Architecture design is an important activity in the system engineering process. Many classic MBSE methodologies, e.g., object-oriented systems engineering method (OOSEM) [5], Harmony SE [6], Magic Grid [7], provide guidance for architecture design tasks. Based on these general methodologies, some in-depth research has been conducted on specific tasks in architecture design, such as architecture modeling, component retrieval and reuse, and architecture evaluation. Chen et al. [8] proposed a method for automated generation and evaluation of logical architectures. This method retrieves and combines components into feasible architecture solutions and selects the optimal one using multi-objective optimization. Gao et al. [9] proposed a set of domain metamodels and modeling patterns for communication satellite networks and optimized and improved the system architectures based on simulation. Fu et al. [10] imported SysML system design models into knowledge graphs to achieve model fusion and reuse and realized automated configuration of system architectures based on semantic retrieval. Cao et al. [11] proposed a software and physical synergetic architecture design method, in which the physical and software conceptual models are automatically generated from hybrid functional models based on ontological reasoning.

However, most of the architecture design methods in the MBSE originate from the top-down conceptual design methodology of engineering design, that is, the top-down functional decomposition structure is used as input, and the system architecture is generated from the bottom-up through component selection and integration [12]. However, these top-down architecture design methods are mainly suitable for design from scratch and hence cannot apply to the highly platform and product family-based design of RSS.

To further improve the reuse of existing design assets and shorten the delivery cycle, PLE has gradually attracted the attention of researchers in the MBSE field and formed a new research direction, MBPLE. Hugo et al. [13] divided the asset reuse strategy into three generations and gave the implementation framework of MBPLE using the Alstom Rolling Stock product line as an example. Young et al. [14] demonstrated the application of MBPLE method in Raytheon. The method defines various configurations using the PLE tool and transforms them into variant architecture models in the MBSE tool to support the subsequent design process. Bilic et al. [15] constructed a toolchain framework for integration of the variant management tools and MBSE modeling tools and verified its efficiency in the Volvo construction equipment product line. Tekinerdogan et al. [16] summarized the application experience and lessons of PLE in the field of physical protection systems (PPS) and proposed an MBPLE workflow suitable for the PPS product life cycle. Forlingieri [17] defined four dimensions of variability, namely co-variability in product, manufacturing and services, variability in the development lifecycle, variability in layers of abstraction, and variability in system hierarchy levels and analyzed their impact on the MBPLE process. Colletti et al. [18] proposed two variant modeling patterns and four comparison criteria to determine which pattern is best suited to model a certain product family. Forlingieri et al. [19] defined two variant modeling methods in SysML based on the application of MBPLE in Airbus. Arifin et al. [20] proposed a complete architecture design process combining MBPLE with genetic algorithms. This method generates a specific physical architecture model based on MBPLE configuration and uses a genetic algorithm to solve the component selection problem in this model. Wagner et al. [21] proposed a method to manage the variability inherent in application scenarios, system architecture, and the structure of the digital twin using MBPLE. Lameh et al. [22] integrated configuration management into feature models so that a versioned feature model is proposed. Wager et al. [23] extended the RFLP-framework by the viewpoint of variability so that variability models on different hierarchy levels can be linked to each other. Essoussi et al. [24] proposed an approach to migrate large legacy systems with variants designed in document-based ways to digital assets based on SysML extensions and plugins. Colletti et al. [25,26] reviewed recent work on variant management of simulation models and proposed an approach leveraging SysML and its variant modeling capabilities.

It can be seen that MBPLE is an emerging technology that has attracted extensive attention from researchers. However, existing methods mainly focus on how to apply MBPLE to individual design steps instead of streamlining the architecture design process. In addition, most of the work remains at the methodology level without computer-aided design tool support.

Since many domain-specific terms are introduced in MBPLE, extensions to the current general-purpose MBSE languages are required. Actually, in SysML v2, fundamental variability concepts have already been provided to facilitate model reuse at any level of design and maintenance of multiple variant configurations [27]. Epp et al. [28,29] analyzed the feasibility of using SysML v2 as a variant modeling language and proposed a variant modeling metamodel based on it. Besides the language architecture standardized by object management group (OMG) including unified modeling language (UML)/SysML, meta-object facility (MOF), etc., another important MBSE language is kombination of architecture model specificAtion (KARMA) [30,31], which provides a semantic specification to construct domain-specific metamodels and languages. Its main purpose is to formalize the semantics of various models to support their interoperability across the entire lifecycle. Since the proposed RSS-MBPLE approach is based on SysML v1.6, these advanced formalisms and languages can be investigated as our future work to migrate and adapt the approach to future demands.

The process of the MBPLE-based architecture configuration is shown in Fig. 7. The process is divided into two major sub-processes, i.e., domain engineering and application engineering. Domain engineering mainly constructs feature models, superset models, and the impact rules between them, thereby providing a basis for the generation of architecture variants. During the application engineering, users can give concrete configurations according to specific tasks and then the architecture variants can be automatically generated through the variant generation. The following is a detailed description of the steps in the process.

(i) Feature modeling. This step analyzes and abstracts the missions that RSS needs to achieve and builds a feature model based on the RSS-MBPLE profile. The architecture feature model $ {\mathrm{FM}}=\left\{{f}_{0},{f}_{1},\cdots \right\} $ contains a set of features that can describe the missions of the RSS. Each feature $ f=\left\langle {\mathrm{name}},{\mathrm{type}}\right\rangle $ is described by its name and value type. The value type of a feature can be Boolean, Integer, Real, Enumeration, etc.

(ii) Superset modeling. Superset models are built upon the general architecture of RSS platforms using RSS-MBPLE and RSS-arch profiles. The basic structure of the superset model $ {\mathrm{SM}}=\left(M,{\mathrm{VP}},\varPhi\right) $ is consistent with the usual SysML system model $ M=\left\{{e}_{0},{e}_{1},\cdots \right\} $ which can be regarded as a set of model elements. The only difference between SM and M is that any model element in SM can be attached to a set of VPs $ {\mathrm{VP}}=\left\{{{\mathrm{vp}}}_{0},{{\mathrm{vp}}}_{1},\cdots \right\} $ to indicate that it is a variable part of the model. $ \varPhi=\left\{\left({\mathrm{vp}},e\right)|{\mathrm{vp}}\in {\mathrm{VP}}\wedge e\in M\right\} $ represents the constraint relationships between the VPs and the model elements.

(iii) Impact rule modeling. The impact rules describe how the properties of the model elements in the superset model are determined by the values of the features. They essentially reflect the design knowledge and experience of designers. The impact relationships $ \varSigma =\left\{\left({\mathrm{vp}},f\right)|{\mathrm{vp}}\in {\mathrm{VP}}\wedge f\in {\mathrm{FM}}\right\} $ associate the features with the variant points. Since the variant points are associated with the model elements in SM through the constraint relationships $ \varPhi $, the feature values can determine the properties of the variable model elements in the superset model. The impact rules $ \varOmega ={\mathrm{FM}}\times \varSigma \to {\mathrm{SM}} $ describe how the features determine the model element properties in the superset model through the impact relationships.

(iv) Variant generation. Based on the models and impact rules constructed in the domain engineering, designers can set specific feature values according to specific missions. A configuration $ C=\left\{{c}_{0},{c}_{1},\cdots \right\} $ is a set of feature values $ c=\left\langle {\mathrm{name}},{\mathrm{value}}\right\rangle $. The architecture variant model VM_a can be automatically generated from the configurations by setting the values of the variable parts of SM according to the impact rules. This automated generation is supported by MBPLE tools.

The architecture model of RSS generated above only describes the types, numbers, and connection relationships of the system components but does not specify the concrete standalone products used in each component. Therefore, it is necessary to generate different combinations of the standalone products from the architecture variant model and compare and select the optimal one according to the system indicators. One combination of the standalone products is the so-called solution. The process of solution selection based on MBPLE is shown in Fig. 8. Since it also follows the MBPLE idea, the overall workflow is similar to Fig. 7.

The process contains four major activities.

Step 1　Feature and superset generation. The designers build a solution feature model and the superset model based on the architecture variant model and the standalone product models in the reusable model repository;

Step 2　Product solution generation. The designers generate multiple feasible solutions based on the standalone products in the repository and calculate the indicators of each solution;

Step 3　Solution comparison. Through the solution comparison based on multi-indicators, the optimal solution can be selected by designers manually;

Step 4　Variant generation. The solution configuration is generated based on the optimal solution and the variant model of the final product design solution is automatically generated through the variant generation step.

Thanks to the aforementioned architecture variant model and the standalone products model repository, Step 1 and Step 2 can be automatically completed through interactive algorithms, which are explained in detail in the following sections. And since Step 4 is already implemented by MBPLE tools, the whole workflow is highly automated and efficient.

The RSS control subsystem is a typical complex system. It is mainly involved in the attitude and orbit control of the entire satellite. It has complex structures and functions, fixed common architectures, and rich specific configurations [34]. It works with the propulsion subsystem to complete the attitude and orbit control of the satellite in various working modes during the on-orbit period and other related tasks in accordance with the payload working requirements. The general configuration of the RSS control subsystem is shown in Fig. 9. It is mainly composed of three parts, i.e., controllers, sensors, and actuators. The identifier after the name of each component indicates the number of configurable units. For example, 0-1 Sun Sensor[0-*] means there can be none or many 0-1 Sun Sensors in the system.

Based on the general architecture, as shown in Table 1, according to specific application scenarios of RSS, they can be divided into several typical configurations, such as low-orbit stable, low-orbit agile, high-medium-orbit stable, and high-medium-low-orbit agile. Taking the low-orbit stable RSS as an example, its typical configuration is shown in Fig. 10. The typical configuration of sensors is star sensor×3, gyroscope×3, digital sensor×1, analog sensor×5, infrared earth sensor×2; the typical configuration of actuators is momentum wheel×5, solar panel drive mechanism×2, magnetic torquer×3; the typical configuration of controllers is central control unit×1 and drive control unit×1.

After determining the architecture configuration of the control subsystem, it is also necessary to select a concrete standalone product for each component. For example, Table 2 shows a list of available star sensor products for low-orbit RSS.

The basis for selecting a standalone product is the typical indicators of the control subsystem, such as weight, attitude determination accuracy, attitude pointing accuracy, maneuverability, and stability. The decomposition of each system indicator is shown in Fig. 11.

It can be seen that the system indicators are mainly impacted by the indicators of the standalone products. Therefore, using the decomposition relationship and control theory, the mathematical relationships between the system-level indicators and the standalone product indicators can be given. Based on these mathematical equations, the indicators of various product design solutions can be calculated and compared so that the optimal one can be selected.

From the analysis of the RSS control subsystem, it can be seen that it has the characteristics of complex architecture and diverse constraints. Considering it has a strong inheritance but rich specific configurations, it is suitable to leverage the MBPLE principles to support its architecture design. The RSS-MBPLE approach including two phases is illustrated in the following two sections. The SysML platform used in the case study is Cameo System Modeler 19.0. The two algorithms are also implemented as plugins to be seamlessly embedded in the design process.

The purpose of the control subsystem architecture configuration is to generate architecture variants based on the typical configurations of the control subsystem according to the missions, e.g., the low-orbit stable RSS architecture. The process is shown in Fig. 12.

The steps of architecture configuration are as follows:

(i) According to the missions of the RSS, extract the two features, i.e., orbital altitude and maneuverability and construct the feature model shown in Fig. 12(a);

(ii) Construct the superset model based on the general configuration of the control subsystem shown in Fig. 9 and create variant points according to the variable parts as shown in Fig. 12(b);

(iii) Establish the impact relationship and impact rules between features and variant points. For example, the rule if(orbitalaltitude=‘loworbit’){0−1solarsensor.Multiplicity=0} means that when the orbital altitude in the feature model is low orbit, the number of 0-1 solar sensors in the architecture variant is 0; the rule if(maneuverability{=}‘stable’){actuator.Type=momentumwheel} means that when the maneuverability in the feature model is stable, the actuator type in the architecture variant is momentum wheel.

(iv) Since the above process establishes the impact rules between the feature model and the architecture superset model, when a specific configuration is given, the corresponding architecture variant can be automatically generated following the rules. For example, given the low-orbit stable configuration in Fig. 12(c), the architecture variant shown in Fig. 12(d) can be automatically generated.

Based on the low-orbit stable architecture, designers can make specific selections for the standalone products from the standalone product model repository to generate the final product design solution.

(i) Automatic generation of feature and superset models for product selection

Since the standalone product selection still adopts the MBPLE concept, it is necessary to construct the feature model and superset model for this process. The feature and superset models can be automatically generated following Algorithm 1. The whole process is illustrated in Fig. 13. The input of the algorithm is the low-orbit stable architecture variant model shown in Fig. 12(d) and the standalone product model and constraint repository. They are also illustrated in the upper part of Fig. 13.

The first output model is the Solution superset model as shown in Fig. 13(b). It is identical to the architecture variant model except that some components whose multiplicity is greater than 1 are split into multiple components since they need to be realized by different standalone products. For example, Gyro whose multiplicity equals 3 is split into two components, i.e., Fiber optic gyro and Mechanical gyro to support the independent selection of the two. In addition, constraints (such as momentum wheel combination 12345, etc.) and indicators (such as pitch maneuverability, yaw maneuverability, and roll maneuverability, etc.) are manually added to the superset model. The final solution superset model contains 17 VPs, used to support the selection of different components and constraints.

The second output is the Solution feature model as shown in Fig. 13(a). The features have one-to-one correspondences with the VPs in the superset model. The possible values of each feature are generated by scanning the standalone product repository. For example, there are four products that can implement Momentum wheel, e.g., High torque 350/25 fly wheel 1A, Integrated 125 Nms high angular momentum flywheel, etc. They constitute an enumeration 07 Momentum wheel Type, which is set as the type of the feature Actuator selection.

The third output is the impact rules between features and VPs. They simply reflect the mappings between feature values and standalone products, e.g., If(Actuator selection=‘High torque 350/25 fly wheel 1A’){Actuator.Type=High torque 350/25 fly wheel 1A}.

(ii) Product solution generation and comparison

Following Algorithm 2, by inputting the Solution superset model shown in Fig. 13(b) and the standalone product repository, all the feasible standalone product combinations can be automatically generated. They are represented as instances of the solution superset model. Fig. 14 shows five solutions with parameters.

The key indicators of the solutions can be calculated according to the parameters of standalone products. This calculation is automated by running the instance table against the parametric diagrams defining the calculation formulas as shown in Fig. 13(c). As shown in Fig. 15, the key indicators of various solutions are calculated. By comparing the indicators, Solution 5 is selected as the optimal solution.

(iii) Solution variant generation

After obtaining the optimal solution, i.e., Solution 5, the feature model can be instantiated and configured according to this solution as shown in Fig. 16(a). According to this configuration, the solution superset model can be transformed into a specific solution variant corresponding to Solution 5 as shown in Fig. 16(b).