Overcoming Challenges in the Transition Towards Battery Electric and Software-Intensive Modular Heavy-Duty Vehicles

Abstract

The automotive industry is undergoing a significant transition, where the development of Battery Electric Vehicles (BEV) and the increasing use of intelligent vehicle functions are transforming vehicles into advanced Cyber-Physical Systems. For heavy-duty OEMs, this transition challenges a Product Development (PD) heritage inherent in an ecosystem of established processes, IT systems, and organization structures. This study primarily comprises semi-structured interviews, conducted at a heavy-duty OEM, and a focused literature search. The study contributes by the following: (i) identifying key PD challenges in the ICE–BEV transition, (ii) outlining obstacles in adopting Model-Based Systems Engineering (MBSE) for managing architectural complexity, and (iii) synthesizing recommendations for architecture-driven collaboration. Interview findings, highlighted intertwined challenges such as fragmented architecture descriptions across physical and software domains, weak continuity between early-phase system context and detailed design, and collaboration constrained by inconsistent terminologies, strained communication channels, and manual reconciliation of architectural information through documents and disconnected tools. These factors hinder function-component traceability and concurrent development across domains. While MBSE is often recommended to address such issues, practical obstacles are noted, including trade-offs between modeling effort and fidelity, limited support for early spatial layout integration, difficulties in bridging physical and software architectures, and the limited integration of document-based practices preferred in early conceptual phases. Based on these insights, the study recommends architecture-driven collaboration anchored in a federated vehicle-architecture description, supported by a distributed systems-engineering function. A layered development approach combining document artifacts with progressively rigorous MBSE is advised for early-phase agility, later-stage traceability, and structured information flow.

1. Introduction

The automotive industry thrives on continuous innovation, driving fierce competition. Several factors contribute to the competitiveness, including similar product offerings, volatile markets, overcapacity, and cost pressures, stemming from new technologies, legislation, and ongoing improvements [1]. Currently, the industry is transforming globally to develop sustainable, autonomous, and connected vehicles. Sustainability initiatives, such as reducing carbon dioxide emissions, have accelerated the development of Electric Vehicles (EVs). New market opportunities arise for automotive Original Equipment Manufacturers (OEM) who invest in research towards EVs, such as fuel cell and Battery Electric Vehicles (BEV).

From a strategic viewpoint, the transition from traditional internal combustion engine (ICE) vehicles to electric vehicles (EVs) is apparent, although the pace of change is slower for heavy-duty vehicles compared to passenger cars [2]. From a legacy viewpoint, many OEMs developing heavy-duty ICE vehicles carry a Product Development (PD) heritage, connected to an ecosystem comprising key entities such as its processes, IT systems, and organizational structures. Over decades of optimization, the product’s design stabilizes, PD processes evolve into best practices, IT systems achieve legacy status, and organization structures become rigid. From a technology viewpoint, in recent decades, a pivotal shift has occurred with embedded systems enhancing the capabilities of vehicles. Modern ICE vehicles, including heavy-duty vehicles, are Cyber-Physical Systems (CPS) that pose challenges during PD [3]. With the advent of EVs, the role of advanced embedded systems has grown significantly to enable intelligent vehicle functions. Systems such as battery management and advanced driver assistance systems play a crucial role in enhancing vehicle efficiency, safety, and autonomy, making EVs examples of advanced CPS. The OEMs potentially face challenges to stay competitive during the ICE to EV transition if the PD ecosystem does not provide the support required to manage the product complexity during the rapid development of EVs.

Scania, a brand within the Traton Group offering heavy-duty transport solutions, has a long heritage of ICE vehicles from generational shifts and incremental enhancements in its Modular Product Portfolio (MPP) developed over decades. The company is currently undergoing a transformation in both its product offerings and organizational initiatives to develop and manufacture BEVs. This transformation aims to address diverse customer needs while advancing the evolution of the MPP and reinforcing the modular strategy. Looking at key viewpoints for automotive OEMs, (i) the inherent PD heritage, (ii) the strategic transition towards electric vehicles, and (iii) the increasing focus on advanced embedded systems development to integrate new functions, industry analyses report that these factors are equally relevant to heavy-duty vehicle OEMs [2,4,5], such as Scania, is the subject of the study presented in this research article.

Transitioning to a BEV brings substantial changes to the powertrain system within the MPP, primarily through the integration of components such as battery packs, power inverters/converters, and electric machines. The vehicle chassis requires structural modifications and layout adjustments to effectively accommodate these powertrain elements across various vehicle applications. Additionally, there are new vehicle functions integrated into the powertrain through embedded systems, such as the battery and thermal management systems [6,7].

The extensive changes to the MPP lead to increased product complexity, which may reflect on organizational structures and the PD ecosystem. The core need is to holistically manage the increased product complexity towards the future MPP; however, the challenge lies in developing an approach that aligns with the physical and software perspectives and the PD ecosystem. From an organizational perspective, Scania is exploring measures to establish an agile way of working and expand digital engineering technologies to complement the PDP.

Given the context, the following research questions were formulated to guide the investigation towards managing this transformation:

RQ1. What key Product Development challenges do heavy-duty vehicle manufacturers encounter when evolving complex modular product architectures to integrate new software-driven vehicle functions in the transition from ICE to BEV?

RQ2. Considering the ICE to BEV transition, along with the growing product and organizational complexity, what are the key considerations for heavy-duty vehicle manufacturers to support the transformation?

1.1. Scania’s Modular Product Portfolio

Scania’s MPP forms the core of its Product Development (PD), which focuses on continuously improving critical product properties such as comfort, handling, and energy consumption. The PD process (PDP) has four phases (referred to as arrows): pre-yellow and yellow (concept and product planning), green (development and implementation), and red (operation and maintenance), following the product’s lifecycle. The MPP operates on the principles of maintaining standardized interfaces between modules or subsystems, creating balanced performance steps that satisfy a range of performance needs, and offering identical solutions for customers with similar performance needs. An interface is a shared boundary between two functional units, involving physical connection and constraints, signal transfer, or other appropriate characteristics [8].

The MPP consists of different functional units with components made up of individual parts. These functional units, or modules or subsystems, deliver the various performance needs expected from the vehicle. Several module variants exist, each designed to meet a specific performance step within a predefined set. Each step corresponds to a distinct range within the broader range of performance needs. The MPP employs configuration rules described with variant codes to control the combination of different module variants in the MPP to create tailored solutions, i.e., control which components should be present in a certain individual product according to customer needs. The variant codes represent different module variants and facilitate maintaining a unified product description of the MPP during PD.

The product description is organized in a generic hierarchical structure and is managed within the in-house Product Data Management (PDM) system. Serving as the authoritative source for product description, the PDM system oversees change management. To complement the PDM system, a commercial Product Lifecycle Management (PLM) platform is integrated, enabling document storage and synchronization of geometrical models. The product description consists of information suited to stakeholders from different business domains such as design, production, and aftermarket services. The PDM system segregates this information, resulting in different types of generic structures. Common to all structures are different object types that build up the hierarchy in each structure. An example of an object type is a part or a component assembled in a product, and is traceable to the different structures (Figure 1).

The product structure, also referred to as the design structure, shows the applicable parts and their relative geometrical position for different product variants. The production structure provides information about the part’s assembly and corresponding tools. The service structure describes information on the spare parts and service methods for the part. Although the structures present varied information, the variant codes act as a common link, which enables filtering the product description to a single product variant across these structures. As the PDM system is the master for product description, it is integrated with IT systems across different business domains.

1.2. Overview of the Contribution

The research questions were addressed in three ways (Figure 2) as follows: (i) taking a stance from an automotive OEM seeking insights into its present state through a semi-structured interview study, (ii) performing a comparative analysis between the interview findings and a State of the Art (SOTA) survey, and (iii) synthesizing from the comparative analysis and frame of reference to formulate key considerations for OEMs to facilitate their transition. RQ1 is primarily addressed through the semi-structured interviews, while RQ2 is informed by the comparative analysis between interview findings and the state of the art.

The paper begins by introducing the research context, framing the key questions, and providing an overview of the MPP at Scania. It then lays the theoretical framework by exploring key concepts (Section 2). This is followed by the methodology chapter (Section 3) describing the approach used for the literature search, semi-structured interviews, and data analysis. The subsequent chapters present the results (Section 4) and discussions (Section 5), leading into a research synthesis that answers the framed research questions (Section 6.1). Finally, potential research directions (Section 6.2) are identified, and the paper concludes (Section 7).

2. Frame of Reference

This chapter lays the theoretical framework by looking into key concepts relevant to the study. The literature discussed here serves as a base for a broader examination of the state of the art, providing a basis for comparisons in the discussion chapter (Section 5).

2.1. Cyber-Physical Systems and Their Complexity

Complexity is a characteristic arising from the interactions between a system’s components, its environment, and the dynamic relationships among them, all of which shape the system’s behavior [10]. Metrics derived from complexity facets to quantify complexity have been discussed in the literature, e.g., [3,11,12]. Törngren and Sellgren discuss different aspects of complexity, including incidental complexity, which emerges from the specific implementation or design choices, and inherent complexity, which is intrinsic to the nature of the system itself [3].

The concept of Cyber-Physical Systems (CPS), introduced in 2006 by Helen Gill at the National Science Foundation in the United States, describes complex systems seamlessly integrating embedded and physical systems [13,14]. The embedded systems control physical processes and are integrated with extensive sensor networks to monitor conditions and robust communication networks for real-time data exchange. CPS operates with minimal human intervention, responding to various scenarios by sensing, perceiving, and acting on information from both the environment and internal systems. Major strategy reports highlight that CPS pose multi-fold technological challenges during development, they require: systemic approaches to requirements engineering and architecture design, multi-disciplinary and multi-paradigm modeling to manage heterogeneous architectures, interoperability across components, simultaneous handling of real-time behavior, functional safety, security, and reliability in dynamic and unpredictable environments, and management of continuous evolution through the lifetime of large-scale systems [15,16,17].

In addition to possessing incidental complexity, BEVs, including heavy-duty vehicles, are examples of advanced CPS that are inherently complex, consisting of advanced systems with intricate relationships, expected to operate under demanding, wide-ranging requirements through intelligent vehicle functions. Systems such as battery management and advanced driver assistance systems play a crucial role in enhancing vehicle efficiency, safety, and autonomy. Heavy-duty vehicle studies on the integration of new advanced functions show development challenges in the domains of safety and certification, architectural complexity, legacy integration, verification, validation, and deployment [18]. In addition to possessing incidental complexity, modern heavy-duty vehicles are inherently complex, consisting of advanced systems with intricate relationships, expected to operate under demanding, wide-ranging requirements.

As Eppinger and Salminen put it, the “development of [such] complex products and large systems is a highly interactive social process involving hundreds of people designing thousands of interrelated components and making millions of coupled decisions” [11]. Organizations transitioning from developing traditionally manufactured products to software-intensive products often find challenges in aligning their PD ecosystem and practices with evolving product technologies, needing a re-examination to sustain operational performance [19].

2.2. Systems Engineering and Complexity Management

The concepts of complexity management and systems thinking have a historic relationship, where the latter forms the basis for many complexity management approaches [10]. An increasing product complexity necessitates a systems thinking approach in the automotive industry, which is competitive and volatile. By emphasizing viewing a system as an interconnected whole and understanding the relationships between components, a systems thinking approach helps anticipate how changes might impact the entire system, including potential unintended consequences [20]. Overlapping with PD in different aspects, Systems Engineering (SE) is a means to manage incidental and inherent complexity (Lindemann [21] cited in [10]). Preferred in multidisciplinary PD [22], SE draws on principles of systems thinking to provide a holistic approach. Having many accepted definitions across the literature, one such definition describes it as “an interdisciplinary approach and means to enable the realization of successful systems” [8], while another, “a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems”. An engineered system can be a product, service, or enterprise comprising people, products, services, information, processes, and natural components [23]. While SE provides a theoretical framework, how it is applied in practice is shaped by the organization based on defined roles and responsibilities. Sheard [24] identified 11 systems engineer roles with distinct responsibilities, though some overlaps exist among them. However, according to the SE Body of Knowledge (SEBoK) [25], “SE activities may be conducted by any competent person regardless of job title or professional affiliation”, provided that the person has relevant “SE capabilities and experience”.

To address the rising complexity from the rapid evolution of software-driven vehicle functions, automotive OEMs have been encouraged to explore approaches such as agile systems development and digital engineering [26]. Acknowledging the benefits of scaling agile methods in CPS development, it is necessary to be mindful of some important challenges, such as collaboration and synchronization between agile and non-agile teams, communication barriers across distributed teams, synchronization between hardware and software development, and limitations in incremental delivery for physical systems [27]. The Office of the Deputy Assistant Secretary of Defense defines digital engineering as “an integrated digital approach that uses authoritative sources of systems’ data and models as a continuum across disciplines to support lifecycle activities from concept through disposal” [28]. A subset of digital engineering [29], Model-Based Systems Engineering (MBSE) is “the formalized application of modeling” and the use of connected models to support SE activities throughout the product life cycle [30]. The SE vision 2035 [31] aims for a future state with established MBSE frameworks, integrated digital threads, and the use of agile methods, cloud infrastructure, AI, and machine learning within enterprises.

2.3. Role of Architecting

From a PD perspective, distinguishing between the “product as a set of subsystems and components” versus the “product as a system” is essential. Recognizing this distinction raises the need for possessing component knowledge (understanding design principles and concepts for constituent components) and architecture knowledge (integrating components to form a coherent whole in a larger context) to develop successful products [32]. Studying the hierarchical nature and decomposability of complex systems, Simon [33] discusses that the interactions between two subsystems tend to be less intense than the component interactions within them. This allows subsystems to be developed independently and concurrently. However, when integrating several subsystems into a complex system, the collective interactions between them reveal the emergence of new functions and properties that cannot be reduced to the subsystems alone. From a SE perspective, we view a product as a system when its complexity demands not only a structured decomposition of elements, functions, and interactions but also a holistic approach to managing its emergent properties and functions. In this view, an architecture is “an idea of a system in its context embodied in its elements, interactions among its elements and context” [34]. Architecting is a vital aspect of SE, essential for transforming requirements into solutions by optimizing designs through strategic trade-offs and informed decision-making.

The architecture of a system is documented through an architecture description, which serves as a structured means of communication among stakeholders, enabling them to exchange information, align concerns, and facilitate decision-making. An Architecture Description Framework (ADF) provides the conventions, principles, and practices necessary to create these descriptions. A part of this framework is the architecture viewpoints that define how to present specific aspects of the architecture based on stakeholders’ concerns. These viewpoints guide the corresponding architecture views in depicting and visualizing the architecture. The definitions of these terms can be referred to ISO 42010 [35]. It is important to emphasize that an architecture description is not the architecture itself, but a formalized representation of it.

There are different models of ADFs available depending upon the domain of application, including Unified Architecture Framework (UAF)^® [36] for a complex system of systems and TOGAF^® [37] for enterprise architecture. Efforts to develop automotive-specific ADFs include the Automotive Architecture Framework [38] that defines general viewpoints—functional, logical, technical, information, driver/vehicle operations, value net, and suggests optional viewpoints such as safety, security, and energy. The general hierarchy of ADFs across six levels is discussed, ranging from meta ADF (common to all kinds of systems) down to product architecture (unique to a product). The Architectural Design Framework for automotive systems [39] is developed based on four main viewpoints—operational, functional, and constructional, with requirements ranging across the other viewpoints. Building on previous automotive ADFs and architecture description languages, the Architecture Framework for Automotive Systems [40] proposes the viewpoints, requirements, functional, implementation, deployment, information, and the additional feature viewpoint (visible to the end customer). A study at Volvo Cars similarly examined previous automotive ADFs towards defining an automotive-specific ADF. Based on existing viewpoints in these ADFs and from challenges identified in software development for EVs, autonomous driving, and connected vehicles, the investigation resulted in new viewpoints, including continuous integration and deployment, ecosystem and transparency, and system-of-systems [41]. Focused on the early PD phases and grounded on a RFLP structure (Requirements, Functional, Logical, Physical), Krog et al. [42] introduce a layered methodology for Vehicle Systems Architecture across system abstraction levels (vehicle, subsystem, component).

From an architectural abstraction point of view, Weilkiens et al. [34] highlight functional and physical as the key perspectives of a system architecture, along with behavioral, layered, and system deployment perspectives, focused more on software-intensive systems. The functional architecture defines what the system does—its functions and relationships, while the physical architecture specifies how these functions are realized through tangible components. The physical architecture progresses through multiple abstraction levels, namely the base architecture representing predefined constraints or design choices, the logical architecture describing principal solutions that can realize functions, and the product architecture representing the final concretization of the evolving system architecture into a realized, manufacturable product. A bidirectional and iterative relationship between the requirements and the system architecture on every abstraction level ensures traceability and alignment with design intent [34]. Focusing on the modularity of an architecture, Ulrich [43] describes a product architecture as the arrangement of functional elements, their mapping with physical components, and the specification of the interfaces between components. To establish a product architecture, Ulrich and Eppinger [44] propose a 4-step method, which bridges the system architecture and final product design, ensuring a cohesive transition from functional intent to physical realization:

• Create a schematic of the product’s elements and functional structure.
• Cluster elements into logical subsystems and modules.
• Develop a rough geometric layout, arranging modules within the product’s physical constraints.
• Identify and define interactions (fundamental and incidental) between modules and subsystems.

2.4. Model-Based or Model-Centric Systems Engineering

In an MBSE approach, information about various system aspects is represented through an evolving system model, which serves as the primary artifact. The scope of the MBSE initiative determines the extent of this information [8]. A widely cited study [45] discussed the leading methodologies of MBSE in terms of the processes, methods, and tools applied in a project environment. Surveys investigating the scope of MBSE use, benefits, and adoption challenges indicated better utility of MBSE in early lifecycle phases (requirements management, system architecture, and verification and validation) in the automotive industry [46]. A possible explanation is that an MBSE implementation is not integrated with product and program management [47]. Another possible explanation could be that in later stages of PD, various engineering disciplines employ specialized modeling languages, making it challenging to implement and maintain a unified modeling effort [48]. This emphasizes the importance of model-to-model translation in CPS development to refine and maintain consistency across models [49]. Although MBSE adoption is 15% higher in the automotive industry than in other industries, the growth remains slow due to a lack of clear implementation guidelines and concerns over model credibility [50]. It is important to question whether the system model results from a single unified model or a framework where models of different formalisms communicate with each other.

Given the complexity in the incremental PD of heterogeneous CPS, a “one-model or one-language” approach for MBSE is not practical, and where the design and development timelines vary for different engineering disciplines, it is important to integrate the system model with the configuration management system [51]. The MagicGrid^® framework [52], an extension of the MBSE grid methodology [53], is SysML compatible and presents a “collection of best practices” for systems modeling in a grid format. The columns represent system aspects, derived from the four SysML pillars, namely structure, behavior, requirement, and parametric, and the rows represent system abstraction levels, derived from the UAF domain. However, the framework does not explicitly discuss the development of a modular architecture. Axehill and Herzog [51] advocated the need to have distinct evolving models for complex systems that separate the desired future state (definition model) from the present state (design and realization model), to handle different time perspectives. A feedback loop provides insights from the present state for potential modifications in the future state [51]. Both studies highlight the need for models representing information at different abstraction levels.

Implementing MBSE offers several benefits, such as improved stakeholder communication, capturing discipline-specific views across the product lifecycle, and reduced development time [8]. Notably, the improvements published in two-thirds of MBSE implementations were based on the perception of improvement [29], indicating the scarcity of metrics to measure large-scale benefits. The top organizational challenges in implementations include clearly defining organizational vision and goals for MBSE, establishing effective governance and management frameworks, creating an infrastructure that facilitates stakeholder collaboration, addressing necessary organizational culture changes, and limited knowledge, skills, and training [54]. Furthermore, technical barriers such as a lack of interoperability and standards, poor traceability across siloed models, and overload of disconnected tools add an additional layer of complexity. These challenges can cause difficulty in demonstrating tangible value compared to improved organization structures, which were identified to have the strongest influence in successful implementations over investments in tools, processes, methods, and training [47]. Publications regarding MBSE implementations include a study discussing potential risks in implementations, suggesting a systematic and incremental approach [55], and another proposing the D3 adoption toolbox to prepare for challenges during an MBSE implementation [56].

MBSE is a valuable approach for managing complexity challenges, particularly when complemented by an ADF [57,58]. Often associated with the advantages it offers over the document-based approach in SE, MBSE aims to mitigate the risks of overlooking critical information and failing to visualize dependencies caused by inconsistent and unsynchronized documentation [48,57]. However, achieving a ‘common language’ that facilitates stakeholders’ communication requires a multi-model framework that integrates functional abstraction and key domain-specific properties, with a strong focus on key interfaces [59]. Domain-specific SE reinforces this idea by encouraging the use of a modeling stack that spans across different layers (high-level concepts down to detailed designs), while ensuring engineers from different disciplines can collaborate with models relevant to them, all while staying connected to the bigger picture [60]. Extending this idea, Masior et al. [61] highlight the challenges in the mixed use of model-based and document-based approaches, leading to fragmented model management, and discuss the need for an advanced MBSE approach (MBSE+). Operating on a middle layer, their method aims to link abstract meta models (top layer) with executable domain-specific models (bottom layers) [61]. Similarly, Tomiyama et al. [62] Stress the need for smart and architecture-driven MBSE to support the software-intensive, data-driven, and multidisciplinary nature of smart products, including CPS. Discussing the practical limitations of a single comprehensive model, the authors recommend a federated modeling approach supported by model translation standards and parameter management at the architecture level [62]. Lerat [63] advocates the need for MBSE implementations to initially focus on the principles of systems architecting and SE rather than emphasizing the modeling technicalities, which otherwise hinder complexity management. Logan et al. [64] claim that SE has been model-based or model-supported to an extent, but is gradually transforming to a model-centric approach, while emphasizing that the importance of text documents should not be overlooked.

2.5. Modularization and MBSE

Several studies have explored MBSE approaches for developing modular architectures, each using different modeling languages, tools, and strategies. The approaches discussed range across different levels of “modeling rigor”, lightweight data-linking methods, and semi-formal conceptual models to comprehensive formal models and federated modeling implementations, reflecting a trade-off between model fidelity and modeling effort.

2.5.1. Lightweight to Intermediate MBSE Implementations

Toepfer and Naumann [65] describe a bottom-up method to support modular PD at Daimler AG, centered on a centralized repository for engineering parameters. These parameters are linked in a customizable and hierarchical network across four structures: product portfolio, component, function, and system, and are directly associated with discipline-specific models. This allows automatic updates when dependent parameters change, maintaining consistency in data and their relationships with evolving design [65].

Unlike Toepfer and Naumann’s standalone repository, Meißner et al. [66] demonstrate a parameter management method embedded in SysML for rapid change management and requirements verification [66].

Pfeifer et al. [67] present a model-based approach for modularizing electric ferries. Their three-step approach begins with developing a logical architecture, then adapting it to develop specific system models for different operating conditions of electric ferries. Comparing these system models, system elements consistent across these models and operational scenarios are identified as system modules [67].

2.5.2. Formal and High-Rigor MBSE Approaches

Arguing that modularity is often assessed after the architecting stages, Stirgwolt et al. [68] incorporate system modularity assessment early in the architecting process. Their approach integrates design structure matrix clustering within SysML to automate the identification and grouping of system modules directly within the architecture modeling environment [68].

To facilitate structured reuse and adaptation of modular systems across product generations, Albers et al. [69] advocate the use of MBSE and provide a systematic SysML-based modeling framework. Their approach includes multiple model abstraction levels: a meta-model (general modular principles and rules), a reference product model (reusable modular kit), and instance models (specific products generated from reference models). These SysML models capture functional requirements and enable management of module variants within configurable product structures [69].

With an intent to enable enterprise-level architecture development of purpose-built vehicles, Jeong et al. [70] propose an MBSE approach that integrates functional decomposition from high-level system objectives and requirements with existing product structure data. Utilizing Capella, a modeling tool based on the Arcadia method, they represent the planned modular vehicle architecture as a hierarchical nested structure, from the overall vehicle at the topmost level down through the constituent subsystems and components [70].

2.5.3. Observations and Reflections

The rationale for the parameter-based approach is linking design data directly, avoiding the use of extensive formal architecture models, but providing less structural insight. On the other hand, the SysML and Arcadia-based approaches involve rigorous architecture descriptions for a deeper understanding of the system, its interfaces, and context, but require extensive modeling effort. Pfeifer et al. [67] present a structured yet semi-formal MBSE method to guide design decisions without detailing everything in a modeling tool upfront.

Across these MBSE approaches, a notable common link is the limited integration of spatial layout in the early architecture development process (step 3 in Ulrich and Eppinger’s 4-step method). Spatial compatibility verification remains largely external to MBSE models, posing risks for integration conflicts in the later design stages. Most authors hint at the challenges in integration between MBSE models and detailed design models. For example, as SysML models are not well-suited for geometrical and spatial layout design, improved SysML-CAD integration is needed to enable the exchange of key model elements and feedback loops between system architecture and mechanical design [71]. This disconnect can result in a methodological gap between PD and SE. While traditional PD may appear to emphasize geometry over systems thinking [42], MBSE approaches may, conversely, underrepresent spatial layout.

Multi-domain integration of the “cyber” and “physical” aspects in an MBSE methodology remains a significant area of concern. While Toepfer and Naumann [65] and Pfeifer et al. [67] primarily address mechanical design aspects, Albers et al. conceptually recognize multi-domain modeling and highlight the need for a holistic mechatronic view, but do not discuss it explicitly. Stirgwolt et al. [68] offer a framework for multi-domain modeling by capturing different types of interactions (e.g., material, information), but do not fully integrate software and control systems. Jeong et al. [70] target comprehensive integration of mechanical, electrical, and software/control domains in their proposed approach, but also acknowledge practical implementation issues.

3. Methodology

To establish a frame of reference for this research, an initial literature search (Appendix A) was conducted on the concepts of CPS, their inherent complexity, complexity management, and SE. The search was then refined to identify relevant studies on MBSE, particularly its application to modularity, system architecture, and automotive PD. The literature search aimed to explore:

• SE practices in interdisciplinary PD environments for complex systems.
• The role of MBSE in managing complexity, in automotive PD and CPS.
• The application of MBSE to modular products and system architectures.
• MBSE practices, perspectives from a document-based approach, and key adoption challenges of MBSE in industry.

The chosen data collection method in this study was semi-structured interviews, which provided the opportunity to have a flexible approach in asking open-ended questions (Appendix B) to the interview participants. Through the interviews, the participants were able to provide detailed descriptions of their personal experiences, suggestions, and opinions. Also, by modifying the order of questions and asking probe questions during the interviews, the interviews were made effective and purposeful [72,73]. During the interviews, the participants were given time to reflect on their responses and provide additional information in connection with the questions. Aiming to seek insights into the present state of Scania, the interviews explored different aspects, including:

• Factors influencing product complexity in heavy-duty vehicles and their consequences.
• Existing PD processes managing system integration and emerging challenges across cross-functional interactions.
• Perspectives on SE and its integration within the current PD setup.
• The use of models in PD and their utility in comparison to text documents.

Qualitative data analysis was performed on the data collected from the interviews through a systematic process comprising the steps of data preparation and familiarization, data coding, generating a description using categories, description representation through narratives, and result interpretation [74].

3.1. Participant Profile

Six participants (P1 to P6) for these interviews were selected from three distinctive teams (two from each team) to maximize the representation of PD and understand different perspectives (Appendix C). These teams were working in the areas of vehicle layout, embedded systems, and mechanical design. The participants had responsibilities spanning functional and software system architecture (P1–P2), vehicle layout, concept development and interface modeling (P3–P4), and mechanical design and component integration (P5–P6). All participants were involved in BEV development activities within their respective domains during the period of this study. Additionally, the participants selected from each team also had varying seniority (experience or role) to capture diverse opinions. P2 and P4 held key decision-making roles, participating in early PD phases and architectural considerations. P3 was responsible for maintaining vehicle layout and interfaces during concept development, while P5 and P6 provided expert perspectives in component and subsystem development. The representativeness of the findings was further supported by presenting and discussing them in multiple technical meetings with additional stakeholders at the company.

3.2. Reliability and Validity

Different reliability procedures and validity strategies [74] were used to assess the interview findings. Using a semi-structured questionnaire guide and conducting the interviews within a stipulated time helped in following a general protocol for consistency. The questionnaire used for the interviews was framed in a structured and detailed manner to maximize the reliability of the interview results. The transcripts were checked to identify errors, and the analyzed interview data were cross-checked with the interview transcriptions to ensure accuracy. The interview findings (in categories and sub-categories) were formed by assembling the analyzed interview data of the participants. The findings were validated through member checking, where participants reviewed and confirmed their accuracy.

Since the initial interviews, Scania began a transformation to adopt lean and agile practices in addition to expanding digital engineering capabilities. Follow-up interviews were conducted to assess how perspectives had changed with the new approach. They also provided an opportunity to revisit their previous responses. Results indicating a change are described in the manuscript. Unmentioned results mean the participant still agrees with their previous response, thus validating it. The limited number of response updates suggests that while organizational transformation is ongoing, many previously observed challenges remain unchanged.

Findings from the study were presented in Scania at multiple technical meetings, providing a platform to spread the findings and receive feedback on the validity of the findings. While the feedback affirmed the key findings of the study, open questions were raised about the modeling approach needed, its integration with the existing IT setup and PDP, and variant management with a new approach. These questions are also reflected in the research directions. The corresponding author, as the interviewer, acknowledges having previously worked in the capacity of a design engineer at Scania. Having encountered some of the challenges discussed in the study, the author recognized how this may have shaped the interview interpretations.

3.3. Delimitations

To establish the boundaries for the presented research, the following points serve as the delimitations:

• Focus lies on a single OEM manufacturing heavy-duty vehicles, not including other modes of road transport such as passenger cars.
• The research concentrates on early PD phases, including concept and design phases. Subsequent life cycle phases, including manufacturing, service, and end-of-life, were not analyzed.
• The research centers on the ICE to BEV transition scenario and how increased software integration reshapes product-level complexity. Technical design details in this transition are beyond the scope of this research.
• The interviews draw insights from internal stakeholders; external stakeholders such as suppliers, customers, and regulators are not interviewed.

4. Results

This chapter presents the results from the qualitative analysis of the interview data, organized into key categories and sub-categories. Notable comments from follow-up interviews are also described within relevant sub-categories.

4.1. Architecture and Design Approach

This section presents insights from participants regarding architectural and design-related challenges in PD, including challenges concerning requirements and legacy influence.

4.1.1. Product Development Challenges

P4 described the incremental approach for transitioning from traditional ICE vehicles to hybrid vehicles and BEVs. Early BEVs were initially adaptations of hybrid vehicles, progressively enhanced over time.

“Historically, we have a diesel engine, and then if we need a hybrid vehicle, we add components to make it a hybrid. Then, to make a BEV, we use the hybrid vehicle to make the first BEVs, and then we have just improved.”

(P4)

However, responses from participants P1 and P5 suggest that it is challenging to adopt the “continuous evolution through small steps” principle in the development of BEV as substantial modifications are required, see, e.g., Ref. [75]. Additionally, P6 mentioned it is challenging to simultaneously maintain two different chassis for the BEV and ICE vehicles. P3 highlighted the need to optimize vehicle architecture to avoid redundant components and functions between the ICE and BEV products in the MPP.

“Process performed to manage small changes; if big changes are to be made, then the process is not well adapted. So big changes need to be divided into smaller changes, and it is too much work to manage them.”

(P1)

We now describe notable comments from the follow-up interviews with P3–P6. P3 and P4 identified a gap during early development (the “yellow arrow” phase and transition to “green arrow”), where the absence of a product structure (only created in the “green arrow” phase) makes it difficult to define a clear product roadmap. A “preliminary product structure” would apparently aid the designers in visualizing interfaces and interactions in a concept and evaluating new architecture concepts according to different “use-cases”. The term use-case stems from the software engineering domain, where it refers to key functionalities or capabilities of a system [76]. The term use-case in this study is used to refer to an in-house practice of grouping offered products into different categories based on parameters such as application and operating conditions, to capture user experience. Some similarity can be drawn to the original concept here.

P4 mentioned the new way of working, following agile principles, intended to improve the cross-functional synchronization and agility in PD. Discussing the new way of working, P5 and P6 acknowledged that while it facilitates aligned planning, developing physical parts differs significantly from developing software.

“In the early yellow arrow, a major hiccup occurs because a product structure cannot be created when there is no real project, which is created only in the green arrow […]. We have ideas, but there is no product road map. We should be more proactive.”

(P3)

4.1.2. Market Needs and Requirements Management

This code identifies the need to improve clarity and traceability for early requirements to manage their complex dependencies.

P1 and P2 indicated that they received their initial requirements mostly through change requests for embedded systems. P3 and P5 described their efforts in deriving the requirements from various sources connected to different aspects of a project, for example, legal, functional, vehicle property, lessons learned, standards, and testing. P5 and P6 mentioned that the design requirements are categorized according to their relationship with product properties. Due to their complex dependencies, the effects of the evolving requirements on product properties are unclear.

The control over recording requirements was reported to be better in the green arrow projects than in the yellow arrow, by P1 and P6. P1, working in both, noted that less information was available in the yellow arrow, requiring more self-search. P6 identified the absence of a definite process for recording requirements in the yellow arrow.

All participants reflected that the initial requirements are recorded through text documents, emphasizing the need for traceability. P2, P3, and P4 stressed their importance as requirements keep changing over time, with P2 suggesting the need for a dedicated tool to support. While P1 and P6 mentioned the difficulty in following traceability, P5 suggested that revision histories in text documents help track changes.

As mentioned earlier, P4 brought up the adoption of use cases, improving the development of BEV. However, P6 feels that the use-cases for BEV are currently viewed in a manner applicable to ICE vehicles, affecting the awareness in understanding the customer’s adaptation to the vehicles.

4.1.3. Legacy Entities

This code describes the role of legacy entities in PD and their architecture implications. All participants referred to relevant legacy entities within their work areas. If the legacy entities are operational and stable, then they are easier to maintain with minor improvements, as the cost of migration from them is high due to multiple dependencies and the need for many resources.

P1 commented that existing User Functions (UF—functions related to the user realized by software systems) are continuously improved, and new ones are created only when there are structural changes in the software systems’ architecture. Further noting that “big changes are difficult to execute,” P1 indicated the limitations posed by legacy UFs for functional or architectural redesign within software systems.

P2 found the legacy UFs to be a “constraint for new development […] but also a source of security for something that works […] they are changed in small ways, so the effects of changes can be controlled.” P2 emphasized the constraint by commenting that “we cannot really manage too large leaps in functionality”. Aligning with P1s views, this indicates that legacy UFs constrain the introduction of new functions and the modification of subsystem boundaries needed for architectural adaptation.

P5 and P6 referred to some long-standing mechanical components still in use due to their reliability and customer demands. P5 added that these components do not disturb the PDP or new developments since their volume is not high. However, P6 added that it is expensive to make substantial changes or replace such components. P6 corroborated by adding that “as soon as you touch a common interface, then that is affected,” reflecting how the dependencies of legacy mechanical systems influence architectural changes and the effort required to modify adjacent subsystems.

Taken together, the responses indicate that legacy entities act as architectural constraints. They limit the degree to which new functionality can be introduced, restrict how subsystem boundaries can evolve, and influence how much the system can actually be modified during the ICE to BEV transition.

4.2. Engineering Collaboration

This section summarizes participants’ experiences of cross-functional collaboration during PD, focusing on communication practices, decision-making, and SE perspectives with role expectations.

4.2.1. Cross-Functional Communication

All participants reported that they work in some capacity in a cross-functional team. Specifically, P3 referred to the participant’s group as “the spider in a web” in Scania, and their work tasks are “such as a cog in the wheel, making everything spin in the same direction”.

P3 and P5 brought up the importance of “focus groups” consisting of engineers and experts within different fields, formed to solve design challenges in projects with the help of industry best practices. P4 mentioned that the pre-yellow arrow consisted of small teams and decentralized decision-making.

P1 and P6 feel there is inadequate coordination in early project phases, sometimes as affected groups are not aware of changes, leading to undesirable late changes. However, P6 adds, “it is also important that the individual is thinking if they are affected”.

P5 finds miscommunication as a common issue among cross-functional teams and hence emphasizes the need to improve communication skills:

“It is quite common when you develop something, and you do not have the information you need to continue […] it is a communication question […]. If you have good communication, then you would not end up in such a situation.”

(P5)

4.2.2. Decision Management

Trade studies were commonly mentioned by all participants, conducted during design reviews or technical meetings. On some occasions, decisions made from these discussions were only sent out through e-mails to persons involved in such meetings. This increased the difficulty in tracking the decisions for future reference, especially if one is not present at the decision meetings. According to P5, it is possible to trace prior decisions if they are formally documented and archived. P3 expressed the need for circulated information informing new decisions taken in the recent past.

P4 brought up an example of a case where decisions were not required to be recorded in the early phases:

“For a project, we had ‘this seems to work, let us do this’ approach, a decentralized decision-making process, to achieve things going faster. […] (Reference) was easy as everything was in my head. But in other bigger projects, if someone is not involved from the beginning, then it is often hard to find [decisions].”

(P4)

P1 provided an example describing the documentation for UF that consisted of a dedicated section to record trade studies, “but is always almost empty.” P1 added that, consequently, “it is difficult to go back and see why the design was chosen.” P6 also expressed issues where the consequences of a particular decision during trade studies and its impact on other systems were not clearly documented.

4.2.3. Perspectives on SE and MBSE

Mixed opinions exist regarding SE, with one interpretation that SE concerns systems consisting of physical and software components and another where SE is associated with developing software systems (such as the 12th role in [24]). P2 mentioned that a system can have multiple levels and referred to three levels: the whole vehicle electrical system, embedded sub-systems, and internal components. P5 described systems as consisting of hardware and/or software. P1 and P6 felt SE is mostly suited to working with software systems, while P2, P3, and P5 responded that SE applies to a system that can consist of different types of components: mechanical, software, cooling, and electrical.

Similarly, mixed views existed regarding MBSE. The first view described MBSE as a process of using models to describe and specify systems, and the second view described it as the generic practice of using models. P1 shared the first view while P2, P3, and P6 shared the second:

“[MBSE] used in conjunction with tools to implement models […] which is common now. The problem is to link all models in a coherent and comprehensive [way]. (Need) Strategy to connect smaller tools that can talk to each other.”

(P2)

4.2.4. Role of a Systems Engineer

There were divergent views regarding the role of a systems engineer. P2 felt that the responsibility of a systems engineer is large and “is not possible for a single person to be involved in everything”, so there must be multiple systems engineers with distributed responsibilities, and did not relate the systems engineer role to any such roles at Scania. P5, on the other hand, felt that a systems engineer role can belong to “someone who owns a [sub]system and has a broader picture”. P5 specified system owners in the software domain, and engineers working on vehicle layout could fit this role. P3, with a similar ideology, felt that many employees already work with multiple tasks other than their own, giving the example of a designer. P6 denied the presence of a systems engineer role but seemed to share thoughts with P5 in referring to layout engineers as systems engineers. In the follow-up interview, P2 mentioned a new role called lead engineer in program increment teams who oversees the management and engineering of a sub-system, which the participant speculated to work similarly to a systems engineer.

4.3. Information Management—Modeling Efforts and Data Representation

This section outlines the participants’ views on information management, capturing their insights related to accessibility, modeling needs, modeling tools, documentation practices, and variations in terminology.

4.3.1. Information Accessibility Challenges

The participants pointed out how information is scattered in multiple locations, mainly in shared and personal system folders, and cannot be accessed easily when needed. They also shared the opinion that in such situations, often other colleagues or persons are contacted till the information is found. P2, a senior employee, added that it is difficult to search for information or identify the right persons to approach if one is not directly involved in the project or does not have sufficient experience working in Scania. P4 and P6 mentioned receiving information or documents through e-mail attachments or a server link through Microsoft Teams on contacting their colleagues.

“A lot of sources of information. Need a lot of experience to find information by oneself; [applicable for] anything which has not gone into the official archive.”

(P2)

P1 commented that with growing experience and involvement in projects, “a lot of info is stored in the brains of different engineers”. P5, a senior and experienced employee, commented that though it is challenging to find information, “but, in general, would know where to look.” P1 and P6 believed there is better access to information in the green arrow compared to the yellow arrow. However, P3 mentioned that focus groups solve some challenges of information accessibility by assisting with the yellow arrow. P4’s comments provide a unique perspective: “a lot of distributed information. It is not a lack of information; it is a lack of access to information.”

The Product Data Management (PDM) system was regularly used as an important and centralized storage location for different types of PD information. P1 expressed that finding information in the document archive without knowing the document ID is difficult. Although document IDs are referenced in related documents, they are seldom updated. Additionally, the participant noted that these documents are archived post-product release, potentially causing delays for certain stakeholders in accessing them. P5 discussed that Engineering Change Orders (ECO) should include information on design changes, trade studies, requirements, and decisions. However, the ECOs are not updated continuously as the design evolves, so there is a possibility of missing information:

“Do not update ECO often, […] important to have the right information when you release […]. The traceability is not good, and its dependent on how good you are at documenting.”

(P5)

Contrasting views were observed in the responses of P2 and P5 regarding the issues faced due to insufficient information between cross-functional teams. P2 felt the need to ask multiple people to find information, a growing concern, while P5 described this as a part of PD:

“Many things are not formally documented. The organization has grown quite a lot in recent years, with many new people searching for information and not finding it […] A lot of information can be received when talking to people, but there is a limit.”

(P2)

“It depends on what you are looking for […]. But from a development point of view, it is always good to discuss with other people.”

(P5)

P2 and P6 highlighted the effectiveness of the configuration management for embedded software code and 3D models, indicating the need for such control over all types of information. P2 also mentioned that with stricter regulations on traceability of software updates, emphasis lies on configuration management and the requirements for cybersecurity and functional safety.

4.3.2. Model Requirements

Participants defined a model as a representation of an entity, which can vary depending on the application. Based on the responses of the participants regarding their expectations from a model, the following requirements on a model are derived, which relate to the mapping, reduction, and pragmatic criteria for a model (Stachowiak, H. Reference [77] cited in [78]):

• Continuously updated: P1–P3 explained that models are continuously read, requiring them to be continuously updated to achieve the correct information.
• Adequate representation: All participants held a common view that the model must adequately represent the entity to be modeled.
• Conformance to relevant standards: P5 brought up the requirement for geometric models to conform to relevant modeling standards, as the model must be compatible throughout Scania. However, the participant also added that as humans, there are different ways to create a model.
• Ability to produce results: The models are required to produce results that can be interpreted by the participants for their work.
• Adequate abstraction: The model should contain necessary and relevant information depending on the purpose.

4.3.3. Modeling Tools and Techniques

All participants also mentioned that Microsoft Office applications, such as PowerPoint and Excel, help them to create models. P1 and P2, belonging to the embedded systems groups, largely discussed an in-house tool governed by a methodology to represent software systems architecture. On a vehicle level, this tool captures the structure, interfaces, and information interactions of the different software systems. P1 spoke about descriptive models representing interactions between multiple ECUs, while P2 discussed integration models representing functional blocks and interfaces. Whereas, for physical systems, different parts of the vehicle architecture are captured in text documents and individual sub-system design models. P3–P6, who work in a mechanical domain, mostly describe geometric and simulation models. P3 mentioned the different types of interfaces in the vehicle: geometrical, legal, strategic, and project. In the follow-up interview, the participant mentioned simplified interface models to visualize spatial interactions.

4.3.4. Computer Models Vs. Text Documents

The participants were asked different questions to understand their views on using text documents vs. computer models to describe system specifications. Summarizing their responses, six comparison attributes were inferred (

Table 1. Attributes for comparison, summary, and respective participant comments for storing system information in text documents vs. models.

Attribute	Comparison Summary	Example Participant Comments
Accessibility and usability	Text documents are easier to create and access, but need to be well-written. Tools for text documents are easier to work but managing information in models is better with time.	“Documents are good as anyone can access” (P1) “Document is good if it is well written […] it is easy to create.” (P2) “We should use a model, it will be a quicker way of working” (P5)
Information organization and management	When information is stored within documents, it tends to be dispersed or fragmented. Possibility to efficiently link information through models	“documents, you cannot see […] the connections.” (P6) For documents, it is not structured information; you can store it any way, which makes it difficult to find.” (P2) “With different systems and storage areas, it achieves difficult […]. Good to have a common system to have all important information together.” (P3)
Stakeholder preferences and adoption challenges	All stakeholders may not be interested in models and prefer text documents Reservations in using complex tools to work with models.	“Depends on who will read […] test engineers do not want to see the model; they just want to see how we should test this part.” (P5) “Models have information in a tool which some people are afraid to use and access” (P1)
Comprehension and representation	Models are easier to understand visually. Explanatory information through large texts cannot possible to presented in models Varied levels of abstraction are possible within a single model	“Like figures, it is easier to understand compared to text.” (P1) “We have a lot of requirements, a lot of text […]. We use documents when there is a lot of text” (P5) “Like to use models to access deeper information inside the model.” (P1)
Efficiency and automation	Easier and quicker to use models to extract information and produce results. Opportunities to automate using models	“I would like an automated way to achieve information […]. Manual labor should not be used to extract information as today.” (P4)

) which is comparable to the results observed in [29].

P2, who did not have a preference in the first interview between using models and text documents, had a different perception in the follow-up interview:

“[…] less convinced that documents work […] the general trend is digitalization, more structure for information”

(P2)

4.3.5. Varied Interpretations of Terminology

P1–P4 shared a view that the understanding of terminologies is not consistent among the groups they interact with. P1 said there is consistency within a group but not in external interactions. P3’s reasoning for such a situation was that different engineering domains are working together and “people will have different perspectives on terminologies, but it is good to have a common view”, without which, according to P4, “can cause people to talk about different topics”. Working with new domains, including electrification and autonomous technologies, has introduced a substantial number of new terms that need familiarity, according to P6. Mechanical designers P5 and P6 expressed the presence of a consistent terminology among mechanical design groups. P5 put this by saying, “the parts I work with are classic. Not so many new areas and not often, so we need new names.”

P3 mentioned that the lack of clarity is especially higher when the employee is “new [and] a lot of things are not understood in the beginning, which needs a lot of time and experience”. According to P2, a consistent terminology is needed to avoid redundant information in real-time databases and further advocate the need by highlighting issues connected to increasing workforce, safety demands, and product complexity:

“Increasing need for a common view, because of the growing number of people involved and the complexity of the product. ISO 26262 [79] also puts requirements on exchanging data with the same meaning within (Scania) and outside.”

(P2)

Discussing consistency in adopted terminologies, P1–P4 indicated the need for different classes of terminology. By classes, the participants seemed to refer to the distinction in terminologies that are fundamental for Scania and those that are discipline-specific. Viewing such a distinction, Scania has an in-house lexicon consisting mostly of standardized technical terms and abbreviations denoting different aspects of the product. The lexicon also acts as an internal standard for naming conventions to define parts. Though the lexicon was referred to as the primary source of terminology, P1–P5 claimed that on a few occasions, they could not find certain terms they needed. P1 and P2 mentioned different temporary solutions implemented to solve the above challenge; P1 created a document with useful definitions, and P2 spoke about groups creating wiki pages for their specific terminology. P3 was quoted as saying “people use their own descriptions and terminologies […]. No proper awareness.”

To investigate the inconsistency further, the participants were asked to describe some fundamental terms in PD, such as product architecture, product structure, function, property, and requirement.

The descriptions from Figure 3 are viewed from the perspective of SOTA definitions. Function is a “defined objective or characteristic action of a system or component” [80] and the “transformation of input flows to output flows, with defined performance” [81]. A function was described as an observed or expected action, but the transformation of input to output was not explicitly mentioned. System property is “any named, measurable or observable attribute, quality or characteristic of a system or system element” [82]. The term property had interpretations mixed with those of a function and the SOTA definition. A requirement was commonly understood across the participants and relatable to the literature, which is:

“A statement that identifies a system, product, or process characteristic or constraint, which is unambiguous, clear, unique, consistent, stand-alone (not grouped), and verifiable, and is deemed necessary for stakeholder acceptability”.

[8]

Figure 3. Pictorial representation comparing the descriptions for the terms function, property, and requirement, provided by the interview participants.

Figure 3. Pictorial representation comparing the descriptions for the terms function, property, and requirement, provided by the interview participants.

Product structure is a “decomposition of the physical elements of the system of interest” [8]. The design structure (Section 1.1), forms the foundation for the design and development activities, and represents the structural decomposition of the product.

Further, product architecture was described as involving the integration of elements into the product structure. Some interesting responses about product architecture were that “product structure is heard more often [than product architecture]” (P4) and is “created more recently, related to […] the layout of the truck” (P6).

In the follow-up interviews, P2 expressed the need for better clarity in the distinction between product structure and product architecture. P5 mentioned that discussions about product architecture have increased with the intensified development in BEV.

4.4. Complexity and Integration Challenges

This section consolidates participants’ perceptions of complexity management, including the nature of complexity, its contributing factors, and the challenges that arise during PD.

4.4.1. Complexity Challenges

All participants had a unanimous opinion that vehicles are complex products. They mean that this poses multiple challenges, such as maintaining a holistic product view, product integration, scalability, the need for interoperable tools, and implementing new introductions.

P1, P4, and P6 described the challenge of developing a product such that everything works together as required and intended. P4 simply put this as “complexity is how to fit everything together so that everything works”. The challenge of implementing new introductions was stressed by P2, P3, and P5. P3 said, “it is harder when a new system, technology, or component is introduced,” and the complexity increases in time-to-market, citing the example of the BEV. P5 provided additional explanation:

“Trying to identify a new interface for future BEV, but it is not as easy as in an ICE truck because the engine position and gearbox have been the same for a hundred years. […] There are no stable interfaces over time because of the changing demands, complexity, or technology.”

(P3)

“If you need to introduce something new or change something, you need to involve a lot of people, and it can be time-consuming.”

(P5)

4.4.2. Factors Contributing to Complexity

In continuation of the challenges due to complexity, the participants also emphasized certain factors causing complexity, which are summarized in

Table 2. Complexity-causing factors deduced from participant responses.

Factors	Participant Views
Heterogeneity and interdisciplinary work	“Complexity is due to different areas (disciplines) in the truck. […] Difficult to know about everything and how things work.” (P1) “Each department has its own requirements to fulfill, and it is a challenge.” (P5)
Cost pressures	“Trying to produce a truck to have more profits and still achieve customer satisfaction. This is difficult and complex.” (P3)
Large number of components	“With new technologies, it (complexity) tends to grow. All of these (parts and functions) need to align” (P5)
Managing multiple variants within a single product	“How many types of vehicles possible. The total number of combinations can be the total complexity.” (P2) “Everything is made from scratch to keep the production line smooth and the possibility of having different variants.” (P4) “We offer many specifications, so we have many variants, that is complexity.” (P5)
Multiple component interactions and dependencies	“On a top level, it (complexity) is the number of connections in an (embedded systems) network […] between systems” (P2) “Sometimes it is difficult to see the dependencies between things, from a design perspective.” (P6)
Compatibility between legacy and new systems	“Complexity comes from backward compatibility. New generations of systems are introduced in parallel to old systems, thus existing together.” (P2)
Variety in requirements	“Different markets have different technical requirements, which require different technical performance steps.” (P6), “Complexity due to a lot of demands, laws in different countries” (P3)

, some of which were also observed in [75].

4.4.3. Perception of Complexity

Product complexity was viewed to be desirable or undesirable based on its impact, correlating to the discussion of useful and useless complexity [10]. P1 believed that complexity can be perceived to be negative when it is unnecessary, while P2 claimed that complexity is a choice that needs to be taken, as it is “inevitable that complexity increases with new developments”. According to P5, “If something is complex, it does not necessarily mean it is not good”, and without it, “the truck might not work as intended”.

P4 claimed that the individual components that make up a product are not complex by themselves, but when combined, the product as a whole becomes complex. The participant clarified this with an example, saying that a vehicle’s suspension system is not complex by itself, but adds complexity when assembled in a vehicle. According to P3, a product “should be as complex as possible [but] easy to describe”, indicating the need for complexity to develop sophisticated products, but the complexity must be managed. P1 and P5 added that complexity in the product aids in realizing advanced capabilities, providing an edge over competitors:

“[Complexity is] positive when different things are made to work together, can be an advantage over competitors if they cannot provide the same thing.”

(P1)

P1, P3, and P6 also added to their opinions that efforts must be taken to simplify aspects that seem complex and try to reduce complexity. P4 ended the response by saying that “if it (complexity) could be divided into parts, then [managing] complexity should be everyday work”, apparently indicating that if a complex system can be decomposed into sub-systems, then the sub-systems can be easier to manage. P2 and P6 pointed out the shortage of adequate tools that help in managing complexity. P6 expressed that something appears to be complex when the complexity is not understood:

“complex is when it is not easy to understand […] system that is complex at the moment is probably less complex tomorrow when you have implemented some systems to visualize it.”

(P6)

P3 mentioned calculating the number of variants produced by a single component; P2 and P6 suggested the number of dependencies between systems and the total number of components in a vehicle, which can help in measuring product complexity.

5. Discussion

This chapter discusses the implications of the interview results while simultaneously comparing them with the SOTA. The chapter consists of six sections and begins with the architectural evolution of a product and the broader environment around the PD. The attention then shifts to the complexity challenges faced by an OEM amidst existing design practices and the PD ecosystem supporting architectural evolution. It is worth noting that several key challenges in mechatronic system design, previously identified by Mørkeberg Torry–Smith et al. [59] continue to persist, as confirmed by our research findings. Looking ahead, the final sections examine the prospects in the current setting to support an adaptive and integrated PD approach. This structure emerged from analyzing the interview results in a complex PD ecosystem. Each section concludes with a tabulated summary (

Table 3. Interview and SOTA insights—Architectural adaptation in the transition to BEV from ICE.

The transition to BEV from ICE—architectural adaptation	Interview Insights	SOTA Insights
	ICE knowledge base: Heavy-duty vehicle manufacturers have accumulated architectural and component knowledge over decades with ICE vehicles. BEV development in heavy-duty vehicles: − Developed by adapting the ICE vehicle architecture. − Opportunity to acquire new component knowledge. Chassis modifications and challenges: − Chassis represents a support platform for most powertrain components. − BEV transition requires significant modifications. − Maintaining separate chassis layouts for BEV and ICE vehicles is challenging	Modular innovation in BEV [83]: BEV development in vehicles generally follows a modular innovation pattern. Trade-offs in Radical Innovation [32]: Radical innovation may lead to a dominant design but often disrupts established component and architectural knowledge. Architectural Innovation [32]: Between purely modular and radical innovation, denoting an unchanged core design but changed architecture Product generations [84]: − Most development projects follow product generation engineering − New generations derived from a “reference product”. Modularity and innovation [85]: − Modularity drives innovation, in turn improving product performance. − Beyond an optimal level, modularity is counterproductive for innovation. − Excessive design choices, product similarities, and communication barriers are concerning signs.

Note: Bold text indicates the heading of each summarized insight and additional text provides supporting detail.

,

Table 4. Interview and SOTA insights—Context to Product Development.

Context to Product Development	Interview Insights	SOTA Insights
	System requirements as a weak link: − Early phase or system requirements loosely recorded. − They could serve as the link between transport use-cases and detailed design. − Design requirements are derived from the goal of improving product properties or product performance − Need for tool support—clarify impact propagation from use-cases to design requirements − Need for accelerated development and evolving demands challenge traditional methods, especially in early phases. Impact on BEVs: Some aspects of use cases are still viewed through an ICE lens, providing limited insights into BEV user perspectives.	Market-oriented abstract use-cases [86]: Most automotive development projects leverage abstract use cases to capture broader market needs. MBSE for CPS development: − Multidisciplinary PD for CPS benefits from a user-centric SE framework leveraging model-based techniques [22]. − Architecting is vital for SE—Essential for transforming requirements into solutions [34].

Note: Bold text indicates the heading of each summarized insight and additional text provides supporting detail.

, Table 5, Table 6, Table 7 and Table 8) of the key insights, which are synthesized to answer the research questions in Section 6.

5.1. The Transition to BEV from ICE—Architectural Adaptation

The automotive industry has accumulated architectural and component knowledge (Section 2.3) for ICE vehicles over decades, leading to stable architectures and PD processes within OEMs. Hybrid vehicles and BEVs in these OEMs are developed largely leveraging ICE vehicle designs. From an innovation perspective, while ICE vehicles have reached dominant design through incremental innovation, BEV development generally follows a modular innovation pattern, introducing new components yet retaining the architecture [83]. With modular BEV development, the automotive industry is actively acquiring new component knowledge to support this shift. As the chassis serves as the platform for most powertrain components, the BEV transition requires significant modifications. Highlighted in the interviews, maintaining separate chassis layouts for BEV and ICE vehicles within the MPP is challenging. At the other end, radical innovations involve changes to both components and architecture, but they often disrupt established component and architectural knowledge in the process of acquiring new knowledge. They come with high uncertainties and the challenges of large-scale implementation with substantial resource demands and longer development timelines. Architectural innovations (unchanged core design but changed architecture) serve as an incremental step for modular innovations [32].

Most new development projects follow the approach of product generation engineering, where the majority of a new generation is derived from previous generations as a reference, with changes in form or principle [84]. New generations following a modular architecture expand component knowledge and reinforce architectural knowledge, enabling controlled product innovation. Lau et al. [85] examine the relationship between product modularity, innovativeness, and product performance. While concluding the absence of direct links between product modularity and product performance, they imply that product modularity drives innovation, which in turn improves new product performance. However, they identify an inverted U-shaped relationship between product modularity and innovativeness, implying that beyond an optimal level, modularity is counterproductive towards innovation. Excessive design choices confusing engineers, communication concerns between teams across modules, and high similarity between products are some signs that Lau et al. suggest companies monitor to minimize negative effects on product innovation [85].

5.2. Context to Product Development

Automotive development projects are mostly initiated through market demand analysis rather than individual customer orders, where abstract use-cases are utilized to capture different market demands [86], similarly practiced at Scania. These use cases serve as a “context” to PD without focusing on individual customers. The concern lies in the early phases (yellow arrow), where there is no structured approach to translate and record use-case needs into vehicle-level (system) requirements. In contrast, there is adequate control over requirements in later phases (green arrow), associated with detailed design. Hence, there is a weak link between the early system context and PD and design requirements. This possibly is a consequence of deriving design requirements from the goal of improving product properties (Section 4.1.2) in different use-cases, making the PDP property-driven over requirements-driven.

Product properties seem to capture performance objectives or targets of the product. As the SE handbook describes, performance is “A quantitative measure characterizing a physical or functional attribute relating to the execution of a process, function, activity, or task.” These attributes include “quantity (how many or how much), quality (how well), timeliness (how responsive, how frequent), and readiness (when, under which circumstances)” [8]. Differences in how requirements are managed during the concept versus design phases suggest a deficient process in early phases of development, making it difficult to oversee complex dependencies. Inkermann et al. [87] point out the shift from component- to function-oriented development in the automotive industry and its impact on early-phase requirements management. Without the need for a separate model to manage requirements and their traceability, the authors demonstrate a SysML-based approach that embeds requirements within five partial models representing the structural and functional view of the system [87]. A property-driven PD may seem product-centric, where existing product strengths are leveraged and improved. This approach enables incremental improvements but may be less adaptable to major architectural changes. As a result, some aspects of the use cases may be at risk of being viewed through an ICE vehicle perspective, e.g., design requirements derived from legacy properties, limiting insights into evolving market needs.

Additionally, the need to enhance time-to-market and address evolving demands presents challenges in continually verifying system requirements using existing methods. Tool support can assist engineers in clarifying how evolving system requirements propagate to detailed design, reducing the risk of unintended consequences or overlooked impacts. Building on Guérineau et al. and their cartographies [22], multidisciplinary PD such as in CPS, requires a user-centric SE framework that addresses escalating complexity by leveraging model-based practices and system modeling techniques. They also emphasize the importance of architecture definition, serving as the foundation for managing complexity and ensuring effective system integration (Section 2.3).

5.3. Outlook on Product Complexity and Its Management

The MPP maintained in the generic structure enables offering customized solutions through configuration rules. It is evident that the complexity in vehicles is both inevitable and multifaceted. The interview findings are consistent with previous studies on complexity in CPS [16,17,88]. This complexity is driven by several factors, including technological advancements, diverse market needs, and regulatory requirements. Complexity can be beneficial in enabling a sophisticated product to perform advanced functions. However, poorly managed complexity has an adverse impact on PD and production, subsequently affecting the time-to-market. Ideally, the complexity should be managed with no unintended consequences, but the inclination should be on reducing rather than eliminating it, as complexity is inherently tied to the product’s architecture and is an integral part. Hence, complexity can work in harmony with the product, provided it is addressed effectively, providing a competitive edge.

The interviews highlighted a decomposition strategy to manage complexity in the product, aligning with a broader discussion in the literature on holistic versus reductionist approaches [10]. Sinha et al. [12] introduce the concept of integrative complexity to quantify the additional complexity from the integration of system modules. They claim that a lower level of integrative complexity indicates a more effective decomposition strategy. While modularity results from a decomposition strategy, product complexity is independent of it [12]. This reinforces the notion that product complexity is an inherent characteristic—while a reductionist approach, such as modularization, addresses complexity within modules or subsystems after decomposition, addressing integrative complexity in the product needs a complementary holistic approach. However, the interviews highlighted a shortage of methods and tools to support this approach.

From a business perspective, the key to managing the MPP is variant management, striking a balance between two tightly linked objectives: external variety to address diverse market needs and internal commonality to reduce parts, optimize costs, and streamline production [75]. However, maintaining this balance within a modular product in an intricate PD setting increases technical challenges from a development engineer’s perspective. A hidden challenge is that a module variant needs to work in multiple scenarios, so the designer needs to consider a wider range of possibilities and interactions [69,89]. This insight seemed to consistently reflect in the interviews. As illustrated in Figure 4, participants ranked ‘managing multiple variants within a single product’ as the most significant complexity-causing factor. This factor is closely connected to the others, seemingly emerging as a cumulative effect of their influence, making it an observation shared by all participants.

Spatial interfaces are captured in CAD models for physical systems, but interactions involving the exchange of energy and mass are not represented, which together are part of a product architecture [90], explored in [75]. The software architecture is developed and governed by an in-house methodology and a dedicated tool at Scania. While the design structure provides a structured decomposition of the MPP, forming the core of the design and development activities, the combination of design structure and CAD models does not assist in the early stages of architecture. Architectural information for the physical systems is then inferred from an array of text documents. The participants working with the mechanical design and layout of the vehicle pointed out relatively more architectural challenges compared to the embedded systems teams.

Table 5. Interview and SOTA insights—Outlook on product complexity and its management.

Outlook on product complexity and its management	Interview Insights	SOTA Insights
	Product structure and MPP: − The product structure provides the structural decomposition of the MPP, forming the core of PD. − Through configuration rules, customized solutions are offered from the MPP. Increasing product complexity: − Modularity to manage product complexity. − Complexity is beneficial when managed, but detrimental when poorly managed − Complications in variant management Architecture gaps between Physical and software systems:> − Physical and software systems architecture descriptions remain detached. − Complicates holistic view and cross-functional collaboration. − Physical systems engineers see larger architectural challenges. Energy and mass interactions are not captured holistically. − Software architecture supported by an in-house methodology and tool. − Lack of a “preliminary product structure” appears to align with the need for a shared and structured architecture description. − Gap hinders proactive PD and challenges product roadmaps. − Support from an early-phase tool designed to visualize interfaces, guide decisions, and evaluate architectural concepts. Vehicle Functions: − Realized collectively by physical and software functions − In-house software architecture governs software functions. − No methodology for identifying and specifying overall vehicle functions. Physical functions are not formally managed. Legacy subsystems and components: − With incremental innovation, legacy entities are logical. − Both a constraint and safeguards reliability. − Changes may cause high resource demands and migration costs	Product complexity: Inherent to the architecture and cannot be eliminated [10]. Concept of integrative complexity [12]: − Modularity is a decomposition strategy addressing localized complexity in modules. − Integrative complexity emerges from module integrations. − A lower value suggests effective decomposition and modularity. Importance of variant management: − Effective variant management is vital to balance external variety and internal commonality [75]. − Product complexity poses technical challenges for engineers in variant management [69,89]. Role of an architecture definition: − Essential to manage complexity and system integration. − Disconnect between functions and components in mechatronic systems. Need for functional modeling to reduce this gap [62,91,92]. − Architecture alignment between teams guides trade studies and decision-making. aids innovation, and avoids rework. − Separation of high-level concerns in architecture, distinguishing functional and physical perspectives [34]. − Early lifecycle phases in automotive development benefit most from model-based methods [46]. − Distinct models for the present state and the desired future state of the product to handle different time perspectives. Feedback loop from present to future state for potential modifications [51].

Note: Bold text indicates the heading of each summarized insight and additional text provides supporting detail.

Table 5. Interview and SOTA insights—Outlook on product complexity and its management.

Outlook on product complexity and its management	Interview Insights	SOTA Insights
	Product structure and MPP: − The product structure provides the structural decomposition of the MPP, forming the core of PD. − Through configuration rules, customized solutions are offered from the MPP. Increasing product complexity: − Modularity to manage product complexity. − Complexity is beneficial when managed, but detrimental when poorly managed − Complications in variant management Architecture gaps between Physical and software systems:> − Physical and software systems architecture descriptions remain detached. − Complicates holistic view and cross-functional collaboration. − Physical systems engineers see larger architectural challenges. Energy and mass interactions are not captured holistically. − Software architecture supported by an in-house methodology and tool. − Lack of a “preliminary product structure” appears to align with the need for a shared and structured architecture description. − Gap hinders proactive PD and challenges product roadmaps. − Support from an early-phase tool designed to visualize interfaces, guide decisions, and evaluate architectural concepts. Vehicle Functions: − Realized collectively by physical and software functions − In-house software architecture governs software functions. − No methodology for identifying and specifying overall vehicle functions. Physical functions are not formally managed. Legacy subsystems and components: − With incremental innovation, legacy entities are logical. − Both a constraint and safeguards reliability. − Changes may cause high resource demands and migration costs	Product complexity: Inherent to the architecture and cannot be eliminated [10]. Concept of integrative complexity [12]: − Modularity is a decomposition strategy addressing localized complexity in modules. − Integrative complexity emerges from module integrations. − A lower value suggests effective decomposition and modularity. Importance of variant management: − Effective variant management is vital to balance external variety and internal commonality [75]. − Product complexity poses technical challenges for engineers in variant management [69,89]. Role of an architecture definition: − Essential to manage complexity and system integration. − Disconnect between functions and components in mechatronic systems. Need for functional modeling to reduce this gap [62,91,92]. − Architecture alignment between teams guides trade studies and decision-making. aids innovation, and avoids rework. − Separation of high-level concerns in architecture, distinguishing functional and physical perspectives [34]. − Early lifecycle phases in automotive development benefit most from model-based methods [46]. − Distinct models for the present state and the desired future state of the product to handle different time perspectives. Feedback loop from present to future state for potential modifications [51].

Note: Bold text indicates the heading of each summarized insight and additional text provides supporting detail.

Despite differing development timelines, software and physical systems are integrated through the PDP, but their architecture descriptions are detached, making it difficult to track dependencies for engineers who desire a holistic view of the product. Since the product architecture forms the crucial link between the transport use-cases and the evolution of the MPP, collaborating on detached architecture descriptions relies heavily on effective cross-functional communication. Additionally, there are risks that architectural objectives of the physical and software systems are not adequately represented in the use cases. This gap between physical and software systems poses challenges to proactive product architecting and creating product roadmaps.

Functions performed by physical systems and the User Functions (Section 4.1.3) collectively realize a vehicle’s functions (Section 2.3). However, currently, no standardized methodology exists at Scania to formally identify and model the overarching vehicle functions. A part of a greater MBSE challenge identified by Tomiyama et al. [62], research is needed towards standardized methods to bridge functions and system architecture models with operational and life cycle data for data-driven CPS development. Highlighting the shift towards function-driven innovation in CPS, Hoepfner et al. [91] discuss the “conceptual gap” between function-driven development and geometry-focused design of mechanical components. As a means towards reducing this gap, they present a SysML-based design method for formal functional descriptions of mechanical components and their links with principal solutions and geometric designs [91]. In another study involving functional model-based design, Wan et al. [92] use the Functional Basis Language to specify early-stage functional descriptions. A model compiler automatically translates these descriptions into executable multidisciplinary simulation models, intended to help engineers visualize and validate holistic vehicle functions. A step in this direction could help in bridging the gap between the detached physical and software architecture descriptions [92].

The interviews highlighted how additional support to visualize interfaces, evaluate architectural concepts for several “use-cases,” and guide decision-making would enhance proactive PD of ICE, hybrid vehicles, and BEV within the overarching MPP. They emphasized the need for a “preliminary product structure” in the early phases of development, which seemed to refer to an envisioned tool to address the additional support needed. By enhancing proactive PD, such a tool could potentially facilitate significant design changes and address redundancy and complexity. In line with these findings, research on functional safety for automated driving has also identified the need for anchoring new designs with legacy platforms [93]. The MPP also comprises legacy subsystems and components, perceived as both constraints and safeguards. Their continued use is advocated by the stability and reliability they bring to the products. However, ensuring compatibility with them induces complexity in the product due to their dependencies. With the evolution of the MPP through incremental changes, legacy entities are logical. However, major changes to the MPP can potentially result in high migration costs and significant resource demands due to the tight dependencies of these entities within subsystems. The need to streamline and plan such migration efforts also hints at the importance of the “preliminary product structure” supporting PD.

5.4. Complexity Beyond Products—the Product Development Ecosystem

PD is a core and integral part of any product’s lifecycle. However, the interviews indicated that during the development of a new product generation, breaking down substantial modifications into small changes can seem overwhelming without the support of a proactive and holistic approach. This may result in ad hoc design adjustments and increased complexity, posing challenges to scalability, safety, reliability, and design flexibility in CPS development, as discussed in [94].

As BEV concepts evolve and architectures are refined for new generations, PD difficulties are compounded by “the risk of organizational barriers” [32,43]. For automotive OEMs, this presents an opportunity to revisit the strategies behind the PD ecosystem, considering the importance of a competitive product and time-to-market.

The interviews highlighted both the strengths and challenges of cross-functional collaboration. On one hand, diverse expertise is brought together (for e.g., “focus groups”) for product innovation and to solve design challenges. On the other hand there are instances of teams unaware of changes caused by communication issues, delaying integrations. Challenges with information management and accessibility pose additional concerns, and the impact is higher for new employees, highlighting the necessity of “intelligent information-filtering” or the ability to provide relevant information to people [95]. Communication issues pose risks in the development tasks of engineers, where decisions, design choices, and trade studies are sometimes difficult to trace. They mostly encounter these challenges while making changes to or drawing inspiration from a stable design. The fact that design decisions are often not well-documented is known in the SOTA. For example, Leveson identifies this as the intent behind software design and proposes “intent specifications”, comprising system goals, constraints, and design rationale, to track decisions and map them with the intent [96]. These challenges in cross-functional collaboration point towards the need for a structured communication system.

Other than existing within the product, complexity also exists in collaborative information processing systems (CIPS)—the environment comprising humans, software applications, and information, to develop a product [3], and integrated processes [91]. The interplay between CIPS and integrated processes creates challenges that extend beyond the CPS themselves, complicating PD. Hence, effective communication is critical between stakeholders during PD, especially during the early phases where there is limited design knowledge and higher design degrees of freedom, as depicted in the cone of uncertainty for complex CPS [3]. The impact of communication issues tends to be lower during the early phases as the teams are smaller and the product is still abstract, but in later stages or as the project grows, the implications are larger if not addressed. While decentralized and agile decision-making can speed up work in early phases, a poorly structured communication system hampers the benefits. Conway’s law discusses the role that communication patterns play within an organization and highlights the risks they pose in influencing a product’s architecture [97]. Additionally, differences in individuals’ working styles, particularly in their levels of proactiveness and communication skills, further complicate collaboration.

With rapid advances in the development of BEV, there are new and dynamic additions to the existing terminology at automotive OEMs. This presents a particular challenge for traditional engineering disciplines such as mechanical engineering, which rely on terminologies anchored to universal standards in their regular tasks and are now suddenly exposed to dynamic terminology. In cross-functional PD tasks, differing interpretations of terminology cause confusion and miscommunication, which aligns with the findings reported in [48]. As a result, different groups maintain local terminology lists to aid internal communication, but this adds to redundant information and also heightens the risk of misunderstandings in external communication. Excessive information search may eventually largely hinder PD if the inaccessibility to information crosses a tipping point, subsequently needing additional resources in terms of time, cost, and effort of persons involved. The concerns in cross-functional collaboration discussed here stem from knowledge boundaries in the form of gaps in terminology, uneven understanding, and conflicting priorities. Ramli et al. [98] propose viewing an architecture framework as a concept of boundary object to unify stakeholders in aligning concerns, assist trade studies, and improve decision-making.

Analyzing participants’ understanding of key terms, such as a function and property, during the interviews, it appears that an automotive OEM’s PDP and best practices influence how certain terms are used, resulting in some definitions not aligning with international standards. This can lead to challenges with external collaboration or incorporating theory into practice. Additionally, standards such as ISO 26262 [79] on functional safety stress the importance of clear and consistent communication. Among different application areas for the automotive industry, MBSE also presents opportunities in automotive safety management [99]. With a fast-paced PD, driven by a significant amount of information, uniformly accepted terminology plays an important role in improving communication. As noted in [48], “a system can potentially fail without clear agreement on basic terminology and relationships (i.e., ontology)”. An ontology in any domain comprises its terminology and essential concepts, including their classification, taxonomy, relationships, and domain axioms [100]. Considering the importance of structured communication and the need to reconcile different terminology classes (Section 4.3.5), it is essential to create a standardized glossary. Such a standardized glossary is also important in developing an ontology [58] facilitating a model-based approach [48,56,68,101].

Table 6. Interview and SOTA insights—complexity beyond products, in the Product Development ecosystem.

Complexity beyond Products, in Product Development ecosystem	Interview Insights	SOTA Insights
	Strengths and challenges in cross-functional collaboration: − Brings together diverse expertise (focus groups) to aid innovation and solve design challenges, but communication issues result in late changes. − Decisions, trade studies, and design rationale not adequately documented create dependency on individuals, especially challenging for new employees − Smaller teams and scope in early phases minimize the effects of communication issues. Situation reversed in green phases. Key challenges with tacit information in early phases of PD: − Excessive information search, needing additional resources, hinders PD. − Proactive collaboration in early phases is hindered by limited structure in communication. − Poor documentation of design rationale increases knowledge gaps over time. − Decentralized decision-making is effective in early phases but compromised by communication issues in later phases. Terminology misalignment: − New and rapidly changing terminology creates interpretation challenges. − Local glossaries aid internal communication but create redundant information and risk cross-functional misinterpretation. − Emerging domain terminology challenges adaptation in traditionally standardized engineering disciplines. − In-house lexicon specifically adapted to the product.	Complexity in CIPS [3] and integrated processes [91]: − Importance of stakeholder integration through effective communication. − Higher ambiguity in early phases (cone of uncertainty) [3]. − Structured communication channels (intelligent information filtering) improve organizational alignment and reduce design rework [95,98]. − Conway’s Law—Organizational structure and communication patterns influence product architecture [97]. − Design decisions are often not well documented. Intent specifications, a method to track decisions [96]. Role of a Standardized glossary: − Fosters communication and effective alignment between stakeholders through fewer misinterpretations. − Standardized glossaries aid in robust ontology development [58], beneficial for a model-based approach [48,56,101].

Note: Bold text indicates the heading of each summarized insight and additional text provides supporting detail.

Table 6. Interview and SOTA insights—complexity beyond products, in the Product Development ecosystem.

Complexity beyond Products, in Product Development ecosystem	Interview Insights	SOTA Insights
	Strengths and challenges in cross-functional collaboration: − Brings together diverse expertise (focus groups) to aid innovation and solve design challenges, but communication issues result in late changes. − Decisions, trade studies, and design rationale not adequately documented create dependency on individuals, especially challenging for new employees − Smaller teams and scope in early phases minimize the effects of communication issues. Situation reversed in green phases. Key challenges with tacit information in early phases of PD: − Excessive information search, needing additional resources, hinders PD. − Proactive collaboration in early phases is hindered by limited structure in communication. − Poor documentation of design rationale increases knowledge gaps over time. − Decentralized decision-making is effective in early phases but compromised by communication issues in later phases. Terminology misalignment: − New and rapidly changing terminology creates interpretation challenges. − Local glossaries aid internal communication but create redundant information and risk cross-functional misinterpretation. − Emerging domain terminology challenges adaptation in traditionally standardized engineering disciplines. − In-house lexicon specifically adapted to the product.	Complexity in CIPS [3] and integrated processes [91]: − Importance of stakeholder integration through effective communication. − Higher ambiguity in early phases (cone of uncertainty) [3]. − Structured communication channels (intelligent information filtering) improve organizational alignment and reduce design rework [95,98]. − Conway’s Law—Organizational structure and communication patterns influence product architecture [97]. − Design decisions are often not well documented. Intent specifications, a method to track decisions [96]. Role of a Standardized glossary: − Fosters communication and effective alignment between stakeholders through fewer misinterpretations. − Standardized glossaries aid in robust ontology development [58], beneficial for a model-based approach [48,56,101].

Note: Bold text indicates the heading of each summarized insight and additional text provides supporting detail.

Table 7. Interview and SOTA insights—Platform for a model-based approach within the PD ecosystem.

Platform for a model-based approach within the PD ecosystem	Interview Insights	SOTA Insights
	Prevalence of a document-based approach in early phases: − High reliance on text-based models in Microsoft Office applications. − Text documents are prevalent for different system aspects due to ease of use and accessibility. − High interdependencies between text documents overwhelm PD due to limited traceability, inconsistency, and redundancy, affecting collaboration. − Knowledge gaps due to incomplete or inconsistent documentation—create direct dependencies on individuals. Model-based approach in later phases: − Use of multiple multidisciplinary specialized models. − Importance of modeling and simulation tools for complex systems. − Layout engineers express the highest need for a model-based approach. − Limited support for specialized models on an architecture level, bridging across systems and layers. Document-based vs. model-based: − Various comparison factors, e.g., usability, accessibility, and personal bias, influence the perception of choosing an approach. − Purely document approach not favored despite reservations in learning modeling tools. − A holistic modeling strategy is encouraged (inclination based on the benefits of the model-based approach). − Simultaneously, the general opinion is not to discontinue documents entirely. − Noticeable gap between informal models and documents in early phases, and specialized discipline-specific models in later phases. Varied interpretations of MBSE: Formalized structured approach to specify systems vs. “generic” use of models.	Document-based approach: − Shortcomings discussed widely in the literature. − PDM system, a key repository for document-based information concerning different system aspects [86]. MBSE approach: − Model-based techniques key for systems architecting [22,34]. − MBSE is moving towards a model-centric approach, but the importance of documents is acknowledged [64]. − Lack or limited integration of MBSE with program management is one of the possible reasons for the limited impact of MBSE in later phases. − Changes in organization structures—highest impact on successful implementation, along with cultural changes and management support [47]. − Some high-level benefits include structured information, improved stakeholder collaboration, and reduced development time. − The benefits of MBSE are often perceived as outweighing empirical measurements [29]. Makes it harder to justify investment to management and contributes to resistance. − Implementation through pilot projects to reduce potential risks and evaluate value incrementally [55]. System model: − Discussion on a single unified model vs. a framework of interconnected models of different formalisms. − Single model—single language impractical for heterogeneous CPS [51]. − Integrating a system model within configuration management is important. − Need for different specialized models is challenging for a unified modeling effort [48].

Note: Bold text indicates the heading of each summarized insight and additional text provides supporting detail.

Table 7. Interview and SOTA insights—Platform for a model-based approach within the PD ecosystem.

Platform for a model-based approach within the PD ecosystem	Interview Insights	SOTA Insights
	Prevalence of a document-based approach in early phases: − High reliance on text-based models in Microsoft Office applications. − Text documents are prevalent for different system aspects due to ease of use and accessibility. − High interdependencies between text documents overwhelm PD due to limited traceability, inconsistency, and redundancy, affecting collaboration. − Knowledge gaps due to incomplete or inconsistent documentation—create direct dependencies on individuals. Model-based approach in later phases: − Use of multiple multidisciplinary specialized models. − Importance of modeling and simulation tools for complex systems. − Layout engineers express the highest need for a model-based approach. − Limited support for specialized models on an architecture level, bridging across systems and layers. Document-based vs. model-based: − Various comparison factors, e.g., usability, accessibility, and personal bias, influence the perception of choosing an approach. − Purely document approach not favored despite reservations in learning modeling tools. − A holistic modeling strategy is encouraged (inclination based on the benefits of the model-based approach). − Simultaneously, the general opinion is not to discontinue documents entirely. − Noticeable gap between informal models and documents in early phases, and specialized discipline-specific models in later phases. Varied interpretations of MBSE: Formalized structured approach to specify systems vs. “generic” use of models.	Document-based approach: − Shortcomings discussed widely in the literature. − PDM system, a key repository for document-based information concerning different system aspects [86]. MBSE approach: − Model-based techniques key for systems architecting [22,34]. − MBSE is moving towards a model-centric approach, but the importance of documents is acknowledged [64]. − Lack or limited integration of MBSE with program management is one of the possible reasons for the limited impact of MBSE in later phases. − Changes in organization structures—highest impact on successful implementation, along with cultural changes and management support [47]. − Some high-level benefits include structured information, improved stakeholder collaboration, and reduced development time. − The benefits of MBSE are often perceived as outweighing empirical measurements [29]. Makes it harder to justify investment to management and contributes to resistance. − Implementation through pilot projects to reduce potential risks and evaluate value incrementally [55]. System model: − Discussion on a single unified model vs. a framework of interconnected models of different formalisms. − Single model—single language impractical for heterogeneous CPS [51]. − Integrating a system model within configuration management is important. − Need for different specialized models is challenging for a unified modeling effort [48].

Note: Bold text indicates the heading of each summarized insight and additional text provides supporting detail.

5.5. Platform for a Model-Based Approach Within the PD Ecosystem

Interviews revealed the use of various modeling tools to create detailed design models within different engineering disciplines. Notably, Microsoft Office applications are commonly and extensively used to create documents and relevant informal models in the early phases of PD. However, there is a noticeable gap between such informal models and documents, and the specialized multidisciplinary models used in later phases. The text documents and ECOs managed through a PDM system are key repositories for information such as system needs and requirements, system descriptions, and trade studies, also discussed in [86]. It is challenging to manage the interdependence between text documents for different system aspects, thereby making it difficult to extract insights from them. Hence, the volume, dependencies, and volatility of the information are overwhelming to manage, and the consequences are limited traceability, duplication, redundancy, and inconsistency in the information during PD. These results correlate with studies discussing the shortcomings of a document-based approach to SE and the need for a model-based approach to improve information structure and engineering collaboration [102]. Additionally, incomplete information due to insufficient documentation or from omissions caused by differing documentation practices creates direct dependencies on the responsible stakeholders. Viewing from an information perspective, PD would benefit from a controlled and structured approach for the broader information landscape (e.g., architecture descriptions, requirements, design rationale, trade studies). Malvius [102] emphasizes consistent terminology and a model-based approach as key components for structured information. With an inclination to identify cross-functional information needs, organizations can leverage structured information towards an integrated information management [102].

Table 8. Interview and SOTA insights—prospects towards a hybrid approach, MBSE, and agile.

Prospects towards a hybrid approach—MBSE and agile	Interview Insights	SOTA Insights
	Concurrent PD and Multidisciplinary Teams: − Distinctness in physical and software systems development, but coordinated through the PDP. − No Formal Systems Engineer Role: Varied opinions on what such a role might entail. − One opinion envisions a dedicated SE team, another of dedicated systems engineers responsible for individual subsystems in the vehicle. − Agile methods—Need identified to establish an Agile way of working.	Sheard’s 11 SE Roles [24]: Early work categorizes multiple SE roles, each with distinct responsibilities. Who can perform SE activities [25]? Any competent individual with relevant capabilities and experience, irrespective of job title. Opens possibilities for existing roles to incorporate SE responsibilities. Collaborative Learning [103]: − Effective collaboration requires exchanging knowledge and information on different topics. E.g., domain expertise, architecture, terminology. − Must be supported by structured communication channels to align perspectives across disciplines and reduce ambiguity Weak links between Agile methods and SE: − Inherent distinctness between physical and software systems development can pose coordination challenges. − Hybrid Approach—Combine system-level rigor with agility to address evolving demands in CPS [22].

Note: Bold text indicates the heading of each summarized insight and additional text provides supporting detail.

Table 8. Interview and SOTA insights—prospects towards a hybrid approach, MBSE, and agile.

Prospects towards a hybrid approach—MBSE and agile	Interview Insights	SOTA Insights
	Concurrent PD and Multidisciplinary Teams: − Distinctness in physical and software systems development, but coordinated through the PDP. − No Formal Systems Engineer Role: Varied opinions on what such a role might entail. − One opinion envisions a dedicated SE team, another of dedicated systems engineers responsible for individual subsystems in the vehicle. − Agile methods—Need identified to establish an Agile way of working.	Sheard’s 11 SE Roles [24]: Early work categorizes multiple SE roles, each with distinct responsibilities. Who can perform SE activities [25]? Any competent individual with relevant capabilities and experience, irrespective of job title. Opens possibilities for existing roles to incorporate SE responsibilities. Collaborative Learning [103]: − Effective collaboration requires exchanging knowledge and information on different topics. E.g., domain expertise, architecture, terminology. − Must be supported by structured communication channels to align perspectives across disciplines and reduce ambiguity Weak links between Agile methods and SE: − Inherent distinctness between physical and software systems development can pose coordination challenges. − Hybrid Approach—Combine system-level rigor with agility to address evolving demands in CPS [22].

Note: Bold text indicates the heading of each summarized insight and additional text provides supporting detail.

From the interviews, it is vital to consider the dynamic between a model-based and a document-based approach. The following key factors emerged from the interview analysis:

• Accessibility and usability: trade-offs between simplicity of text documents and long-term efficiency of models.
• Attitude towards change in the way of working and personal biases: familiarity with using text documents compared to the learning curve of models.
• Fragmentation vs. integration: managing information in text documents relative to models.
• Comprehension and representation: detailed, narrative-style explanations in text documents as opposed to structured information at different abstraction levels.
• The degree of automation possible using models is contrasted with that of text documents.

The interviewees’ preferences in adopting model-based and document-based approaches are shown in Figure 5. The usage of text documents is still prevalent for different purposes, but the transition to a model-based approach is encouraged and preferred. Although there were reservations observed in using models over documents, none of the participants preferred only text documents, indicating the need and acceptance of a model-based approach. The need for a model-based approach supported by relevant tools was expressed as the highest among the vehicle layout groups. In addition to the skills and knowledge of engineers and experts, modeling and simulation tools assisting in decision-making are needed for complex systems. Such models exist at the sub-system and component level, but there is limited support from models that provide an overview of the product architecture.

The interviews revealed mixed views on MBSE; either as a structured approach using models to describe and specify systems, or as the generic practice of using models in engineering. Henderson and Salado [29] attempt to clarify the distinction of MBSE from other related concepts. Adopting a model-based approach additionally requires appropriate investments in adequate training and infrastructure to ensure effective implementation (Section 2.3). However, such investments are a consideration for most transformative technical strategies.

5.6. Prospects Towards a Hybrid Approach—MBSE and Agile

The PD in heavy-duty OEMs is concurrent, and the approach involves multidisciplinary engineering teams. However, along with the foundational engineering disciplines such as mechanical engineering, electrical engineering, vehicle engineering, and software engineering, systems engineering needs to be integrated into the multidisciplinary engineering team.

It was evident from the interviews that Scania does not have a formal systems engineer’s role. However, the participants were encouraged to provide their opinions on what a systems engineer’s role might entail. Analyzing the responses, two interpretations emerge: a collective SE role in terms of a dedicated team of engineers with different expertise collaborating at the product level, or as individual engineers concentrating solely on their own subsystems and assuming ownership. Referring to the frame of reference (Section 2.2), Sheard [24] outlined different roles and responsibilities applicable to a systems engineer, while SEBoK [25] suggested that an individual with adequate capabilities and experience may conduct SE activities without a specific job title. This being said, it is important to identify what the “SE activities” are and what level of “SE capabilities and experience” is needed, if an SE approach is integrated in a multidisciplinary engineering environment. The approach requires continuous collaboration with domain experts in both physical and software systems, aiming to bridge architectural gaps. With structured communication playing a key role, this collaboration is a learning process where information exchange covers topics such as domain and product knowledge, modeling techniques, architecture description, and complexity management, to reduce the knowledge gaps [103].

Integrating an agile approach into CPS development requires considering the distinctness between the development of physical and software systems [3], as also identified through the interviews. This gap encourages the need for a hybrid approach for CPS development, bridging the weak links between SE and agile methods. Such an approach would combine the rigor for complex systems with the lightweight and flexibility to respond to rapidly evolving user needs and market conditions [22]. However, differing views on the scope of SE can complicate adopting and extending a hybrid approach among some teams.

6. Research Synthesis

The interview study presented in this paper investigated an automotive industry view of the challenges posed to PD due to the increasing complexity of a modular product. Building on the frame of reference and the interview insights, we answer our research questions in this chapter and lay out future research directions.

6.1. Addressing Research Questions

RQ1. What key Product Development challenges do heavy-duty vehicle manufacturers encounter when evolving complex modular product architectures to integrate new software-driven vehicle functions in the transition from ICE to BEV?

Continuous innovation to introduce new vehicle functions fuels the automotive industry. Commercial pressures from rapid technological changes, competitive factors, or regulatory demands require accelerated development cycles with continuous verification, all while being stringent and upholding quality standards.

Established automotive OEMs have accumulated architectural and component knowledge for ICE vehicles over decades, resulting in a stable product architecture and PDP. A reductionist approach and a decomposition strategy have historically been proven useful to manage product complexity and incrementally innovate the ICE vehicle. However, modular innovations and increasing software-driven vehicle functions in the rapid shift towards BEV have now revealed several intertwined challenges that transcend technical design, raising concerns within the PD ecosystem in its processes and communication dynamics. An outline of these challenges is provided below:

• Weak link between the context and PD and design requirements:
  Current PD methods lack a formalized approach to translate high-level transport use-cases into actionable design requirements. The practice of deriving design requirements from the improvement of product properties may tend to a product-centric PD over a user-centric approach. A direct dependency is the varied stakeholder interpretations of use-cases across multiple teams (software, electrical, mechanical) when they collaborate on developing new functions. This adds additional responsibilities to domain experts in clarifications. Incremental innovations benefit from property-driven PD. However, major shifts, such as in modular innovations, are a challenge.
• Holistic vs. Reductionist approaches to manage product complexity:
  Decomposition strategy (reductionist approach) and high modularity in PD help localize and manage complexity within modules. However, complications may result from unforeseen interactions between modules, requiring holistic oversight. Poorly managed complexity is a significant concern for increasing the engineering workload and poses risks of design errors. This essentially affects the efforts in balancing external variety and internal commonality. While the product structure facilitates managing variants, new functions lead to new performance steps and variants, posing technical challenges to engineers maintaining this balance. As software-driven vehicle functions increase, they challenge traditional module boundaries and interfaces from established architectural practices, needing a re-examination of the decomposition strategy.
• Fragmentation between physical and software architecture descriptions:
  Lack of a shared vehicle architecture description results in a fragmented view of the product, posing challenges to shared understanding, cross-functional collaboration, and holistic decision-making. A contributor to this issue is the higher architectural challenges for physical systems. A model-based formal methodology is required that provides a holistic view of the vehicle, accounting for energy and mass flows along with spatial interactions. Furthermore, without formal methods to specify high-level vehicle functions, traceability from transport use-cases to architecture decisions remains limited. This widens the gap between physical and software systems development and impairs function-driven development. Hence, early architectural tasks such as visualizing interfaces, evaluating concepts, and creating product roadmaps are difficult.
• Cross-functional collaboration and communication barriers in different forms:
  Software-intensive vehicle functions require close cross-functional coordination between software teams and traditional engineering disciplines. However, persistent communication barriers impact the cross-functional coordination, which manifests in various ways: a lack of a shared holistic view of the vehicle for collaborating stakeholders, misalignment due to inconsistencies in terminology with emerging technical concepts, and varying stakeholder engagement, seen in the involvement and personal communication preferences of individual stakeholders. Communication barriers may seem manageable in the early phases due to smaller teams and abstract concepts. However, any unresolved interactions can have amplified effects in later phases without a structured communication system. Large OEMs often have multiple processes involving different cross-functional teams. These processes may or may not be in the same network, posing risks to alignment, redundant information, and duplicate work. Also, PDP and best practices influence interpretations of key terms, complicating external collaboration or incorporating new theory into practice.
• Managing early-phase PD information:
  While specialized modeling tools exist for subsystem design (e.g., CAD for mechanical, dedicated software architecture tools for embedded systems), architectural and early development phases often rely on different forms of text documents. The volume, volatility, and inter-dependencies of information are overwhelming to manage and track with a predominantly document-based approach. Excessive search hinders collaboration and adds risks of overlooked information and reactive communication. Local copies or multiple links for documents create inconsistency and redundancy. Moreover, tacit information in informal, undocumented knowledge or inadequately documented information creates direct dependencies on stakeholders, which is especially challenging for new employees.

Product architectural information in the traditional PD ecosystem relies on a combination of a document-based approach, siloed discipline or domain-specific tools, and PDM/PLM-managed product structures. While the architectural information for ICE vehicles is systematically documented and managed centrally, it remains fragmented and poorly integrated without a formal and structured methodology for vehicle architecture description. As a result, engineers must manually reconcile architectural information across domains. An often-overwhelming task, which is further complicated by detached architecture descriptions for physical and software systems. This may not have been a pressing issue for ICE vehicles in the past. However, the rapid pace of BEV development and its intricate challenges create a gap between architectural knowledge and PD. Collaboration is prone to becoming ad hoc without a shared vehicle architecture description, and complexity management is hindered. This discussion brings forward the second research question.

RQ2. Considering the transition from ICE to BEV, along with the growing product and organizational complexity, what are the key considerations for heavy-duty vehicle manufacturers to support the transformation?

OEMs developing complex heavy-duty vehicles carry a PD heritage, connected to an ecosystem of key entities such as their processes, IT systems, and organizational structures. The OEMs face challenges as discussed in RQ1 during the ICE to BEV transition if the PD ecosystem does not provide adequate support required to manage the growing complexity. We infer from the literature that an organization must embed MBSE into a broader collaborative and architectural context to effectively support the transition from ICE to BEV under growing product and organizational complexity. In addition to the models serving the purpose of technical representations, it is key to ensure that they are effective coordination tools for stakeholders across physical and software domains. Aligned with a governing methodology and complemented by clear and purposeful documentation, this integrated approach has the potential to enable complexity management and support proactive PD. Against this backdrop, we discuss the answer to RQ2:

• Balancing continuity and innovation:
  OEMs must ensure short-term operational stability and long-term market competitiveness during the BEV transition. A hybrid innovation strategy allows new product generations to be introduced through modular innovations, followed by incremental improvements within modules or subsystems. This is a pragmatic approach for controlled innovation, where architectural knowledge is preserved and reinforced, while component knowledge is expanded. Proven architecture is leveraged for gradual evolution, balancing time-to-market with risk control. Balancing modularity and innovation risks requires clear guidelines that distinguish which modules or subsystems are shared, and which must be unique. Targeting specific modules or subsystems for further innovation contributes to improved product performance. Here, improved communication between modules or subsystems plays a key role.
• Architecture-driven collaboration:
  A consistent framework that improves impact propagation tracking, enables rapid iterations, and improves rigor enhances architecture-driven collaboration. This should be supported by structured communication channels and intent documentation that captures tacit knowledge and decisions.
  Maintaining a balance between holistic and reductionist approaches requires integrating systems thinking with modular development. A decomposition strategy localizes complexity within modules, while an overarching vehicle architecture description is necessary to manage complexity from module interactions.
  To foster a function-driven innovation, explicitly mapping vehicle functions with a common methodology is important. This should be guided by a user-centered approach, where system requirements are the primary driver and product properties act as constraints or performance optimization targets.
  Architectural innovations should be pursued towards the desired future architecture state, without disrupting the current modular product. This means distinct models representing the present and future architecture states support planning, communication, and evaluation. A feedback mechanism between these states supports long-term evolution, adaptability, and planning legacy system transitions.
• Layered and hybrid SE strategy leveraging the benefits of document-based and model-based approaches:

  ○

  Layer One: Early conceptual and primarily document-based—prioritizing simplicity and speed.

  In the early conceptual stages, retaining simplicity and accessibility of text documents offers value for abstract, high-level information. A full-fledged model-based approach is neither necessary nor practical in these early stages; however, they can be complemented with lightweight models. With a large design space and ambiguity, narrative text offers clarity and enables early agility without reliance on heavy tools.

  ○

  Layer Two: Federated vehicle architecture description—transition between conceptual and development stages.

  Complexity in the information grows as concept development and collaboration on the vehicle architecture progress. This necessitates a structured and integrated environment comprising formal models to address the challenges of manual reconciliation of product architecture information. A federated vehicle architecture description provides a shared platform for cross-functional teams, bridging physical and software systems development. Serving as a backbone for architecture work, it links transport use-cases and detailed design, acting as a bridge between layer one and layer three. Integrating PDM/PLM systems with this layer is essential to maintain information consistency across the PDP. However, an additional formal layer introduces additional responsibilities in managing the architecture model itself and ensuring effective integrations across the layers.

  ○

  Layer Three: Discipline-specific modeling.

  Comprises primarily discipline-specific engineering models for detailed design in the later development stages.

  Layer two should act as a formalized bridge between conceptual product planning layer one) and discipline-specific development (layer three). However, this layer is not clearly distinct, either because it is currently merged into adjacent layers or is underdeveloped, resulting in insufficient support for model-based architectural development.

• Standardized terminology and structured information flow:
  Terminology classes at different abstraction levels (e.g., company-specific, discipline-specific, domain-specific) potentially offer value in robust ontologies, in turn facilitating a model-based approach.
• Emergent SE Role Structure in three steps:
  A gradual and phased approach to organizational change through a distributed model helps ensure SE responsibilities are scalable. While facilitating cross-functional collaboration, the distributed SE model may provide opportunities to identify tightly coupled teams.

  ○

  Step 1: Lay and strengthen the foundation.

  Incorporating a practice of focus groups can provide a foundation for architecture-driven collaboration without introducing new SE roles at the outset.

  ○

  Step 2: Introduce the distributed SE model.

  As a succeeding step, the focus group practice can be extended into a distributed SE model. This creates an adaptable platform to collectively share SE responsibilities and strengthen collaboration across physical and software domains. This setup can foster collaborative learning through feedback loops between vehicle architecture and detailed sub-system design, combining top-down and bottom-up perspectives. Basing Sheard’s work [24] SE roles can be explicitly mapped to focus groups’ responsibilities to highlight overlaps and reveal gaps.

  ○

  Step 3: Refinement of model.

  As a final step, necessary activities should be identified to refine the distributed SE model, for example, through additional competence or personnel.

• Managing change and building confidence:
  Pilot projects can support the targeted introduction of layer two, providing an incremental approach to build confidence, measure effectiveness, and scale up within the organization. Dedicated workshops during these projects provide opportunities to understand the scope of changes and also clarify benefits and risks.

6.2. Research Directions

Discussing the recommendations in RQ2 leaves multiple areas open to future exploration and research. Ultimately, the transition to BEVs represents not just a product shift but a broader transformation impacting the PD ecosystem and OEM strategies.

This research proposes conceptual suggestions for layer two and the distributed SE model implementation, and tooling is not prototyped. As a next step in the layered approach, further work is needed to develop layer two, which is key for a federated vehicle architecture description. Multiple questions arise, such as what kind of models can represent the vehicle architecture? How many models are needed? How formal should the model be and at what level of fidelity? How can the architecture description be seamlessly integrated with layer one and layer three? How should variant management be supported in layer two? How can layer two be integrated into the existing PDP?

Having touched upon the role of a standardized glossary and an ontology in enhancing a model-based approach, their contribution in layer two and the distributed SE model is promising for further exploration. How can terminology classes be developed to contribute towards ontology development and a model-based approach? How can this support improved cross-functional communication?

Leveraging step 1 of the SE role structure, subsequent research would focus on the expansion of the distributed SE model, examining questions such as how the present responsibilities of focus groups map with the SE functions. How should the distributed SE model function in layer two? How can such an approach be linked to agile methods and program management?

Another essential area for future research involves developing tangible metrics to evaluate how effectively the layer two and a distributed SE model facilitates PD and complexity management. Given the current emphasis on a property-driven PD and discussing the need for a requirement-driven approach, evaluating the shift could be insightful.

Revisiting modularity and innovation risks in RQ2, future work should focus on the approach to establish guidelines for distinguishing shared and unique subsystems or modules for modular PD. Exploring metrics to identify high-complexity variants in a modular product offers an interesting research direction. How can the heavy-duty vehicle industry benefit from exploring the future of BEV from the perspective of architectural innovation?

7. Conclusions

In response to the global ICE to BEV shift and the growing integration of software-driven functions into modular product architectures, this study examined a heavy-duty vehicle OEM developing advanced automotive CPS and identified findings relevant for such transitions in the state of the art. Interviews at the OEM revealed several key challenges, including fragmented architecture descriptions across physical and software domains, weak alignment between early-phase system context and detailed design specifications, and constrained cross-functional collaboration. The constraining factors are inconsistent terminologies, a lack of structured communication mechanisms, and reliance on document-centric practices. Collectively, these challenges create gaps in function-component traceability and the integration of physical and software sub-systems. These gaps may not have been a pressing issue for vehicle development in the past. However, the rapid pace of BEV development and its intertwined challenges strain legacy PD ecosystems and established complexity management practices, resulting in increased late-stage rework, complicated variant management, and higher risks of integration errors. Although this study reflects internal stakeholder perspectives within a single heavy-duty OEM, several of the identified challenges are also reflected in the state of the art. This indicates that these challenges are not unique to the case company, while external perspectives could offer additional insights.

Findings from the interviews, complemented by the literature review, suggest different paths forward. A hybrid incremental-modular innovation strategy is seen as valuable in preserving a proven architecture while enabling targeted BEV functionality, alongside maintaining a parallel development track specifically for architectural innovations. Architecture-driven collaboration supported by a federated vehicle architecture description offers a common platform to bridge physical and software domains and for holistic decision-making.

Adopting a layered development approach, combining document-based artifacts with progressively deeper MBSE, emerges as a pragmatic path forward, fostering early-phase agility and later-stage rigor and traceability. Notably, existing solutions often neglect the integration of document-based practice, which remains prevalent in early development phases. Examining the application of MBSE for managing complexity and fragmented architecture descriptions highlighted practical obstacles, including trade-offs between modeling effort and fidelity, limited support for early spatial layout integration, and challenges in bridging physical and software subsystems architectures.

A distributed SE model established within existing cross-functional teams, supported by standardized terminology, complexity metrics, and iterative pilot programs, may enhance collaboration, reduce complexity, and improve traceability without introducing extra organizational layers. Standardized terminology contributes to ontology development, which may streamline communication and data exchange in an organization. This forms a key enabler for a robust modeling approach.

An integrated strategy, as outlined based on the findings in this paper, has the potential for improving the management of the increasing complexity of automotive CPS, thus providing the overall direction for future work. This strategy incorporates holistic systems thinking, user-centered design, structured information flow, standardized information management, and rigorous MBSE methodologies. Furthermore, integrating agile practices with MBSE offers a promising synergetic approach to address the challenges of multidisciplinary PD.