Nothing Special   »   [go: up one dir, main page]
Next Article in Journal
Evaluation Model and Application of the Implementation Effectiveness of the River Chief System (RCS)—Taking Henan Province as an Example
Next Article in Special Issue
Concurrent Value-Driven Decision-Making Process for the Aircraft, Supply Chain and Manufacturing Systems Design
Previous Article in Journal
Digital Transformation, Firm Boundaries, and Market Power: Evidence from China’s Listed Companies
You seem to have javascript disabled. Please note that many of the page functionalities won't work as expected without javascript enabled.
 
 
Search for Articles:
Title / Keyword
Author / Affiliation / Email
Journal
Article Type
 
 
Advanced Search
 
Section
Special Issue
Volume
Issue
Number
Page
 
Journals
Systems
Volume 11
Issue 9
10.3390/systems11090480
systems-logo
Submit to this Journal Review for this Journal Propose a Special Issue
► Article Menu

Article Menu

share Share announcement Help format_quote Cite question_answer Discuss in SciProfiles thumb_up
...
Endorse textsms
...
Comment
first_page
settings
Order Article Reprints
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

A Model-Based Engineering Approach for Evaluating Software-Defined Radio Architecture

by
Mohammed G. Albayati
1,
Eric B. Dano
2,
Ravi Rajamani
3 and
Amy E. Thompson
3,*
1
Department of Mechanical Engineering, University of Connecticut, Storrs, CT 06269, USA
2
Department of Engineering Management and Systems Engineering, George Washington University, Washington, DC 20052, USA
3
Department of Electrical and Computer Engineering, University of Connecticut, Storrs, CT 06269, USA
*
Author to whom correspondence should be addressed.
Systems 2023, 11(9), 480; https://doi.org/10.3390/systems11090480
Submission received: 18 August 2023 / Revised: 11 September 2023 / Accepted: 13 September 2023 / Published: 20 September 2023
(This article belongs to the Special Issue Decision Making with Model-Based Systems Engineering)
Browse Figures
Figure 1
<p>Integrated methodology and process for system architecting and trade-off analysis.</p> "> Figure 2
<p>Interaction and interfaces between the system contexts.</p> "> Figure 3
<p>Activity diagram depicting SDR-MM behavior in its context and environment.</p> "> Figure 4
<p>(<b>a</b>) The model shows the power dissipation from a single FPGA along with the power dissipation from the remaining other SDR-MM elements. (<b>b</b>) The Average Electronic Surface Temperature (AEST) versus power dissipation for each architecture.</p> "> Figure 5
<p>Thermal management model to predict the Average Electronic Surface Temperature (AEST): (<b>a</b>) heat is conducted to the enclosure and then transferred to the CEAE through free convection heat transfer; (<b>b</b>) heat is first conducted to the enclosure and heat sink, and then dissipated to the CEAE through either natural or forced convection heat transfer.</p> "> Figure 6
<p>A sample of requirement validation.</p> "> Figure 7
<p>Functional breakdown of Architecture 1 using SysML activity decomposition map.</p> "> Figure 8
<p>SDR-MM system behavior of Architecture 1 captured with activity diagram.</p> "> Figure 9
<p>Internal block diagram (IBD) of Architecture 1 depicting SDR-MM elements and structure.</p> "> Figure 10
<p>Sensitivity analysis using the thermal management model: (<b>a</b>) with variation in thermal conductivity, and (<b>b</b>) with variation in enclosure thickness.</p> "> Figure 11
<p>Functional breakdown of Architecture 2 using SysML activity decomposition map.</p> "> Figure 12
<p>SDR-MM system behavior of Architecture 2 captured with activity diagram.</p> "> Figure 13
<p>Internal block diagram (IBD) of Architecture 2 depicting SDR-MM elements and structure.</p> "> Figure 14
<p>Functional breakdown of Architecture 3 using SysML activity decomposition map.</p> "> Figure 15
<p>Internal block diagram (IBD) of Architecture 3 depicting SDR-MM elements and structure.</p> "> Figure 16
<p>Level 2 functional allocation of Architecture 3.</p> "> Figure 17
<p>Normalized scores for each alternative architecture against each criterion, based on pairwise comparisons from: (<b>a</b>) SME1, (<b>b</b>) SME2, and (<b>c</b>) SME3.</p> ">
Versions Notes

Abstract

:
In product development, important specification and design decisions must be made at various stages of the lifecycle that include design, manufacturing, operations, and support. However, making these decisions becomes more complex when a multi-disciplinary team of stakeholders is involved in system-level or subsystem-level architecture and design decisions. Model-Based Engineering (MBE) approaches are enabling a digital thread of connected data and models. This work demonstrates a novel MBE approach that incorporates a model-based systems engineering (MBSE) method and a multi-criteria decision-making (MCDM) method to determine the best architecture solution that aligns with stakeholder needs and objectives over multiple domains. This approach demonstrates the connection of a system descriptive model, modeled using the systems modeling language (SysML), to underlying physics-based engineering models for the purpose of better predicting the technical performance of systems during the architecture development phase. This approach is demonstrated for a common aerospace communications application, a software-defined radio. This novel MBE approach supports digital transformation at organizations and allows for earlier design validation, enabling designers to test and select the best system architecture from many candidates and validate that the design meets stakeholder needs.

1. Introduction

As technology continues to advance and the complexity of operating environments increases, creating good systems architecture becomes increasingly complex. A digital engineering (DE) approach leverages data, models, and information in a digital environment to support all activities throughout the lifecycle of a product, process, or system. The digital thread is a digital communication framework that connects authoritative sources of information in well-packaged, fit-for-purpose, and standards-based formats. DE and the digital thread have attracted significant interest in the defense, automotive, and energy industries. Digital twins are often a key part of the DE environment. They are a virtual representation of physical systems or processes that enable performance predictions and optimization while maintaining synchronization with the physical system or process throughout its lifecycle [1]. While these terms have been well defined by multiple sources, such as the International Council on Systems Engineering (INCOSE) and the International Organization for Standardization (ISO), there is a need for new and innovative approaches for effectively implementing DE at an organizational level for digital transformation. The creation and use of digital twins are not new and are based on established theories in multiple fields such as data science, artificial intelligence (AI), machine learning (ML), and internet of things (IoT). However, these fields are advancing rapidly, and DE methods and frameworks must be updated to keep pace.
Model-Based Engineering (MBE) is a software-driven approach to system and product development that emphasizes the use of models and simulations throughout the product lifecycle. MBE seeks to automate and streamline the engineering development process by leveraging digital technologies and data-driven methods. MBE can fit into digital engineering by providing a comprehensive and integrated view of a product, from business analysis to retirement, across the lifecycle. By using models from multiple domains to represent the product and its behavior, MBE enables engineers to analyze, test, and validate the product at an early stage of development, reducing the risk of errors and improving the overall quality of the product [2,3].
INCOSE [4] defines Model-Based System Engineering (MBSE) as, “the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases”. In other words, MBSE is a systematic approach to systems engineering that uses models to support various phases of the systems development lifecycle. MBSE is supported by the Systems Modeling Language (SysML), which was developed by INCOSE and the Object Management Group (OMG). SysML is a comprehensive graphical modeling language that can be used to define, analyze, and verify complex systems. This language can be used to model systems that involve various components such as hardware, software, information, personnel, procedures, and facilities [5]. MBSE leverages digital technologies and practices to improve systems engineering, enabling digital transformation. It uses digital models to represent requirements, design, analysis, and other key elements, promoting better collaboration and communication among stakeholders. This results in improved efficiency, consistency, and transparency in the development process, leading to better decisions and faster time to market. MBSE also allows traceability and reuse of system knowledge and artifacts throughout the lifecycle, which are crucial for digital transformation [6,7].
Engineers tend to work in isolated teams or on a specific stage of the development lifecycle across stages such as design, prototyping, implementation, manufacturing, transition, operations, sustainment, and end-of-life considerations. Current SysML and MBSE approaches use separate independent models for the development and manufacturing of systems [8,9,10,11]. Model-Based Production Engineering (MBPE) [9] and Manufacturing System Planning (MSP) [12] focus on optimizing the design of the production system, but not necessarily the design of the product, based on the knowledge and models of the manufacturing system. Additionally, manufacturing planning often begins in the later stages of product design and is performed by different departments and engineers, leading to a lack of communication and inefficiencies, excessive costs for changes, and long development cycles. Moreover, current methods for design for manufacture and assembly (DFMA) and design for producibility may not start until the detailed design of a part begins. The digital thread aims to break down these silos by providing data and models that work together and offer insights into each silo for the purpose of product optimization and innovation.
INCOSE has identified the path for systems engineering in its Vision 2035 document. They state that “system engineering environments will fully leverage advances in digital technologies and modeling standards to enable rapid exploration of designs using high fidelity simulation, data visualization, and semantic web technologies” [13]. They further describe that as discipline and domain-specific tools mature, they must join an ‘Integrated Data Ecosystem’. The enabler for this capability is to incorporate these domain models into a common digital environment, and the more difficult step of defining the required data and parameters that need to be passed between models. For example, in the work presented herein, the system model elements had to have the parameters added to them so that they could pass them into the mechanical structure and heat models so that the findings could be used in early architectural alternative decisions. The future digital MBE environment will allow for rapid assessment of system performance over multiple dimensions, allowing architects to realize a robust transdisciplinary.
Sillitto [14] has defined the system architecture as a process aimed at ensuring that the final system will effectively carry out its intended functions. This involves determining what elements to include in the design. Conceptual architecture refers to the high-level representation of a system that defines its capabilities and their relationships. It serves as a starting point for more detailed design and development work, providing a clear and concise understanding of the system’s objectives, the relationships between its components, and the constraints that must be considered [15]. The cost of making changes during a project’s conceptual architecture phase is much lower than during later stages of development. This is because the system is still being synthesized at this stage, and the changes are easier to implement and less expensive to implement due to the lack of physical or technological constraints. Making changes during later stages can be much more complex, time-consuming, and costly due to the need to undo or redo work that has already been completed. Thus, the conceptual architecture phase is a critical point in the development of a project, as it provides an opportunity to ensure that the system is aligned with its goals and objectives and to make any necessary changes that can help to ensure the success of the project.
Designing a product that can compete in a highly competitive market is a complex task, especially during the development stage when it is important to make the right design choices. Evaluating different alternatives is critical for making the best decision from the stakeholders’ perspective, but this can be complicated due to the need to anticipate and quantify the properties of not-yet-realized artifacts, especially in multi-disciplinary design fields such as systems engineering [16]. Trade study analysis involves transforming qualitative data into quantitative data based on a pre-identified set of criteria to select the preferred solution(s) out of many alternatives [17]. With the right trade study setup, the system design can be performed at hierarchical levels of abstraction. Evaluating alternatives and conducting trade-off analyses are crucial activities in systems engineering to lower costs during early design phases [18]. In a subsequent study, Parnell et al. [19] surveyed the literature to evaluate the use of MBSE approaches and tools for trade study analysis. They found very few MBSE papers dealing with trade space exploration and the evaluation of design alternatives.
The approach to conducting an architecture trade study, as described by Douglass [20], involves the following steps: (1) identifying key system functions, (2) identifying candidate solutions, (3) defining assessment criteria, (4) assigning weights to the criteria, (5) defining a utility curve for each criterion, (6) assigning measures of effectiveness (MOEs) to the candidate solutions, (7) conducting a sensitivity analysis, and (8) determining the final solution. This method builds upon the importance of alternative evaluation and trade-off analysis, which are critical systems engineering activities during the architecture phases, where the cost of redesigning the system is much lower compared to later stages in the system lifecycle.
The design of complex systems can be challenging and requires the use of effective engineering tools to evaluate and optimize different alternatives. MBSE has emerged as a powerful approach to system design, providing a comprehensive and systematic way to analyze and optimize complex systems. In one example, Gao et al. [21] demonstrated the effectiveness of MBSE in designing satellite communication systems, showing how tradespace analysis can lead to better communication and collaboration among stakeholders. In another example, Duncan and Etienne-Cummings [22] implemented MBSE in developing a tool to assess implantable wireless biotelemetry communication systems, highlighting the potential of this approach to identify potential risks and trade-offs and enhance the design process. Similarly, Rojas et al. [23] proposed using MBSE and trade-off analysis to optimize the design of implantable biomedical microdevices, demonstrating the potential of system engineering approaches in improving the design process and resulting system performance. These studies highlight the importance of MBSE in complex system design and the potential of this approach to enhance communication, collaboration, and cost savings in the design process.
While other studies have demonstrated the effectiveness of integrating systems and domain models or systems models with multi-criteria decision-making (MCDM) for complex system design, this paper demonstrates a true MBE approach by integrating systems models, domain models, and MCDM. The goal of this paper is to show how the use of transdisciplinary MBE models and MCDM decision analysis techniques can be used to optimally select between architectural alternatives. The research questions (RQs) to realize this goal are: RQ#1: What model parameters are required to make systems and mechanical models interoperable, RQ#2: Can system models be informed by linked mechanical engineering models, and RQ#3: Can MCDM be used to select between systems engineering architectural alternatives. Our proposed methodology to address the research questions is depicted in Figure 1. Each method in Figure 1 will be elaborated upon in the following sections, including the rationale for its selection in comparison to other options, its application to the SDR application, and the findings.
The proposed integrated methodology, shown in Figure 1, consists of four primary methods: (1) descriptive models (described in Section 2). The descriptive model, created using SysML, includes requirements, structure, behavior, and parametric. To demonstrate the proposed approach, a software-defined radio microwave module (SDR-MM) is used as a case study. The SDR-MM was selected due to its multi-disciplinary engineering nature, versatility in various operational concepts, and modularity that allows for different system configurations to be evaluated [24]. (2) Analytical models (described in Section 3). Combining system and analytical models enhances the engineering design process by comprehensively understanding the system and informed decision making based on functional requirements and technical performance. (3) Architecture definition (described in Section 4). The detailed architecture and description of the three architectural alternatives are described in this section. (4) The MCDM model (described in Section 5). The MCDM processes are used to evaluate and prioritize alternative architectures based on assessment criteria. Integrating system models, analytical models, and MCDM processes forms the basis of MBE, a holistic approach to enhance efficiency, reduce errors, and facilitate early resolution of architecture issues. MBE, along with multi-domain inputs and modeling tools, enables the selection of the optimal architecture alternative and supports the optimization of the system architecture. Finally, a brief conclusion is presented in Section 6 along with suggestions for future work.

2. Descriptive Models

Gao et al. [21] compared six widely recognized MBSE methodologies, IBM’s Rational Unified Process for System Engineering, NASA Jet Propulsion Lab’s State Analysis, Dori’s Object-Process Methodology, IBM’s Harmony-System Engineering, Vitech’s MBSE, and INCOSE’s Object-Oriented Systems Engineering Method (OOSEM). The OOSEM, which covers both software and hardware development within a single framework, was found to be well suited for modeling complex and multi-domain systems. Additionally, it utilizes a standardized, iterative, and recursive procedure that aligns with the systems engineering Vee process model, making it ideal for system modeling at each level of system abstraction. Due to the complex and multi-disciplinary engineering nature, including both software and hardware, of the SDR-MM, the OOSEM Specify and Design System process described in [20] was selected to develop the descriptive model for this problem.
The OOSEM is a comprehensive approach to systems engineering that is based on a top-down, scenario-driven methodology. This method uses SysML to support the various stages of systems development. It encompasses key systems engineering activities such as model set-up, stakeholder needs analysis, use case definition, system requirements analysis, logical and physical architecture definition, optimization and evaluation of alternatives, management of requirements traceability, and system verification and validation. These activities help ensure that the final system meets the stakeholders’ needs and is effective in achieving its goals. Before starting the Analyze Stakeholder Needs process, a Concept of Operation (CONOP) or multiple CONOPs would have been prepared describing the assumptions or intent regarding the enterprise’s overall operation or series of operations. The main activities of OOSEM are summarized below [21,25,26].
Model Set-up. This step involves organizing the model using a SysML package diagram, which includes the analysis of stakeholder needs, system requirements, the definition of the logical and physical architecture, and traceability of requirements. This step also includes defining modeling conventions and standards to maintain a consistent appearance and approach to modeling.
Analyze Stakeholder Needs. In this step, based upon the CONOPs, stakeholders are identified, their problems are analyzed and understood, external systems and users are identified, and top-level use cases and MOEs are defined.
Analyze System Requirements. This step involves specifying the functional requirements, interfaces, critical system properties, performance characteristics, and design constraints. High-level (enterprise) use cases from the previous step can be modeled and analyzed, and an IBD can be created to describe the system’s interactions with other systems.
Define Logical Architecture. The process of defining a logical architecture involves creating a comprehensive overview of the system, including its functional components, their interactions, and relationships. This step also involves breaking down functions and assigning them to the logical elements of the system for better clarity and organization. Further information about this stage can be found in Section 4.
Synthesize Candidate Physical Architectures. This step involves converting the logical architecture into physical components and subsystems. It also entails specifying the physical connections between components and the physical relationships between them, making sure they are aligned with the established requirements and the CONOPs. For more information about this step, refer to Section 4.
Optimize and Evaluate Alternatives. The analysis is conducted to determine the best system architecture that meets the requirements and has the best MOEs. This step is used throughout Section 4 and Section 5.
The OOSEM also includes requirement traceability to ensure that the solutions meet the needs and fulfill the requirements.
During the OOSEM model set-up phase, SysML was selected as the modeling language to build a descriptive model of a system. The OOSEM Specify and Design System process for the SDR-MM is organized using the SysML Package Diagram. The package organization includes stakeholder needs analysis, system requirements analysis, logical and physical architecture definitions, and requirement traceability. Logical and physical architecture definitions were combined in one package, which includes functional analysis, structural analysis, and parametrics for each architecture alternative. This setup facilitated the functional decomposition analysis and evaluation process. Stylistic standards were defined for this project for the use of upper- and lower-case words and templates were established for diagram types.
Information from various stakeholders, including primary user needs, government regulations related to the System of Interest (SOI), industry standards, and policies, can be collected and analyzed. For the SDR-MM, the stakeholder needs are characterized into six categories: (1) functional and performance needs, (2) interfaces, (3) design constraints, (4) electromagnetic environment effects, (5) environmental needs, and (6) lifecycle needs (reliability, safety, maintainability, testability, etc.).
It is crucial to understand the needs and system-level requirements of the stakeholders before developing the SDR-MM, including the desired functionality, performance, and any constraints. In the example presented in this paper, the CONOP was derived based on the desired application of the SDR-MM: which is to add a robust narrowband signal detection capability to an existing system. A fixed narrowband digital signal output is sent to a processor for detection processing. The data are requested based on the desired center frequency and bandwidth and passed over a low-speed data fabric.
The system requirements are either derived or refined from stakeholder needs/CONOPs or are derived from decision analyses. It is important to keep in mind that system requirements are not set in stone and are subject to continuous updates as the architecture synthesis progresses. For the SDR-MM, 20 system requirements (Table 1) were developed, which are related to the six stakeholder needs categories previously mentioned. Traceability relations are used to ensure these system requirements are met during the architecture development process.
The interactions between the SDR-MM and its external systems and environment were considered. The context structure is shown in the IBD in Figure 2 and depicts an operational configuration for the communication system during use. The SDR-MM is shown interacting with external systems that include a Low-Noise Amplifier (LNA), a Time-Frequency-Navigation Geodesy (TFNG) distribution card, an external host computer/processor, a power supply, the Communication Enclosure Air Environment (CEAE), and the Communication System Structure. Considering the SDR-MM as a black box, the IBD depicts how it interacts with other systems and defines the items (materials, energy, data, information, or signals) flowing between systems in the context.
The SDR-MM’s primary function is receiving and converting information from a radio source. A SysML activity diagram was created to depict the activities and behavior involved in the receive signal use case, as shown in Figure 3. This functional behavior definition refines the stakeholder needs and requirements and shows how the main functions of each system interact with all the others. With this black box approach, we do not consider how analog signals are converted to digital data. However, based on stakeholder needs and operational concepts, we depict expected interactions, inputs, and outputs to and from the system in the environment.
MOEs, which capture essential performance and lifecycle considerations, are used to define measurable outcomes that stakeholders expect to achieve when the SOI is integrated into its operating environment. The initial set of 20 requirements (Table 1) was narrowed down to four key criteria. This reduction focused on independent criteria that uniquely distinguish each architecture, as many of the initial requirements were found to be ‘common mode’ factors that all architectures met, and thus did not serve as differentiators in the MCDM assessment. For the SDR-MM, MOEs of signal output bandwidth, total cost, total mass, and safe operating temperatures are defined. These criteria will be described in the following paragraphs.
SDR-MM Cost (USD): This is the total estimated material and labor cost (money spent) to manufacture the SDR-MM. Manufacturing cost (MC) includes the cost of Commercial-Off-The-Shelf (COTS) hardware (HW), assembly cost, and software (SW) programming cost. The SW cost here is non-recurring engineering to load operational SW into the system. The cost of manufacturing the SDR-MM Enclosure was estimated using the DFMA software (version 2021A) by Boothroyd Dewhurst [27]. The tool requires basic geometry information, such as envelope shape and dimensions, and the number and dimension of features (holes, cuts, etc.). It also requires defining the material and manufacturing processes. If applicable, the cost of the thermal solution hardware and labor for the SDR-MM are added.
M C ( U S D ) = C H W + C e n c + C t h r − s o l + C a s s y + C S W
where CHW, Cenc, Cthe-sol, Cassy, and CSW are cost of COTS HW, Enclosure, thermal solution, assembly, and SW, respectively.
SDR-MM Mass (kg): This is the total mass (M) of SDR-MM elements, including connectors, power, signal, and data internal wires and cables, Enclosure, RF tuner, Analog to Digital Converter (ADC), Field-programmable Gate Array (FPGA), and miscellaneous electrical components and mounting HW. If applicable, it also includes the mass of a thermal solution.
M ( k g ) = M e n c + M t h e − s o l + ∑ i = 1 n M i
where Menc and Mthe-sol are mass of Enclosure, and thermal solution, respectively, and i represents the remaining SDR-MM elements.
Signal Processing Performance: Number of Equivalent Narrow Bandwidth (NB) Outputs. This refers to the number of equivalent output channels capable of generating NB signals for processing in the external processor. The number of NB output channels determines the number of spectral range of signals that can be received simultaneously. Note: The signal analysis section has more detail on how to calculate this criterion.
SDR-MM Reliability: Average Electronic Surface Temperature (AEST). The AEST refers to the average temperature of the electronic components of an SDR-MM. It is used as an indicator of the system’s thermal performance and can help predict potential thermal failures. Electronic components must be operated within a certain temperature range to maintain optimal performance, prevent damage, and achieve design life. The AEST measures how close the system or device is to reaching that limit. AEST is often used in the thermal management of electronic systems to ensure that the systems operate within safe temperature ranges. Note: The thermal analysis section has more detail on how to calculate this criterion.

3. Analytical Models

Analytical models and tools are used to calculate and predict the transformation of inputs into outputs for the signal processing and thermal management criteria. Depending on the complexity of the analytical models, the SysML parametric diagram and MBSE solvers can be used to perform calculations. The integration of systems models with analytical models and tools enables the analysis of complex system architectures with higher levels of accuracy.

3.1. Signal Analysis

The design point of maximum power or heat dissipation for each FPGA is a crucial factor in ensuring the system’s robustness and reliability. Thus, an analysis of power consumption for different output channel types for an FPGA-based system is required. The power dissipation of each channel is calculated based on its output channel bandwidth and data link. This information is used to establish the maximum number of output channels that can be instantiated without exceeding the 30 W limit for maximum power or heat dissipation for each FPGA. The analysis results provide valuable insights into the trade-off between the number of channels and power dissipation in the system.
For each NB output, which has a BW of less than 1 MHz, the power dissipation (PDNB) is 6 Watts (W) per channel. This includes 4 W for the Digital Down Converter (DDC) (NB output) and 2 W for the Serializer/Deserializer (SerDes) NB data link, which has a data rate of approximately 100 Mbps. For each wideband (WB) output, which has a BW greater than 1 MHz, the power dissipation (PDWB) is 12 W per channel. This includes 4 W for the DDC and 8 W for the WB SerDes data link, which has a data rate of approximately 4 Gbps.
For example, to determine how many NB channels can be instantiated without exceeding the 30 W max, we add the base consumption of 10 W to the consumption of 3 NB channels, which is 18 W. This results in a total consumption of 28 W, leaving a 2 W margin and a maximum of three NB channels per FPGA. To determine how many WB channels can be instantiated without exceeding the 30 W max, we add the base consumption of 10 W to the consumption of 1 WB channel, which is 12 W. This results in a total consumption of 22 W, leaving an 8 W margin and a maximum of one WB channel per FPGA. The SDR-MM heat load is also a factor in determining the number of channels and will be evaluated in the next section.

3.2. Thermal Analysis

Heat can be generated due to signal processing and can build up inside the SDR-MM. Some failures due to elevated temperatures or overheating could be loss of electronic function of components due to thermal fracture of mechanical support, internal connection failure, or failure in semiconductor materials [28]. Therefore, the thermal management model was developed to predict the AEST inside the SDR-MM. Integrating the thermal model with the system model provides bi-directional connectivity and higher levels of thermal performance to better inform the design decision for optimizing system architecture that meets the stakeholder needs and design constraints.
The power dissipation from the SDR-MM is used in the thermal management model to ensure the system operates below the specified maximum temperature. Correlating the signal output band to the power dissipation establishes a causal relationship between signal processing and thermal management. First, the total power dissipation (PD) is approximated using Equation (3).
P D = N N B × P D N B + N W B × P D W B + N F P G A × ( P D F P G A + P D b a s − F P G A ) + P D o t h − e l e m
where NNB and NWB represent the number of NB and WB output channels, respectively. NFPGA, PDFPGA, and PDbas-FPGA represent the number of FPGAs, the power dissipation per FPGA, and the base power dissipation per FPGA, respectively. The PDbas-FPGA is assumed to be 10 W and depicts the case of FPGA operating without a load. The power dissipation of all non-FPGA related SDR-MM elements (PDoth-elem) is assumed to be 40 W when they are in the ON state. The PD values are estimated based on inputs from the SDR and FPGA subject matter experts (SMEs). Figure 4a depicts the power dissipation of SDR-MM elements for a single FPGA configuration.
A thermal resistance method [29] was used in developing the thermal management model with the following assumptions: (1) steady-state conditions, (2) constant thermal conductivity of the enclosure subsystem material, and (3) only conduction and convection heat transfer. The main purpose of this model is to predict AEST under given design variables and operational air conditions. The inputs to this model are the design variables for the enclosure (enclosure dimensions and material thermal conductivity), the heat generated (or power dissipation) by the signal processor, and the air characteristics of the CEAE.
Figure 5 shows a schematic of both thermal management models. Figure 5a depicts a thermal model where the heat generated by the internal SDR-MM electronic components is conducted through the Enclosure and then dissipated to the CEAE through a free convection heat transfer. First, the thermal resistances for conduction and convection heat transfer are calculated using Equations (4) and (5), then the total resistance is calculated by Equation (6). The thermal resistances of a PCB and a thermal interface material are estimated and added to depict an actual system configuration. Finally, the total power dissipation from all SDR-MM elements, the total calculated resistance, and the air characteristics inside the CEAE are used in Equation (7) to calculate the AEST.
R t , e n c = t / k × A
R t , c o n v = 1 / h c × A
R t o t a l = R t , P C B + R t , T I M + R t ,   e n c + R t , c o n
T A E S = T a + P D × R t o t a l
where Rt,enc is the conduction thermal resistance of the enclosure in K/W, while Rt,con is the convection thermal resistance in K/W. k is the thermal conductivity of the enclosure material in W/(m K), TAES is the Average Electronic Surface Temperature in °C, t is the enclosure thickness in m, hc is convection heat transfer coefficient in W/(m2 K), Ta is air temperature inside the CEAE, and A is the power dissipation area in m2.
The thermal model illustrated in Figure 5b uses a different approach to dissipate the generated heat. It shows that the heat generated by the internal SDR-MM electronic components is first conducted through the enclosure and heat sink, and then dissipated to the CEAE through either natural or forced convection heat transfer. First, the required thermal resistance for a thermal solution (Rthe-sol) is calculated by Equation (8) at the given maximum SDR-MM operating temperature (Tmax) and maximum estimated power dissipation (PDmax) from all SDR-MM elements. Then, the total resistance, including the calculated thermal solution resistance, and the AEST are calculated using Equations (9) and (7), respectively.
R t h e − s o l = ( T m a x − T a ) / P D m a x − R t , P C B + 2 ∗ R t , T I M + R t , e n c
R t o t a l = R P C B + 2 ∗ R t , T I M + R t , e n c + R t h e − s o l

4. Architecture Definition

Developing an architecture for an SDR-MM requires a systematic approach. In this approach, CONOP and system requirements were used to determine the desired functionality and performance of the SDR-MM. Three alternative architectures were developed from the stated CONOP using the following methodology which aligns closely with the last three steps of OOSEM.
The process begins with functional decomposition, which involves breaking down the system’s use case(s) into smaller, more manageable subfunctions. The decomposition of the main SDR-MM function is an essential step in understanding how the functions of the SDR-MM interact with each other and contribute to its overall operation. Based on the CONOP and stakeholder needs, the main purpose of the SDR-MM is to receive analog signals from LNA and perform digital conversion (Level 0 function); however, the three architectures differ at Level 1 and Level 2 functions, specifically transforming analog RF signal to digital data and managing heat. The SysML activity decomposition map is an effective tool for displaying the functional decomposition and breakdown at multiple levels, and activity decomposition map examples are provided in the following three subsections, one for each architecture alternative.
Next, the Level 1 and 2 functions are allocated to SDR-MM elements. This involves creating a high-level conceptual architecture that outlines the major components and interfaces of the module, including any hardware components and external interfaces. The SysML activity diagram can be used for this purpose. The functions, flows, and interfaces can be realized and allocated to the conceptual elements. Finally, the SDR-MM architecture is tested and evaluated against the requirements and CONOP to ensure that it meets the desired performance and functionality. Analytical models are used to calculate and predict the transformation of inputs into outputs and system parameters. To enable simulation capabilities, SysML constraint blocks are used to define constraints on the system behavior. They are linked to the model elements that they constrain, allowing for traceability and analysis throughout the development process.
As part of the validation process, the ‘satisfy’ relationship between MOEs and their associated requirements was established [30]. For example, for the design constraint of ‘the total cost of the SDR-MM shall be less than USD 15,000’ will be formalized as totalCost < USD 15,000. A sample for the architecture design validation process is shown in Figure 6.

4.1. Application of the Architecture Definition Process for the Development of Alternative Archetecture 1

The development of the SDR-MM architecture was performed in three steps, as outlined in the architecture definition section. The transfer analog to digital function is decomposed into 11 Level 1 subfunctions. Then, some of the level 1 subfunctions are further broken down into lower-level functions at level 2, as illustrated in Figure 7. Only two essential functions are highlighted in this work: managing heat and transferring the analog RF signal to digital data. Figure 8 illustrates not only the interaction and interfaces between level 1 functions but also shows the functional allocation to the conceptual elements of the SDR-MM. The functions manage heat and provide structural support for SDR-MM elements are allocated to an enclosure while down convert analog RF signals to analog IF frequencies, digitize the IF signal, convert the analog IF signal to real digital IF samples, and convert real digital IF signal to complex digital baseband data are allocated to an RF tuner, an ADC, and an FPGA, respectively. The elements and structure of this architecture are illustrated in Figure 9. Architecture 1 does not include a heat sink, as shown in Figure 9, and using the simulation capabilities of the MBSE tool, the module was tested under different signal performance scenarios with varying numbers of NB outputs. Figure 4a illustrates that with a single FPGA configuration, the total power dissipation can reach up to 70 W with a maximum of 30 W coming from the FPGA. Based on the assumption that each NB output can dissipate 6 W, a single FPGA can handle 3 outputs. However, due to heat constraints, this architecture can only support one NB output, as shown in Figure 4b, with the maximum temperature reaching 129 °C.
The resulting Architecture 1 is limited by its heat dissipation capabilities, despite meeting CONOP with a 1 °C margin. As previously mentioned, the manage heat function is performed by an enclosure, making a sensitivity analysis on enclosure parameters crucial in testing the possibility of improving heat dissipation capabilities. Figure 10a,b depict the SDR-MM operating at different FPGA loads and at the given CEAE characteristics (convection transfer coefficient and air temperature). The results indicate that material thermal conductivity and enclosure thickness alone are not enough to enhance heat dissipation, as there is no significant impact on AEST. A sensitivity analysis was also performed on the CEAE characteristics and showed that power dissipation can be improved by higher heat transfer coefficients or a colder environment. However, since we are designing the SDR-MM, not the CEAE, a passive or active thermal solution could enhance heat dissipation.
Due to the proprietary nature of SDR-MM, it can be challenging to determine the breakdown of costs and mass. An estimation method was used to overcome this, which involved looking at similar modules developed by other vendors for similar CONOP. The electronic COTS hardware, assembly, and SW programming for Architecture 1 with a single channel (a single FPGA) were estimated to cost USD 10,000. Additionally, the Enclosure was estimated to cost USD 80, using the DFMA tool [27], and this cost was added to the total. Similarly, the mass of all the SDR-MM elements was estimated to be 0.5 kg, and the Enclosure mass was estimated to be 1.38 kg.

4.2. Application of the Architecture Definition Process for the Development of Alternative Archetecture 2

The steps outlined in the architecture definition section are also implemented to develop this architecture. The main function is broken down into twelve subfunctions. Architecture 2 converts a real digital IF signal to complex digital baseband data in a comparable manner to Architecture 1, which is accomplished by a single FPGA. Additionally, the RF Tuner is used to down-convert analog RF signals to analog IF frequencies, and the ADC is used to digitize the IF signal and convert the analog IF signal to real digital IF samples. However, the method of managing heat is different. Since the functional decomposition is similar to Architecture 1, only differing aspects are highlighted in Figure 11. The activity diagram in Figure 12 displays functional allocations, flows, and interfaces between SDR-MM components. Heat is first conducted to a thermal solution through the Enclosure and then dissipated to the environment via a heat sink. The Enclosure manages the first stage, while the heat sink manages the second. Additionally, the structural model (Figure 13) was generated automatically using the capability of the MBSE tool [31].
The thermal analysis was performed in two steps. First, the required thermal resistance of a heat sink was calculated using Equation (8) under extreme operating conditions, 30 W power dissipation from the FPGA and a maximum SDR-MM operating temperature of 130 °C, and was found to be 1.5 °C/W. Then, the AEST was calculated at different numbers of NB outputs. As Figure 4b shows, this architecture can support up to three NB outputs due to the use of a thermal solution (a heat sink in this case) with the maximum temperature reaching 127 °C.
A similar approach used for Architecture 1 cost and mass estimation was used for this architecture. This also has a single FPGA, so the electronic COTS hardware, assembly, and SW programming were estimated to cost USD 10,000, with a similar cost for the Enclosure. Additionally, an estimated USD 125 was added to the total for material and labor costs for the thermal solution and attachment to the Enclosure. The mass of this architecture is estimated to be 2.12 kg. As stated, it uses a similar enclosure but differs in extra weight due to a thermal solution.

4.3. Application of the Architecture Definition Process for the Development of Alternative Archetecture 3

Architecture 3 manages heat similarly to Architecture 2 but differs in the conversion of a real digital IF signal to complex digital baseband data. An RF tuner is utilized similar to Architectures 1 and 2 to down-convert analog RF signals to analog IF frequencies and an ADC is used to digitize the IF signal and convert the analog IF signal; however, the conversion function is divided into two stages, each handling one WB output, as shown in Figure 14. The activity diagram of this architecture is similar to that of Architecture 2, and thus is not presented. However, it has different elements and structure as depicted in Figure 15. Based on the assumption that each WB output generates 12 W of heat, two FPGAs are required, as depicted in Figure 16 (for clarity, not all input and output flows are displayed in the figure).
The thermal dissipation model is slightly different from architectures 1 and 2, where a maximum of 60 W can be dissipated as heat from both FPGAs. The thermal analysis was also performed in two steps. First, the required thermal resistance of a heat sink was calculated using Equation (8) under extreme operation conditions, 60 W power dissipation from the FPGAs, and a maximum SDR-MM operating temperature of 130 °C, and it was found to be 1 °C/W. Then, the AEST is calculated at different numbers of WB outputs. As Figure 4b shows, this architecture can support up to two WB outputs due to the use of a thermal solution (a heat sink in this case) with the maximum temperature reaching 113 °C.
Similarly, the cost and mass were estimated for a two FPGAs configuration. The electronic COTS hardware, assembly, and SW programming were estimated to cost USD 15,000, with a slightly larger enclosure to accommodate the additional FPGA. Additionally, USD 180 was added to the total for material and labor costs for the thermal solution and attachment to the Enclosure. The mass of this architecture is estimated to be 2.79 kg. The increase in cost and mass is due to a second FPGA, a slightly larger enclosure, and a larger heat sink with lower thermal resistance. Table 2 summarizes the assessment criteria for the three architectures.

5. Multi-Criteria Decision-Making Analysis

This method involves making a multiple-attribute decision where we must weigh different performance metrics to determine the best architectural alternatives (derived in Section 4) that satisfies the requirements, CONOP, technical performance, and design constraints. There are many MCDM methods available for use. The Analytic Hierarchy Process (AHP) is an MCDM method to evaluate and prioritize options based on a set of criteria. It is particularly useful when there are multiple conflicting objectives or criteria that need to be considered in a decision. AHP is widely employed for making decisions and determining criteria weights from SME entered pair-wise comparisons of all criteria AHP also provides a quality metric from SME inputs, which can flag inconsistencies in the pair-wise comparisons [32,33,34]. Fuzzy AHP is another variant that uses a range of High/Typical/Low inputs as part of the pair-wise comparison process, allowing for inherent sensitivity checking in the process. Relative AHP is an effective method for ranking a limited number of alternatives in new and exploratory decision-making processes. It involves comparing each alternative pairwise and determining their relative importance. The relative comparison, even if consistent, must always be assessed for any inherent SME biases. For this reason, many MCDM applications use AHP for the weighting and other methods such as TOPSIS [35] and VIKOR [36] for scoring. These methods are based on various ways of determining the distance from an “ideal solution”. For our application, we selected AHP-based weighting due to the multiple diverse criteria used (e.g., robustness). To address any “SME bias”, three SMEs were used to independently perform the AHP criteria weight calculation. It was decided that instead of using a single set of derived mean SME weights, all three sets were carried forward to assess uncertainty. This could have also been achieved by using the Fuzzy AHP method. For scoring, the criteria utility functions are very non-linear, and it is less clear what the ideal solution is (e.g., the robustness of SDR outputs). For that reason, a relative AHP approach was used so that the SMEs could best assess the relative score of the alternatives for each category. As was performed for the weighting, three SMEs were used to prevent any single SME bias. Sensitivity analysis in AHP helps to evaluate the stability, reliability, and robustness of the decision-making process. It provides insights into the sensitivity of the decision to changes in the criteria or alternatives and helps decision makers make informed choices based on the impact of different scenarios on the overall outcome [37,38].
The AHP process consists of several steps that guide the decision maker in evaluating options and making a final choice. The first step is to define the problem or decision that must be made and identify the objectives or criteria used to evaluate the options. These objectives and criteria should be organized into a hierarchical structure, starting with the most general objective at the top and breaking it down into more specific criteria at lower levels. The next step is to compare the criteria in pairs and assign relative weights to each criterion based on its importance relative to the other criterion. The experts make pairwise comparisons, and then the answers are consolidated and normalized into a set of weights. Then, the options or alternatives are assessed against each criterion using relative weights derived through expert elicitation. Finally, the scores for each option are combined across all criteria, using the relative weights assigned to the criteria to adjust the scores. A decision is then made by comparing the overall scores for each option.
The AHP utilizes a technique called pairwise comparison to assign relative importance to different criteria or options. The pairwise comparison involves comparing each criterion or option with every other criterion or option, and assigning a rating based on the relative importance of one element compared to the other. The commonly used rating scale for pairwise comparison includes a range of values such as 1 to 9, where 1 indicates equal importance, 3 indicates moderately more important, 5 indicates strongly more important, 7 indicates very strongly more important and 9 indicates extremely more important. Additionally, intermediate values can be used to indicate importance levels between any two of these ratings that the relative importance between two criteria or options is not extremely different or extremely similar, but somewhere in between. It is important to use the scale consistently throughout the process and avoid arbitrary values or personal biases while comparing criteria or options. By using pairwise comparison in a systematic and consistent manner, the decision maker can ensure that the relative weights assigned to the criteria or options are accurate and reliable [32,33]. It is important to note that a consistency check of the pairwise comparisons is critical to ensure the accuracy of the final decision. One measure of consistency is the Consistency Ratio (CR), which can be used to determine if the judgments of the evaluators are consistent. According to [33], a CR of 0.1 or less is considered acceptable and indicates that the judgments of the evaluators are consistent. Therefore, the decision maker should check the CR and ensure that it meets this threshold before making a final decision.
The AHP process helps to make trade-off decisions between conflicting requirements. Having multiple individuals participate in the completion of AHP pairwise comparison matrices can lead to reduced bias and improved accuracy of results. This approach also allows for various perspectives to be considered, resulting in a more comprehensive decision-making process [32,33,34]. Therefore, we asked three SMEs to complete the pairwise survey. One SME is a university professor who instructs courses related to System Engineering, while the other two SMEs are industry representatives from the aerospace sector, one having extensive practical design experience with communications. In the assessment process, the importance of various criteria to stakeholders and the alternative priorities were quantified using pairwise comparisons from three SMEs. For the four criteria, a 4 × 4 square pairwise comparison matrix A was created. In this matrix, each entry aij represents the relative importance of criterion i over criterion j, rated on a scale of 1 to 9. To calculate the weights of the criteria, matrix A was first normalized by dividing each element aij by the sum of its respective column, as defined by Equation (10). The average row scores (ARS) were then calculated using Equation (11), approximating the eigenvector of the pairwise comparison matrix, the results of which are presented in Table 3. This process was carried out for each SME. Similarly, for the three architectural alternatives and four assessment criteria, four 3 × 3 matrices were created for each SME. This was performed to determine the priority (or score) for each alternative architecture against each criterion. Each matrix was initially normalized, and then the ARS were calculated using equations 10 and 11, respectively. This process was repeated for each SME, and the resulting scores are displayed in Table 4 and Figure 17. Throughout the process, the CR was calculated using the method from Reference [33] and monitored. If any inconsistency was identified (CR > 0.1), a request was made to the SMEs to adjust their pairwise comparisons. Only the final and consistent results (CR < 0.1) are presented in this paper. The scores are given as values between 0 and 1. The score assigned to each alternative is weighted across criteria based on the importance of the criteria using Equation (12), and the overall score for each alternative is calculated by summing up the scores from the three SMEs, as illustrated in Table 5.
b i j = a i j ∑ i = 1 n a i j
A R S = ∑ i = 1 n b i j n
W C S = W . C r i ∗ S . C r i
where n, ARS, WCS, W.Cr, and S.Cr represent the number of assessment criteria, the average row score, weighted criterion score, criterion weight, and criterion score, respectively.
The CONOP was designed to enhance the single-channel NB receive capability to complement other system capabilities. The primary objective was to demonstrate robustness in the system’s performance in defense-related applications. The assumption was that the customer preferred robustness in the system’s performance over other factors, such as cost and weight.
Three architectures were considered to achieve the CONOP, each with its unique design and components. Each architecture was evaluated based on four criteria, with the most essential being performance related, followed by reliability. The data showed that all three alternatives met the CONOP and stakeholder needs, but architectures 2 and 3 have higher scores for criteria 3 and 4, which are related to robustness and reliability, as illustrated in Figure 17. This is because these architectures have an additional channel, which provides better performance and reduces the risk of system failure.
The cost and weight of the alternatives were also considered in the evaluation. It was found that there was no significant increase in cost from Architecture 1 to 2, but Architecture 3 had a significant increase in cost and weight due to the use of an active thermal solution, a second FPGA, and a larger enclosure.
Based on the data, Architecture 2 was found to be the most favorable among the three alternatives, with an overall score of 1.20. This suggests that it offers the best balance of performance, robustness, reliability, and cost. Architecture 1 had the lowest overall score of 0.70, which can be attributed to its lack of robustness, as it only has a single channel.
A limited sensitivity study was conducted on our methodology/AHP approach. This was performed by assessing the average weights over a ±10% and 20% range for each criterion, applying the resulting weights to the average scores for each alternative, and then tabulating to obtain the best alternative. No change was observed in the architecture 2 selection in the ±10% range. The 20% range was felt to cover any SME judgement error in the peer-wise rankings. What was found is that Cr.1, Cr.2 and Cr.4 still yielded the stated alternative 2 solution over the entire ±20% variation. Cr.3 at average weighting − 20% also yielded alternative 2, but at average weighting + 20% alternative 3 was a statistical tie with alternative 2. This could be expected since alternative 3 provided the widest bandwidth (Cr.3) but was the most expensive (Cr.1), heaviest (Cr.2) and required the most heat mitigation (Cr.4). Pushing Cr.3 up to average weighting + 20% and renormalizing weights reduced all the negative factors of alternative 3 and amplified its greatest asset (Cr.3). As this corner case occurred right at the 20% test point (beyond the variation in SME answers), it can be posited that the finding as stated are robust. In retrospect, a fuzzy AHP approach could have been used to inherently allow for determination of sensitivity.

6. Conclusions and Future Work

This work demonstrates the integration of multi-disciplinary engineering models into a comprehensive MBE approach which was used to enable engineers to make informed decisions and assess various architecture alternatives early in the development process. In addition to integrating engineering models, an MCDM analysis was performed to determine the best system architecture that meets functional requirements, technical performance, and design constraints. The AHP was used to evaluate and prioritize options based on assessment criteria. Three SMEs were asked to participate in the pairwise comparison of the criteria and alternatives, which helped to reduce bias and improve the accuracy of the results. Architecture 1 had limitations in robustness due to its single-channel design. Architecture 2 was highlighted as the most balanced option, excelling in performance, robustness, reliability, and cost. Architecture 3, despite its high performance and robustness, was less favorable due to significant increases in cost and weight. Sensitivity analysis was also carried out to assess the robustness and stability of alternative rankings with respect to criteria weights. It was found that if the weight of Cr.3 increases by 20%, Architecture 3 would statistically tie Architecture 2 as the best solution. However, this was posited to be a point beyond.
In this research journey of exploring the integration of multi-disciplinary engineering models into system development, several pivotal insights were unearthed. This research successfully incorporated these models into a holistic MBE framework, enhancing the early stages of system development. This work identified key parameters promoting interoperability between Systems Engineering and Mechanical Engineering models, underscoring the potential for deepened interdisciplinary collaboration. Importantly, our findings underscore the invaluable role of Mechanical Engineering models in system-level decision making and the proven efficacy of multi-criteria decision-making MCDM methods in guiding architectural choices. Collectively, these results promise to revolutionize system development paradigms and pave the way for innovative strides in the domain.
This study demonstrates a scalable approach for incorporating multiple engineering models, assessment criteria, and the knowledge and expertise from SMEs to form an MBE model. The methodology and results can be easily adapted to similar projects and extended to include more models, criteria, experts, and alternative CONOPs. In the future, machine learning approaches can transform the way multi-objective optimization is performed. Its ability to learn and make predictions based on data can enable it to perform more advanced decision making, considering multiple conflicting objectives, and providing optimal and accurate results.
In future work, details of manufacturability during the early phases of product development can be considered to ensure that the final product is not only functional but also cost-effective and producible. This will allow for a more thorough evaluation of system architectures and ensure that the final decision is based on a comprehensive understanding of all relevant factors.

Author Contributions

M.G.A., conceptualization, methodology, validation, writing—original draft preparation, investigation, and data curation. E.B.D., conceptualization, methodology, and writing—reviewing and editing. R.R., methodology and writing—reviewing and editing. A.E.T., conceptualization, methodology, supervision, funding acquisition, and writing—reviewing and editing. All authors have read and agreed to the published version of the manuscript.

Funding

This research was funded by the Air Force Research Laboratory, Materials and Manufacturing Directorate (AFRL/RXMS) for support via Contract No. FA8650-20-C-5206. Additional support was provided by the University of Connecticut Pratt & Whitney Institute for Advanced Systems Engineering (UConn-PW-IASE).

Institutional Review Board Statement

Distribution A. Approved for public release: distribution unlimited. (AFRL-2023-1588) Date Approved 04-06-2023.

Informed Consent Statement

Not applicable.

Data Availability Statement

Not applicable.

Conflicts of Interest

The authors declare no conflict of interest.

References

  1. INCOSE DEIX Working Group. Digital Engineering and the Digital Twin; INCOSE DEIX Working Group: San Diego, CA, USA, 2022. [Google Scholar]
  2. Marko, N.; Liebel, G.; Sauter, D.; Lodwich, A.; Tichy, M.; Leitner, A.; Hansson, J. Model-Based Engineering for Embedded Systems in Practice; Technical Report; University of Gothenburg: Göteborg, Sweden, 2014. [Google Scholar]
  3. Liebel, G.; Marko, N.; Tichy, M.; Leitner, A.; Hansson, J. Model-based engineering in the embedded systems domain: An industrial survey on the state-of-practice. Softw. Syst. Model. 2018, 17, 91–113. [Google Scholar] [CrossRef]
  4. International Council of Systems Engineering (INCOSE). Systems Engineering Vision 2020; Version 2.03, TP-2004-004-02; International Council of Systems Engineering (INCOSE): Seattle, WA, USA, 2007. [Google Scholar]
  5. Object Management Group. OMG Systems Modeling Language (OMG SysMLTM); Object Management Group: Needham, MA, USA, 2019. [Google Scholar]
  6. Schluse, M.; Atorf, L.; Rossmann, J. Experimentable Digital Twins for Model-Based Systems Engineering and Simulation-Based Development. In Proceedings of the 2017 Annual IEEE International Systems Conference (SysCon), Montreal, QC, Canada, 24–27 April 2017. [Google Scholar] [CrossRef]
  7. Gilbert, T.W. Mbse:Digital_Engineering [MBSE Wiki]. OMG. 2023. Available online: https://www.omgwiki.org/MBSE/doku.php?id=mbse:digital_engineering (accessed on 9 February 2023).
  8. Lechevalier, D.; Narayanan, A.; Rachuri, S.; Foufou, S. A methodology for the semi-automatic generation of analytical models in manufacturing. Comput. Ind. 2018, 95, 54–67. [Google Scholar] [CrossRef]
  9. Kübler, K.; Scheifele, S.; Scheifele, C.; Riedel, O. Model-Based Systems Engineering for Machine Tools and Production Systems (Model-Based Production Engineering). Procedia Manuf. 2018, 24, 216–221. [Google Scholar] [CrossRef]
  10. Tao, F.; Qi, Q.; Wang, L.; Nee, A.Y.C. Digital twins and cyber–physical systems toward Smart manufacturing and industry 4.0: Correlation and comparison. Engineering 2019, 5, 653–661. [Google Scholar] [CrossRef]
  11. Tao, F.; Cheng, J.; Qi, Q.; Zhang, M.; Zhang, H.; Sui, F. Digital twin-driven product design, manufacturing and service with big data. Int. J. Adv. Manuf. Technol. 2018, 94, 3563–3576. [Google Scholar] [CrossRef]
  12. Steimer, C.; Fischer, J.; Aurich, J.C. Model-based design Process for the early phases of manufacturing system planning using SysML. Procedia CIRP 2017, 60, 163–168. [Google Scholar] [CrossRef]
  13. INCOSE. Systems Engineering Vision 2035. 2021. Available online: https://www.incose.org/2023_redesign/publications/se-vision-2035 (accessed on 6 September 2023).
  14. Sillitto, H. Architecting Systems: Concepts, Principles and Practice; College Publications: London, UK, 2014. [Google Scholar]
  15. Bass, L.; Clements, P.; Kazman, R. Software Architecture in Practice: Software Architect Practice_c3; SEI Series in Software Engineering; Addison-Wesley Professional: Boston, PA, USA, 2012. [Google Scholar]
  16. Lo, M.; Couturier, P. A metamodel of evaluation in systems engineering: Application to a mechatronic design. IFAC Proc. Vol. 2012, 45, 1562–1567. [Google Scholar] [CrossRef]
  17. Morkevicius, A.; Aleksandraviciene, A.; Armonas, A.; Fanmuy, G. Towards a common systems engineering methodology to cover a complete system development process. INCOSE Int. Symp. 2020, 30, 138–152. [Google Scholar] [CrossRef]
  18. Parnell, G.S. Trade-Off Analytics: Creating and Exploring the System Tradespace; John Wiley & Sons: Hoboken, NJ, USA, 2016. [Google Scholar]
  19. Parnell, G.S.; Shallcross, N.; Specking, E.; Phillips, M. MBSE enabled trade-off analyses. INCOSE Int. Symp. 2021, 31, 1406–1416. [Google Scholar] [CrossRef]
  20. Douglass, B. Agile Model-Based Systems Engineering Cookbook; Packt Publishing Ltd.: Birmingham, UK, 2021; ISBN 1838985837. [Google Scholar]
  21. Gao, S.; Cao, W.; Fan, L.; Liu, J. MBSE for satellite communication system architecting. IEEE Access 2019, 7, 164051–164067. [Google Scholar] [CrossRef]
  22. Duncan, K.R.; Etienne-Cummings, R. A Model-Based Systems Engineering Approach to Trade Space Exploration of Implanted Wireless Biotelemetry Communication Systems. IEEE Syst. J. 2019, 13, 1669–1677. [Google Scholar] [CrossRef]
  23. Martínez Rojas, J.A.; Fernández, J.L.; Sánchez Montero, R.; López Espí, P.L.; Diez-Jimenez, E. Model-Based Systems Engineering Applied to Trade-Off Analysis of Wireless Power Transfer Technologies for Implanted Biomedical Microdevices. Sensors 2021, 21, 3201. [Google Scholar] [CrossRef] [PubMed]
  24. Dano, E. A Case Study on the Architectural Development of a Transceiver Assembly. In Proceedings of the 2019 International Symposium on Systems Engineering (ISSE), Edinburgh, UK, 1–3 October 2019; pp. 1–6. [Google Scholar]
  25. Friedenthal, S.; Moore, A.; Steiner, R. A Practical Guide to SysML: The Systems Modeling Language, 3rd ed.; Morgan Kaufmann: Burlington, MA, USA, 2014; ISBN 9780128008003. [Google Scholar]
  26. INCOSE. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities; Wiley: Hoboken, NJ, USA, 2015; ISBN 1118999401. [Google Scholar]
  27. DFMA® Software and Services|Boothroyd Dewhurst, Inc. 2023. Available online: https://www.boothroyddewhurst.com/ (accessed on 17 January 2023).
  28. Ulrich, R.K.; Brown, W.D. Advanced Electronic Packaging; John Wiley & Sons: Hoboken, NJ, USA, 2006; ISBN 978-0471466093. [Google Scholar]
  29. Bergman, T.L.; Bergman, T.L.; Incropera, F.P.; Dewitt, D.P.; Lavine, A.S. Fundamentals of Heat and Mass Transfer; John Wiley & Sons.: New York, NY, USA, 2011. [Google Scholar]
  30. Bankauskaite, J.; Strolia, Z.; Morkevicius, A. Automated trade study analysis based on dynamic requirements verification in the model-based system engineering. INCOSE Int. Symp. 2021, 31, 1256–1270. [Google Scholar] [CrossRef]
  31. No Magic, Inc. Magic Model Analyst 2022x Refresh1 User Guide; No Magic, Inc.: Allen, TX, USA, 2022. [Google Scholar]
  32. Saaty, T.L.; Vargas, L.G. The Seven Pillars of the Analytic Hierarchy Process. In Models, Methods, Concepts & Applications of the Analytic Hierarchy Process; International Series in Operations Research & Management Science; Springer: Boston, MA, USA, 2001; Volume 34. [Google Scholar] [CrossRef]
  33. Saaty, R.W. The analytic hierarchy process-what it is and how it is used. Math. Model. 1987, 9, 161–176. [Google Scholar] [CrossRef]
  34. Al-Saggaf, A.; Nasir, H.; Hegazy, T. An Analytical Hierarchy Process-based system to evaluate the life-cycle performance of buildings at early design stage. J. Build. Eng. 2020, 31, 101364. [Google Scholar] [CrossRef]
  35. Putra, J.A.; Rakhman, T.; Biddinika, M.K. Selection between AHP and TOPSIS for Academic Information Systems Decision Making Model. In Proceedings of the 2nd International Conference on Applied Science, Engineering and Social Sciences, Yogyakarta, Indonesia, 7–8 August 2019; SCITEPRESS—Science and Technology Publications: Setúbal, Portugal, 2019; pp. 86–89. [Google Scholar]
  36. Siahaan, A.; Siregar, D.; Napitupulu, D. Multi-Attribute Decision Making with VIKOR Method for Any Purpose Decision. J. Phys. Conf. Ser. 2018, 1019, 012034. [Google Scholar] [CrossRef]
  37. Mansor, M.R.; Hambali, A.; Azaman, M.D.; Sapuan, S.M.; Zainudin, E.S.; Nuraini, A.A. Material Selection of Thermoplastic Matrix for Hybrid Natural Fiber/Glass Fiber Polymer Composites using Analytic Hierarchy Process Method. In Proceedings of the International Symposium on the Analytic Hierarchy Process, Kuala Lumpur, Malaysia, 23–26 June 2013; pp. 1–8. [Google Scholar]
  38. Mekonnen, T.M.; Mitiku, A.B.; Woldemichael, A.T. Flood Hazard Zoning of Upper Awash River Basin, Ethiopia, Using the Analytical Hierarchy Process (AHP) as Compared to Sensitivity Analysis. Sci. World J. 2023, 2023, 1675634. [Google Scholar] [CrossRef]
Systems 11 00480 g001
Figure 1. Integrated methodology and process for system architecting and trade-off analysis.
Figure 1. Integrated methodology and process for system architecting and trade-off analysis.
Systems 11 00480 g001
Systems 11 00480 g002
Figure 2. Interaction and interfaces between the system contexts.
Figure 2. Interaction and interfaces between the system contexts.
Systems 11 00480 g002
Systems 11 00480 g003
Figure 3. Activity diagram depicting SDR-MM behavior in its context and environment.
Figure 3. Activity diagram depicting SDR-MM behavior in its context and environment.
Systems 11 00480 g003
Systems 11 00480 g004
Figure 4. (a) The model shows the power dissipation from a single FPGA along with the power dissipation from the remaining other SDR-MM elements. (b) The Average Electronic Surface Temperature (AEST) versus power dissipation for each architecture.
Figure 4. (a) The model shows the power dissipation from a single FPGA along with the power dissipation from the remaining other SDR-MM elements. (b) The Average Electronic Surface Temperature (AEST) versus power dissipation for each architecture.
Systems 11 00480 g004
Systems 11 00480 g005
Figure 5. Thermal management model to predict the Average Electronic Surface Temperature (AEST): (a) heat is conducted to the enclosure and then transferred to the CEAE through free convection heat transfer; (b) heat is first conducted to the enclosure and heat sink, and then dissipated to the CEAE through either natural or forced convection heat transfer.
Figure 5. Thermal management model to predict the Average Electronic Surface Temperature (AEST): (a) heat is conducted to the enclosure and then transferred to the CEAE through free convection heat transfer; (b) heat is first conducted to the enclosure and heat sink, and then dissipated to the CEAE through either natural or forced convection heat transfer.
Systems 11 00480 g005
Systems 11 00480 g006
Figure 6. A sample of requirement validation.
Figure 6. A sample of requirement validation.
Systems 11 00480 g006
Systems 11 00480 g007
Figure 7. Functional breakdown of Architecture 1 using SysML activity decomposition map.
Figure 7. Functional breakdown of Architecture 1 using SysML activity decomposition map.
Systems 11 00480 g007
Systems 11 00480 g008
Figure 8. SDR-MM system behavior of Architecture 1 captured with activity diagram.
Figure 8. SDR-MM system behavior of Architecture 1 captured with activity diagram.
Systems 11 00480 g008
Systems 11 00480 g009
Figure 9. Internal block diagram (IBD) of Architecture 1 depicting SDR-MM elements and structure.
Figure 9. Internal block diagram (IBD) of Architecture 1 depicting SDR-MM elements and structure.
Systems 11 00480 g009
Systems 11 00480 g010
Figure 10. Sensitivity analysis using the thermal management model: (a) with variation in thermal conductivity, and (b) with variation in enclosure thickness.
Figure 10. Sensitivity analysis using the thermal management model: (a) with variation in thermal conductivity, and (b) with variation in enclosure thickness.
Systems 11 00480 g010
Systems 11 00480 g011
Figure 11. Functional breakdown of Architecture 2 using SysML activity decomposition map.
Figure 11. Functional breakdown of Architecture 2 using SysML activity decomposition map.
Systems 11 00480 g011
Systems 11 00480 g012
Figure 12. SDR-MM system behavior of Architecture 2 captured with activity diagram.
Figure 12. SDR-MM system behavior of Architecture 2 captured with activity diagram.
Systems 11 00480 g012
Systems 11 00480 g013
Figure 13. Internal block diagram (IBD) of Architecture 2 depicting SDR-MM elements and structure.
Figure 13. Internal block diagram (IBD) of Architecture 2 depicting SDR-MM elements and structure.
Systems 11 00480 g013
Systems 11 00480 g014
Figure 14. Functional breakdown of Architecture 3 using SysML activity decomposition map.
Figure 14. Functional breakdown of Architecture 3 using SysML activity decomposition map.
Systems 11 00480 g014
Systems 11 00480 g015
Figure 15. Internal block diagram (IBD) of Architecture 3 depicting SDR-MM elements and structure.
Figure 15. Internal block diagram (IBD) of Architecture 3 depicting SDR-MM elements and structure.
Systems 11 00480 g015
Systems 11 00480 g016
Figure 16. Level 2 functional allocation of Architecture 3.
Figure 16. Level 2 functional allocation of Architecture 3.
Systems 11 00480 g016
Systems 11 00480 g017
Figure 17. Normalized scores for each alternative architecture against each criterion, based on pairwise comparisons from: (a) SME1, (b) SME2, and (c) SME3.
Figure 17. Normalized scores for each alternative architecture against each criterion, based on pairwise comparisons from: (a) SME1, (b) SME2, and (c) SME3.
Systems 11 00480 g017
Table 1. System requirement derived from stakeholder needs.
Table 1. System requirement derived from stakeholder needs.
Req. No.Req. NameReq. Text
SR.1Process the Received Analog SignalsThe SDR-MM shall accept analog signals with the characteristics specified in the ‘Input Analog Signal Characteristics’ and transform them into digital data.
SR.2Quality of Output Data: Number of Equivalent Narrow Band OutputsThe SDR-MM shall have multiple bandwidth digital data outputs without overheating the system.
SR.3Interact with External Host Computer/Processor: Commands and StatusThe SDR-MM shall accept operational commands (on and off) from the External Host Computer/Processor and send out the status information.
SR.4Input Analog Signal CharacteristicsThe SDR-MM shall accept an analog signal with the following characteristics: signal power in range of −87.7 to −83.27 dBm, frequency in range of 3–17 GHz, and signal bandwidth in range of 140–160 kHz.
SR.5Power PortsThe SDR-MM shall have external ports to accept DC power (28 VDC, 3.3 VDC, 5 VDC, 12 VDC 15 VDC) from the Power Supply.
SR.610 MHz Frequency Reference PortThe SDR-MM shall have external ports to accept ‘10 MHz Frequency Reference’ from TFNG to discipline all LOs used in the conversion process.
SR.71 PPS Analog Signal PortThe SDR-MM shall have external ports to accept ‘1 PPS Analog Signal’ from TFNG to start the time (strobe) set into the FPGA timing registers.
SR.8System Sampling Clock PortThe SDR-MM shall have external ports to accept ‘System Sampling Clock’ from TFNG used to sampling strobe for ADC and reference for decimation in DDC.
SR.9GPS Epoch Time Message PortThe SDR-MM shall have external ports to accept ‘GPS Epoch Time Message Port’ from the External Host Computer/Processor set timing registers in the FPGA to the time from the GPS Msg.
SR.10Processed Digital Data PortsThe SDR-MM shall have external ports to send the processed data (digital data) to the External Host Computer/Processor for detection processing.
SR.11Dissipate the Heat Generated by Signal Processing FunctionThe SDR-MM shall dissipate the heat generated during the signal processing to the Communication Enclosure Air Environment (CEAE) to maintain the Average Electronic Surface Temperature (AEST) at or below 130 °C.
SR.12SDR-MM DimensionsThe SDR-MM dimensions shall not exceed 20.32 cm × 12.7 cm × 7.62 cm (8″ × 5″ × 3″).
SR.13SDR-MM Max MassThe total mass of the SDR-MM shall not exceed 3 kg (estimated based on similar SDR-MM).
SR.14SDR-MM Max Energy ConsumptionThe SDR-MM shall consume less than 100 watts (peak).
SR.15SDR-MM ElementsThe SDR-MM shall have an enclosure subsystem that can withstand an impact force of 100 KN (estimated based on the total weight of the SDR-MM and safety factor of 2).
SR.16Support Weight of SubsystemsThe SDR-MM shall have an Enclosure subsystem that can support the total weight of all other MM elements.
SR.17Support Weight and Provide Structural SupportThe SDR-MM shall mechanically be mounted to the Communication System Structure to support its weight and provide structural support.
SR.18Corrosion and Leak ProtectionThe SDR-MM shall protect itself and internal components from corrosion and leaks.
SR.19SDR-MM Max CostThe total cost of the SDR-MM shall be less than USD 15,000.
SR.20Accessing the Internal ComponentsThe SDR-MM shall allow easy access to all system components located inside the Enclosure that allows for component replacement and maintainability
Table 2. Summary of the four-assessment criteria of the three SDR-MM architectures.
Table 2. Summary of the four-assessment criteria of the three SDR-MM architectures.
Assessment CriteriaArch.1Arch.2Arch.3
Cr.1 (USD)10,08010,20515,265
Cr.2 (kg)1.882.122.79
Cr.3Max of 1 NB outputMax of 3 NB outputsMax of 2 WB outputs
Cr.4 (°C)129 °C127 °C113 °C
Cr.1: SDR-MM Cost (USD). Cr.2: SDR-MM Mass (kg). Cr.3: Signal Processing Performance—Number of Equivalent NB Outputs. Cr.4: SDR-MM Reliability—Average Electronic Surface Temperature (AES).
Table 3. Normalized Criteria weights based on SME inputs.
Table 3. Normalized Criteria weights based on SME inputs.
Cr.SME1SME2SME3
Cr.10.090.060.07
Cr.20.180.150.19
Cr.30.550.520.43
Cr.40.180.280.31
Table 4. Criteria scores for each alternative.
Table 4. Criteria scores for each alternative.
Arch.SMECr.1 ScoreCr.2 ScoreCr.3 ScoreCr.4 Score
SME10.570.470.200.17
Arch.1SME20.430.450.100.13
SME30.540.560.110.14
SME10.290.380.400.33
Arch.2SME20.430.450.330.51
SME30.300.320.440.43
SME10.140.150.400.50
Arch.3SME20.140.090.570.36
SME30.160.120.440.43
Table 5. Weighted criteria scores and overall composite scores across all SMEs.
Table 5. Weighted criteria scores and overall composite scores across all SMEs.
Arch.SME1SME2SME3Overall Score
Arch.10.280.180.240.70
Arch.20.380.410.411.20
Arch.30.350.420.361.13
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Share and Cite

MDPI and ACS Style

Albayati, M.G.; Dano, E.B.; Rajamani, R.; Thompson, A.E. A Model-Based Engineering Approach for Evaluating Software-Defined Radio Architecture. Systems 2023, 11, 480. https://doi.org/10.3390/systems11090480

AMA Style

Albayati MG, Dano EB, Rajamani R, Thompson AE. A Model-Based Engineering Approach for Evaluating Software-Defined Radio Architecture. Systems. 2023; 11(9):480. https://doi.org/10.3390/systems11090480

Chicago/Turabian Style

Albayati, Mohammed G., Eric B. Dano, Ravi Rajamani, and Amy E. Thompson. 2023. "A Model-Based Engineering Approach for Evaluating Software-Defined Radio Architecture" Systems 11, no. 9: 480. https://doi.org/10.3390/systems11090480

APA Style

Albayati, M. G., Dano, E. B., Rajamani, R., & Thompson, A. E. (2023). A Model-Based Engineering Approach for Evaluating Software-Defined Radio Architecture. Systems, 11(9), 480. https://doi.org/10.3390/systems11090480

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop