1. Introduction
Product Line Engineering (PLE) is a systems and software engineering approach that focuses on creating a family of related products with managed variability and commonality (Reference Clements and NorthropClements & Northrop, 2002). Rather than designing each product individually, PLE allows the systematic reuse of core assets across a product line, achieving efficient and scalable production. This reuse is centred around defining a set of common and variable features to address the needs of different products while maintaining consistency and quality across the line. PLE is widely applied in industries requiring high adaptability, such as automotive, aerospace, defense, and software, where tailoring products to different configurations or markets is crucial (Reference ForlingieriForlingieri, 2022).
The integration of Product Line Engineering (PLE) with Systems Engineering (SE) has become a critical challenge in the development of complex systems, particularly those requiring high variability across product lines. A Systematic Literature Review (SLR) conducted by the authors has identified several gaps and challenges that have motivated the development of a novel model for addressing variability in PLE (Reference Lameh, Dubray and JankovicLameh et al., 2024a). Key findings from the SLR highlight the need for a more integrated, multi-perspective approach to PLE, where the problem definition and the solution design are distinctly separated. In fact, PLE largely emphasizes single-level approaches as current studies focus on either architectural modeling, dealing with physical components, or software product line engineering, concentrating on software features. However, the need for a multi-layered approach integrating PLE with SE has become increasingly apparent, particularly for complex systems with high variability demands. In SE, modeling across various layers or viewpoints is a fundamental process (Góngora et al., Reference Góngora, Ferrogalini, Moreau, Boulanger, Krob, Morel and Roussel2015; Kortwinkel, Reference Kortwinkel2020). A field study at Renault validated the need to tackle variability from various viewpoints (Reference Lameh, Dubray and JankovicLameh et al., 2024b).
Hence, there is a necessity for multi-layered modeling. This research tries to address this gap and proposes an integrated, multi-perspective approach developed in coherence with ARCADIA’s MBSE method. It encompasses different levels to address this gap.
This paper is structured as follows: After the current introduction, section 2 reviews the literature on PLE definitions, complexity, and the MBSE ARCADIA method. Section 3 outlines the research methodology. Section 4 presents the proposed FODA-based variability modeling approach integrating operational, functional, and constructional viewpoints. It also applies this approach to a Renault case study on Advanced Driver-Assistance Systems (ADAS). Section 5 discusses the findings and implications, and Section 6 concludes with key insights and future directions.
2. Literature review
This section provides a comprehensive list of definitions related to PLE terminology. The main references reviewed converge on similar principles underlying PLE. By analyzing and consolidating their definitions, we derived a unified perspective, presented in Figure 1. This figure and subsequent discussion synthesize the core elements of PLE definitions, offering a cohesive framework that integrates insights from the literature.
Figure 1. Ontology of PLE
(Reference BoschBosch, 1999) emphasizes PLE as a means to achieve systematic reuse across software systems. (Reference Clements and NorthropClements & Northrop, 2002) define PLE as a structured approach to managing a family of systems through shared assets and planned variability. (Reference Krueger, Charles and Van Der LindenKrueger, 2002) highlights the role of feature modeling in organizing and capturing commonalities and variabilities. (Reference Weiss and LaiWeiss & Lai, 1999) focus on domain-specific architectures as a cornerstone of PLE. (Reference Pohl and LindenPohl et al., 2005) expand on variability management as a critical enabler for efficient product derivation. (Reference TrewTrew, 2005) and (Reference Krueger and ClementsKrueger & Clements, 2017) underscore the practical applications of PLE, integrating processes, tools, and frameworks to address complexity in product development. Together, these works form a comprehensive ontology for understanding PLE. This paragraph presents how these main references define PLE synthesized into a unified framework by merging key concepts from all sources; as such, each definition reflects the collective insights of these foundational works rather than a single reference.
In PLE, variants and versions play distinct roles. A variant is an alternative form of an asset that represents variations in space, enabling products to be customized for different requirements or contexts within the product line. Conversely, a version of an asset indicates a point in time, representing the evolution or refinement of an asset to address updates or improvements, hence capturing variations over time. Together, variants and versions support both the adaptability and sustainability of products within a product line. The central concept of PLE lies in managing assets. It is the reusable components that collectively contribute to one or multiple products. These assets encompass a range of artifacts such as software modules, hardware elements, architectural components, and documentation. Assets are categorized into three primary types:
1. Common assets form the core of the product line and are used across all products, representing the shared features and functionalities that define the line’s identity. This group addresses the commonality aspect of PLE.
2. Variable assets contribute to the customization options within the product line. These assets may be used in some products but not others, providing the flexibility required for different configurations and representing the variability aspect.
3. Specific assets are unique to a single product within the product line. They address specialized requirements or characteristics for a particular product, capturing the specificity aspect and distinguishing products in cases where unique functionalities or features are essential.
By categorizing assets in this way, PLE ensures a structured approach to managing the complexities of product variations, allowing for efficient scaling, adaptability, and quality control. This multi-tiered structure—incorporating commonality, variability, and specificity—provides a robust framework for addressing diverse product needs while maximizing reuse across the product line.
Figure 2. Definitions of assets in PLE
In the literature, one of the most used modeling approaches is FODA modeling. The product-line variability is described in a variability model, commonly known as a feature model. This model provides a structured representation of the diversity within a product line, organized through features or variability inductors. A feature is a defining characteristic, that captures the aspects that distinguish one product from another within the product line. Thus, the variability model is fundamentally structured around these variability inductors. Additionally, variability constraints within the model define formal relationships between two or more features. These constraints either enforce or limit the use or reuse of assets across products, shaping how assets are applied and reused within the product. The model represents product family variability, already presented comprehensively in prior work (Lameh, 2023). This model is aligned with the Feature-Oriented Domain Analysis (FODA) method, employing a feature model to represent variability. Key elements such as features, notations, construction of parent-child relationships, and technical constraints are detailed, as well as the integration of configuration management for systematic control. However, the SLR conducted showed that a notable gap remains when applying this model to complex systems, as multiple layers (operational, functional, and constructional view) are often not fully addressed in conventional FODA-based approaches (Reference Lameh, Dubray and JankovicLameh et al., 2024a). The features will be used in variation points representing the applicability of a specific asset, determining its presence or absence within a particular product instance based on the feature selection. This selection process, known as a variability configuration, enables the creation of a partial or complete product instance by choosing or omitting specific variability inductors. As a result, this configuration process filters assets, ensuring that only the assets relevant to the selected variability inductors are included, shaping the final product in alignment with defined variability options.
3. Research methodology
This research followed a mixed-methods approach, combining academic theory with practical implementation (Reference Dawadi, Shrestha and GiriDawadi et al., 2021). After a thorough literature review, iterative workshops were conducted to propose and refine models, which were then validated with subsystem owners. Interdependencies between subsystems were analyzed to ensure model applicability. A committee of validation, composed of subject matter experts, reviewed the models to ensure rigor. Theoretical work and practical implementation progressed in parallel, with careful separation to avoid bias, while also validating each other. The models were deployed in industry tools, identifying variability points for future use, ensuring both scientific precision and practical relevance.
4. Proposition of a PLE FODA model
4.1. Methodology: ARCADIA
Model-Based Systems Engineering (MBSE) is an approach to systems engineering that emphasizes the use of models to support system requirements, design, analysis, verification, and validation activities (Reference Góngora, Ferrogalini, Moreau, Boulanger, Krob, Morel and RousselGóngora et al., 2015). MBSE enhances the ability to manage complexity and improve communication among stakeholders by providing a clear, visual representation of the system. By integrating various aspects of system development, MBSE facilitates better decision-making and increases efficiency throughout the project lifecycle. Moreover, the MBSE approach can be beneficially applied to develop a new sharing concept. Several concepts and methodologies in the MBSE field aim to achieve this goal. (Reference Baron, Grenier, Ostapenko and XueBaron et al., 2023) synthesized MBSE methods and tools: OOSEM, OPM, Pattern-Based Systems Engineering, NASA JPL State Analysis Methodology, BPMN, IBM Harmony, Vitech MBSE Methodology, and ARCADIA. ARCADIA (ARChitecture Analysis & Design Integrated Approach) provides a highly structured approach with an integrated methodological guide (Reference Cichocki, Landschützer and HickCichocki et al., 2022). It focuses on the analysis of the needs, the functional architecture, the logical architecture, the behavioral analysis, and the validation and verification (Reference Baron, Grenier, Ostapenko and XueBaron et al., 2023). Based on a standard SE methodology, started practically in 2005 by Thales (Reference GérardGérard, 2005), ARCADIA allows for effective management of high system complexity (Reference Cichocki, Landschützer and HickCichocki et al., 2022). It is flexible, understandable, has good traceability, and is available as an open source (Reference Baron, Grenier, Ostapenko and XueBaron et al., 2023). (Reference VoirinJ.-L. Voirin, 2018) defines it as follows: “ARCADIA is thus a structured engineering method for defining and verifying the architecture of complex systems. It promotes collaborative work among all key players, often in large numbers, from the engineering (or definition) phase of the system and subsystems, until their Independent Verification and Validation (IVV)”. Note that ARCADIA was also standardized by AFNOR, the French Standardization Association (Association Française de Normalisation). ARCADIA employs a top-down approach using four layers of working levels: operational need analysis, system need analysis, logical architecture, and physical architecture. The top level is the most abstract, progressively becoming more detailed at each subsequent layer (Reference VoirinJ. Voirin, 2008) (Figure 3). This method ensures a distinct separation between identifying needs, and problems (through operational need analysis and system need analysis) and obtaining solutions (through logical and physical architectures) (Reference RoquesRoques, 2016). It also divides the system architecture phase of the V cycle into a sequence of four distinct stages. These stages correspond to the four levels shown in Figure 4 (Reference Baron, Grenier, Ostapenko and XueBaron et al., 2023). (Reference RoquesRoques, 2016) mentions three equivalently important mandatory interrelated activities (i) need analysis and modeling, (ii) architecture building and validation, and (iii) requirement engineering. Table 1 summarizes the four levels of layers described.
Figure 3. Four stages of V-cycle (Reference Baron, Grenier, Ostapenko and XueBaron et al., 2023)
Figure 4. ARCADIA by (Reference RoquesRoques, 2016)
Table 1. ARCADIA’s layers
ARCADIA is a logical representation and an abstraction of the system, providing a decomposition of the system’s objectives. It is primarily based on needs definition, then functional analysis, followed by the allocation of these functions to components, i.e. top-down then bottom-up (Reference VoirinJ.-L. Voirin, 2018).
4.2. FODA-based PLE model
We propose to build PLE model constructions based on the ARCADIA approach, developing three views. At each of these three levels, features are defined and analyzed to ensure alignment with core needs rather than being solution driven. Variability is systematically evaluated, with each feature’s necessity questioned using the “5 Whys” technique. This approach ensures that the features at each level are thoroughly justified, addressing fundamental requirements at every stage of the modeling process. In discussions with experts, we identified several levels of variability features that need to be managed (see Figure 5): (i) Operational Variability: This level addresses variability arising from diverse operational needs. For example, a vehicle may need different driving modes (e.g., eco, sport, or off-road), each requiring tailored features, (ii) Functional Variability: At this level, multiple functions may fulfill a single operational requirement. For instance, both radar and camera systems can detect obstacles, but their use may depend on performance or environmental constraints, and (iii) Constructional Variability: This level involves variability in components that implement specific functions. For example, different sensors may technically satisfy a detection function, but the cost or added value (e.g., durability or precision) dictates the final choice.
Figure 5. Variability model proposed
Managing these levels introduces several challenges, as highlighted by prior research based on interview studies. Key issues include the need to limit unnecessary expenses by avoiding non-essential variability, controlling complexity to reduce integration costs, and ensuring that variability contributes genuine operational value rather than being solution driven. These challenges emphasize the importance of systematic evaluation and strategic decision-making in variability management.
Note that for each feature (variability inductor) at any level, a detailed data model is developed. This includes attributes such as a unique ID, a description to clarify its purpose, multiplicity, and a status for configuration management. These attributes collectively ensure precise tracking, representation, and control of each feature throughout the product line, facilitating consistent management of variability across configurations.
In modeling, two primary types of constraints are essential to accurately represent dependencies and limitations within a product line: technical constraints and market constraints. Technical constraints define interdependencies among components that ensure proper functionality, specifying how certain features or components rely on others to operate effectively. Market constraints, on the other hand, stem from market-specific requirements or restrictions, shaping product configurations according to regional, regulatory, or customer demands. These constraints are typically incorporated into the structure of the product line to refine and tailor offerings, ensuring that each configuration aligns with both technical necessities and market needs.
4.2.1. Operational view (why?)
The operational level focuses on the system’s mission, objectives, and interactions with its environment. It seeks to answer the question of why the system is needed, clarifying the external services the system must provide. In this view, the system is treated as a black box, abstracting internal details, and concentrating on its external behavior. The operational view defines the system’s purpose and how it interacts with external entities, ensuring a clear understanding of its role within a broader ecosystem. This phase is crucial for aligning the system’s goals with stakeholder needs and market demands. It is true that in an operational view, a system may have one or several missions.
In this view, we propose to organize missions into generic, elementary, and variant forms. This organizational structure considers missions as variants, which will be modeled in terms of features. This approach enhances flexibility and provides a clearer understanding of the system’s capabilities.
Generic Mission refers to a service that provides value to an external actor or user. Mission Variant describes a specific alternative of a vehicle mission, defined by a subset of use cases that apply to a fully configured vehicle. The variant depends on the system’s overall features and is composed of various elementary missions. An Elementary Mission is the fundamental building block of a generic vehicle mission, representing a distinct and well-defined characteristic of its overall functionality.
4.2.2. Functional view (what?)
After determining the system’s mission, the functional view focuses on the internal mechanisms and functionality required to achieve the system’s objectives. The features will be detailed at a finer grained to answer the question of what the system needs to do by identifying and decomposing the necessary functions that directly relate to the interactions defined in the operational view. This view ensures that each system function is mapped to a specific operational requirement, allowing for a structured approach to variability by defining both common and variable functions across different product lines. From a functional view, certain functions are consistently present across all variants of the mission, while others may vary based on design constraints and specific user needs. A more granular description of variability is needed.
4.2.3. Constructional view (how?)
The constructional (organic or structural) view, often referred to as the white box, addresses the how by detailing the system’s architecture and technical design. It specifies how the identified functions will be realized through specific technologies, components, and subsystems. This view provides the blueprint for implementing the system, ensuring that the design is flexible enough to accommodate both shared and variant features across different product configurations. By focusing on the constructional aspects, this level facilitates the management of physical and technical variability, ensuring that product variants can be built efficiently while maintaining consistency and quality. In system architecture, both hardware and software play crucial roles. While software is generally easier to manage and less costly to modify, hardware components introduce a layer of complexity, especially when determining how a function is realized. Variability within architecture often arises due to factors like the availability of different suppliers, the natural evolution of components over time, or the emergence of new components proposed to the market. A single physical component can be designed to perform multiple functions. Within an MBSE approach, functions are allocated to components, and thus components are managed separately within a Product Breakdown Structure (PBS). This PBS model also captures component variability. Dependencies between models are established to maintain coherence.
4.3. Process
This variability management process, implemented at Renault, follows a structured approach, combining top-down and bottom-up methodologies to ensure comprehensive and practical variability control across subsystems. Renault, as a major car manufacturer, uses this approach to model and deploy PLE in a way that aligns with the practices of the broader automotive industry. Although sensitive information is withheld, the process described here reflects the genuine application of these principles.
These are the main process steps for modeling:
Engage with subsystem owners and describe and model variability: The initial step focuses on engaging with subsystem owners, who are responsible for identifying and describing the variability within their respective subsystems. They define this variability according to the specific missions that the subsystem is designed to fulfill. This top-down approach allows for an organized description of variability, starting at the operational level and gradually moving through the functional and architectural layers, ensuring that all variations for the system in question are fully understood. Concurrently, the process includes mapping historical variability and future trajectories to encompass both established configurations and emerging requirements.
Define inter-subsystem dependencies: Once the subsystem-level variability is captured, the focus shifts to inter-system dependencies, recognizing that the relationship between subsystems is essential to building a coherent variability model. This stage involves iterative exchanges between subsystems to capture the interdependencies and constraints, creating a unified view across the product line. As the modeling of variability progresses from subsystem to subsystem, the dependencies solidify the relationships and highlight any constraints that must be managed across different subsystems.
Incorporate bottom-up input from market and product teams: Simultaneously gather input from marketing and product definition teams to reflect evolving market demands and new product features. In parallel to this top-down approach, a bottom-up component complements the process, particularly to address demands stemming from product design and market requirements. Marketing and product definition teams, who are instrumental in shaping the desired product features, actively contribute by requesting specific configurations that support new or enhanced missions. This dynamic between engineering and product conception teams ensures that market needs are consistently incorporated into the engineering design, bridging the product requirements with technical feasibility. Therefore, the top-down identification of variability by engineers is balanced by the bottom-up needs of product and market teams, creating a balanced, comprehensive variability model.
Parallel Activities; Variation Points and Configurations: The culmination of these efforts is the configuration stage, where variability models, including defined variation points, are consolidated into configurations that meet both engineering solutions and market demands. This merging of top-down and bottom-up perspectives allows for thorough cross-verification, ensuring that the variability model is consistent and aligned with both technical and market expectations. In fact, following this modeling process, a variation point implementation phase will ensue. This phase entails tagging model elements by variation point, identifying where choices or options exist in the subsystem. In parallel, configuration management will be executed to define valid product instances. With variation points identified and configurations mapped, the model will be filtered, progressively refining from a comprehensive full 150% model to a partially defined 120% model that reflects relevant options, and ultimately to a fully defined 100% model representing the final, precise product configuration needed. This structured progression from modeling to filtered configurations sets a foundation for efficient, controlled PLE.
Ensure Model Consistency and Coherence and do the updates, especially after the deployment (once Variation Points and creating configurations are done).
4.4. Application
For practical illustration, we apply this approach, and the process described in 4.3. to the Advanced Driver Assistance System (ADAS) focusing on park assist. This real-world example provides a relevant context for demonstrating the application of our feature model-based PLE approach. The deployment of the proposed methodology is outlined through a step-by-step implementation within this subsystem, showcasing its adaptability and effectiveness in addressing complex variability requirements. The variability modeling begins by identifying missions, not components; for instance, a clear operational distinction is made between a 360-degree surround-view function and a rear-view function. Functional variability is introduced only if specific performance needs or quality priorities demand it, as with functions requiring diverse capabilities for each mission. Finally, at the component level, the decision to use specific camera types, for instance, follows only if variability in components is necessary to support the required operational mission effectively. Thus, the proposed method ensures that variability is rooted in mission-based differentiation, optimizing both functionality and cost efficiency. Following is the description of the variability we got while engaging with the perimeter’s owner.
Operationally, the ADAS Park Assist subsystem can offer different park assist missions: (i) Ultrasonic Park Assist (UPA): This can exist in two variants: rear-only or rear-and-front. These variants are formed by incremental elementary missions, (ii) Camera Park Assist (CPA): It can come in two variants: rear-view camera or around-view camera, where only one variant is installed on the vehicle, representing alternative missions, and (iii) Automatic Park Assist (APA): This can also exist in two variants: hands-free parking and/or remote parking. A vehicle could have one or both variants, representing different elementary missions that form the overall mission.
As an example of constraints, the dependency of APA REMOTE on CPA AROUNDVIEW for optimal operation is a technical constraint, modeled as a logical condition to ensure subsystem compatibility. In contrast, the decision to avoid offering UPA FRONT without UPA REAR, while technically feasible, is a marketing constraint defined in the product structure.
Functionally, in the context of ADAS, particularly within 360-degree surround-view subsystems, the Rear-View Integration Function, for example, is a standard feature that automatically switches to the rear camera view when the vehicle is in reverse. This function is essential for enhancing driver awareness during low-speed maneuvers and is included in every variant that incorporates an Around View Monitor (AVM) system. Conversely, two examples of functions that may or may not exist depending on system configurations and design constraints are the Obstacle Detection and Alerts Function and the Dynamic Guideline Adjustment Function. The Obstacle Detection and Alerts Function utilizes sensors to identify potential hazards in the vehicle’s path, providing real-time warnings to the driver; however, this feature may be excluded in entry-level models to reduce costs. Similarly, the Dynamic Guideline Adjustment Function, which adjusts visual guidelines based on steering input, enhances parking accuracy but may not be implemented in all variants due to additional sensor requirements or cost considerations. This distinction highlights how the necessity of certain functions can be influenced by the intended use case and targeted market segment, while other functions are determined by design and cost constraints.
From a constructional point-of-view, if the CPA function is selected, this choice automatically includes a camera component essential to this feature. Further, ODAF may require a specific camera. Additional levels of component variability, such as variants specific to certain countries or partners, are incorporated as needed. However, in most cases, a new hardware component simply replaces its predecessor as an updated version. This allows for managed evolution within the architecture without adding unnecessary diversity unless justified by external factors like region-specific requirements.
Figure 6. ADAS park assist VM application
5. Discussion
The global process emphasizes variability detection and formalization, aiming to define variability in a structured way. While some variability is embedded in system models, it can remain unstructured without a PLE approach. Centralizing these models into a unified, standardized structure is critical. (Reference KempKemp, 2024) states that modeling’s purpose is to define and analyze systems holistically, supporting problem definition and system-level analysis. This unified model enhances understanding and managing variability across the product line, addressing variability systematically throughout the system’s lifecycle. By viewing the system operationally, functionally, and constructively, the model bridges the gap between PLE and SE, ensuring optimal variability management. Moreover, the variability modeling approach follows a structured, top-down methodology. Variability should be addressed starting at the operational view to minimize unnecessary diversity at the functional and architectural levels. Operational needs are examined first to determine if variability is justified. If variability does not offer distinct operational benefits, it should be minimized. Variability can be introduced at the functional level if multiple functional needs arise, but architectural variability should only occur when dictated by external constraints, such as new components or supplier changes, to avoid unnecessary costs. In variability modeling, a trade-off exists between high-level variability and integrating configuration directly into the model. Early modeling simplifies configuration but can limit flexibility. Alternatively, a modular, elementary feature-based approach allows flexibility as needs evolve. Our study shows that for stable, long-lasting variability, it’s beneficial to resolve it early within the model. For features with potential for significant evolution, decomposition into elementary features is preferred, accommodating future variability. This ensures flexibility while maintaining the integrity of features, supporting modularity without altering their core identity. Note that, this approach was validated by modeling various automotive subsystems (more than 25), i.e. safety, chassis, connectivity, and powertrain… Across these diverse subsystems, consistent modeling patterns emerged through an iterative process, progressively refined as the modeling advanced. Feedback was collected through iterative reviews with experts at different levels e.g. vehicle, domain, subsystem, and product expression levels, etc. Iterative workshops were conducted at regular intervals, integrating domain-specific expertise to refine modeling accuracy. Expert validation sessions included structured reviews, ensuring consistency across subsystems and abstraction levels. Feedback loops were implemented through periodic assessments, enabling continuous refinement of modeling patterns. Cross-functional teams contributed insights, facilitating convergence toward a standardized approach. Quantitative metrics, such as model completeness and consistency checks, were employed to assess validation efficacy. Validation ensured alignment across all levels, with efforts focused on synchronizing inputs from all stakeholders. This approach allowed for the standardization of patterns over time, ultimately resulting in a comprehensive catalog that effectively addressed all requirements without necessitating additional patterns. Due to confidentiality constraints, specific details cannot be fully disclosed. The ADAS example provided illustrates the formalization of this approach, showcasing its adaptability and ensuring confidentiality.
6. Conclusion
Through iterative feedback loops, the proposed model enhances the ability to configure product lines dynamically, reduces design and development time, and supports continuous improvement. Moreover, incorporating robust configuration management practices throughout these levels ensures that product variants are consistently aligned with stakeholder requirements and market needs. However, in implementing feature model-based variability management within PLE, several challenges emerged, each requiring targeted solutions to maintain the integrity and efficiency of the approach. One primary challenge involved aligning feature models across the three levels without creating redundancy or inconsistency. A layered integration strategy was adopted to address this, ensuring that each level retains unique, role-specific features while aligning with overarching product goals. Another challenge was managing the complexity of dependencies, where multiple features interact across levels. This was mitigated by employing constraint-handling techniques within the feature models to maintain compatibility and resolve conflicts. Where scalability posed a concern, modular feature modeling practices were implemented, allowing incremental updates without overhauling the entire model. These solutions collectively enabled a robust, adaptable framework for PLE variability management in complex, multi-level systems.
In conclusion, this paper presents a novel, integrated multi-layered approach to PLE based upon ARCADIA’s MBSE method across operational, functional, and constructional levels. This model provides a structured, scalable approach for handling the complexity inherent in modern product lines, particularly in industries like automotive, where variability is a critical factor for success. Through a systematic analysis and practical implementation using real cases at Renault, experts highlighted the effectiveness of this approach in addressing complex variability challenges inherent in PLE for systems with high adaptability demands. Given that the automotive industry is among the most intricate domains, this methodology is inherently adaptable and can be extended to other industries or complex systems facing similar challenges in variability management. Our findings suggest that a multi-perspective, structured variability management method supports both efficiency and scalability in product development through the formalization and the limitation of variability and could improve product development process. This method also enables a more flexible and comprehensive SE architecture, which is essential for sustaining complex evolution. Future work will explore model solving and AI.
Open access
