Bridging Design and Simulation: A Framework for Simulation Lifecycle Governance and Digital Thread Integration in Engineering Enterprises

Simulation-driven design has become central to modern product development, enabling engineers to evaluate structural, fluid, thermal, and dynamic behavior virtually before physical prototyping. The growing availability of high-performance computing (HPC), together with advances in finite element analysis (FEA), computational fluid dynamics (CFD), and multiphysics simulation, has significantly increased both the volume and complexity of computer-aided engineering (CAE) activity across discrete manufacturing industries [1], [2], [3]. As a result, simulation artifacts such as geometry packages, mesh definitions, solver input decks, boundary conditions, and result datasets have become strategically important engineering assets [3].

However, simulation capability has advanced faster than simulation data governance. A persistent gap remains between CAE execution environments and enterprise product lifecycle management (PLM) systems that govern product design data [4], [5]. In many industrial settings, CAE work is still performed on local workstations, HPC clusters, or shared directories outside the PLM environment. Requests are often communicated through emails or informal channels, geometry is exported manually, and results are archived in unstructured project folders. This creates a traceability deficit: organizations struggle to determine which design revision a simulation represents, whether results remain valid after design changes, or whether prior validated models can be reused [5], [6].

The operational impact is significant. Engineers spend time reconstructing prior analyses, rebuilding models that could have been reused, and assembling simulation evidence chains for audits rather than advancing design work [4]. In distributed organizations, the lack of unified governance also increases coordination challenges and configuration risk [7]. Reproducibility, which is essential for simulation-based validation in safety-critical industries, is weakened when prior inputs, assumptions, solver settings, and execution environments cannot be reliably recovered [8], [9].

Prior studies have addressed simulation data management (SDM) in PLM environments and computer-aided design (CAD)–CAE integration [5], [6], while established simulation process and data management (SPDM) literature has defined broader architectural and governance principles [1], [4]. More recent research has extended SDM toward digital-twin environments and lifecycle-oriented information models linking CAE models, simulation conditions, and simulation data [10], [11]. In parallel, recent studies on engineering digital threads have emphasized lifecycle-wide data connectivity, traceability, heterogeneous-system integration, and relational continuity among engineering information objects [12], [13], [14]. Research on model-based systems engineering (MBSE)–PLM integration has similarly highlighted the difficulty of maintaining consistent engineering information flows across systems and lifecycle stages [15].

Nevertheless, there are three gaps remaining. First, many existing approaches focus on individual elements such as simulation information modeling, geometry integration, digital thread architecture, or lifecycle connectivity rather than an integrated end-to-end CAE governance architecture. Second, quantified empirical evidence across multiple industrial contexts remains limited. Third, the challenge of embedding simulation governance within an existing PLM data model while limiting modification to the established product structure has received limited attention. Recent PLM-based digital-twin and simulation-data-management studies [16], [17], together with digital-thread studies [10], [11], [12], [13], [14], [15], provide important theoretical and architectural foundations, but limited evidence exists on implemented PLM-native CAE governance frameworks evaluated across contrasting industrial environments. Table 1 provides a structured comparison of the most relevant prior studies against the present work across four dimensions: integration scope, industrial validation, quantified metrics, and PLM-native implementation.

This paper presents PLM for CAE, a framework that embeds simulation lifecycle management within the enterprise PLM data model and process engine. The framework integrates simulation request management, CAD association, CAE model governance, HPC execution, result archival, and digital-thread traceability within a unified architecture. The specific contributions are:

1) A PLM-native simulation data model that extends the standard PLM product structure with CAE-specific object types and governed relationships, supporting traceability from product revision to simulation outcome.

2) An HPC–PLM integration architecture using boundary-layer agents to retrieve version-controlled inputs and capture execution metadata and result references after solver completion.

3) An end-to-end simulation workflow embedded within the PLM process engine, incorporating mandatory governance gates, change-driven re-analysis notification, and governed result archival.

4) Empirical evaluation across two contrasting industrial deployments: a railway equipment manufacturer operating under structural safety requirements and a consumer goods manufacturer operating under high-velocity product development cycles, with performance outcomes collected over a twelve-month post-implementation period.

Figure 1 presents the overall CAE system integration strategy, showing the relationship among CAE application processes, the CAE digital workspace, SPDM/PLM for CAE, and the enterprise PLM application.

This study is guided by the following research questions:

RQ1: How can CAE lifecycle governance be embedded within an existing enterprise PLM environment while limiting modification to the established product data structure?

RQ2: Which PLM-based governance mechanisms are associated with observed improvements in simulation traceability, model reuse, retrieval efficiency, and reproducibility?

RQ3: How should a PLM for CAE architecture be configured differently for compliance-driven and velocity-driven engineering organizations?

The remainder of this paper is structured as follows. Section 2 characterizes the current state of CAE workflow data management in industrial practice. Section 3 analyses the specific challenges arising from the disconnect between CAE environments and PLM systems. Section 4 describes the research methodology; Section 5 presents the PLM for CAE architecture, including the extended data model, workflow integration, and HPC connectivity framework. Sections 6 and 7 describe the two industrial case studies and document the implementation approach and measured outcomes in each deployment context. Section 8 discusses framework scalability, the simulation digital thread contribution, limitations, and future research directions. Section 9 presents conclusions.

The management of simulation data in industrial engineering organizations has been extensively documented as a source of operational inefficiency and governance risk [1], [2]. While CAE workflows follow a broadly consistent sequence of activities across discrete manufacturing sectors—encompassing simulation request, geometry preparation, execution, post-processing, and archival—the data management practices underlying each stage are frequently fragmented, unstandardized, and disconnected from the enterprise systems that govern product design data [3], [4]. This section characterizes the current state of each workflow stage, drawing on published surveys and practitioner literature to establish the evidence base for the challenges formalized in Section 3.

The simulation process typically originates with an engineering request initiated by a design engineer, project lead, or product development team. At this stage, critical information defining the intent and scope of the analysis must be established, including the objectives of the simulation, applicable load cases, boundary conditions, material assumptions, acceptance criteria, and the governing design revision against which the analysis is to be conducted.

In current industrial practice, this information is predominantly communicated through informal channels—emails, spreadsheets, verbal discussions, or meeting notes—rather than being captured within a structured, system-managed record [2], [5]. Therefore, the intent and assumptions underlying a simulation engagement are inconsistently documented, rendering them difficult to recover for audit purposes or to communicate reliably to successor engineers. This informality at the initiation stage propagates downstream, as subsequent simulation activities are conducted without a formally governed link to the product structure or design revision that motivated the analysis.

Following the definition of the simulation request, the relevant CAD geometry is retrieved—typically from the PLM system, where master product design data is managed under revision control. However, the geometry representation optimized for design and manufacturing purposes is rarely suitable for direct use in simulation [6]. CAE specialists perform a series of preprocessing operations to produce a simulation-ready geometric representation, commonly designated as CAD for CAE or a geometry package. These operations include defeaturing, removal of non-essential geometric details, suppression of thin-walled features below mesh resolution thresholds, and idealization of structural elements such as beams, shells, and connections [6].

In most industrial implementations, this preprocessing is conducted using local tools and desktop environments operating outside the PLM vault [3], [6]. The resulting CAD for CAE geometry is stored in project-specific directories or on individual workstations without formal version control or traceability linkage to the originating design revision. Hamri et al. [6] identify this disconnection between CAD and CAE environments as a foundational source of simulation governance risk, noting that the absence of a managed geometry handoff creates the conditions for simulation to be conducted against uncontrolled or superseded design states. As product designs undergo iterative revision during development, the probability of this mismatch increases without a governed geometry export mechanism.

Figure 2 illustrates the typical CAE Request initiation and geometry preparation sequence in current industrial practice, highlighting the manual handoff points at which traceability is lost between the PLM-managed design state and the simulation-ready geometry.

Following geometry preparation, the simulation workflow proceeds to model assembly and execution, including mesh generation, solver input definition, boundary condition and load case application, and submission of the analysis job for computation. In industrial practice, these activities are typically executed on HPC platforms, including on-premises clusters, cloud-based HPC services, or hybrid environments, to support large-scale structural, fluid, and multiphysics analyses that exceed desktop computing capacity [2], [4].

Although HPC environments provide the required computational performance, they also introduce a governance discontinuity. Solver inputs, intermediate files, job records, and raw outputs are often stored in HPC file systems or user-specific directories outside enterprise data management controls [4]. As a result, these artifacts are rarely linked back to PLM in a structured manner. The HPC–PLM boundary is therefore a major point of traceability loss, particularly when key metadata such as solver version, execution timestamp, convergence history, and hardware environment is not captured or governed after job completion [4].

Figure 3 illustrates the high-level CAE task flow from model preparation and solver execution through reporting and subsequent CAE maintenance activities.

Upon completion of the solver execution, simulation results are analyzed through post-processing activities. Engineers interrogate field output data—including stress and strain distributions, displacement fields, temperature profiles, flow characteristics, and modal responses—to assess product performance against the acceptance criteria defined at the request stage. Findings are documented in technical reports, which form the primary communication artifact between the simulation team and design engineering, program management, and regulatory stakeholders.

In current industrial practice, simulation reports are predominantly produced in desktop presentation or document formats and distributed via email or stored in shared network directories [2], [5]. Recent research on lifecycle data integration and digital-thread implementation similarly emphasizes that engineering artifacts must be managed through consistent lifecycle relationships if they are to remain reusable, traceable, and auditable across product-development stages [20]. This selective and inconsistent archival of reporting artifacts means that the formal record of simulation findings is frequently incomplete at the program level, creating risk for design decisions that depend on simulation evidence and for regulatory submissions that require a complete analysis evidence chain.

The final stage of the simulation workflow is the archival of simulation artifacts for future reference, reuse, and audit. These artifacts include CAD-for-CAE geometry, mesh files, solver input decks, job execution records, result datasets, and technical reports. In well-governed workflows, they should be stored with sufficient metadata to support retrieval, reuse, and reproducibility.

In practice, however, simulation archival is often a manual, end-of-project activity with limited standardization [2], [3]. Simulation data is commonly distributed across local workstations, HPC directories, shared drives, and selective PLM uploads, without a unified repository or consistent metadata schema [5]. Recent studies on digital-twin and engineering data-management frameworks similarly emphasize that simulation-related data often remains distributed across heterogeneous systems unless governed through explicit data models and lifecycle relationships [2]. Consequently, validated simulation models from prior programs can become underutilized knowledge assets because the metadata needed for discovery, context, lifecycle association, and reuse is not systematically captured [1], [3], [10], [11]. Recent digital-thread and lifecycle information-model research identifies this as a persistent limitation of engineering data environments: knowledge capture and reuse require explicit object relationships and lifecycle-aware data models rather than file storage alone [14], [21]. Overall, the current-state workflow shows that simulation artifacts are generated across multiple systems and handoff points, while only selected outputs are formally captured in enterprise-managed repositories. The systems-engineering implications of this distributed workflow are analyzed in Section 3.

Building on the workflow characterization in Section 2, this section translates the observed current-state practices into four management and systems-engineering challenges: fragmented simulation data, limited design-to-simulation traceability, inconsistent governance, and constrained reuse of validated simulation knowledge. The emphasis is not on restating workflow steps, but on identifying the structural problems that prevent CAE data from functioning as governed enterprise knowledge.

The distributed storage practices described in Section 2.5 create a fragmented simulation-data environment in which artifacts are difficult to search, relate, and govern across programs. The primary management problem is not simply that files reside in different locations, but that simulation artifacts lack a consistent metadata structure and enterprise-level relationship model. As a result, engineers may reconstruct models that already exist but cannot be reliably discovered, consuming program resources without corresponding engineering advancement [1], [2], [3], [5].

Maintaining a formal, queryable linkage between CAD design revisions and corresponding simulation activities is among the most technically significant challenges in CAE data governance [7], [12], [13], [14]. Without a governed association mechanism, it is not possible to determine reliably whether a simulation result reflects the current product configuration or a superseded design state, introducing risk into design decisions that depend on simulation evidence [5], [6]. In regulated industries, the inability to demonstrate formally that all required analyses were conducted against the approved design configuration constitutes an audit risk and can delay certification submissions [22]. Grieves and Vickers [7] identify the absence of a governed design-to-simulation linkage as a fundamental gap in digital thread realization, noting that the value of simulation evidence is contingent on its traceability to a formally managed product state.

Simulation activities in most industrial organizations are conducted without consistent governance processes or standardized data capture practices [2], [3]. Material property definitions, boundary condition specifications, solver parameters, and modeling assumptions are documented inconsistently across individual project files and informal report appendices that are not subject to version control or formal review. This variability makes it difficult to compare results across teams, enforce best practices, or audit simulation quality [3]. The National Agency for Finite Element Methods and Standards (NAFEMS) simulation governance and Process Maturity Benchmark Study [3] reports that a large proportion of engineering organizations operate at low maturity levels with respect to simulation governance, characterized by ad hoc processes and limited integration with enterprise workflow systems—representing both a governance risk and a barrier to scaling simulation-driven design effectively.

Reuse of validated simulation models depends on preserving not only the model files, but also their governing design context, assumptions, simulation conditions, lifecycle relationships, and validation status [5], [10], 11]. In the absence of sufficient model characterization, contextual metadata, and searchable repositories, engineers may be unable to assess and adapt prior simulation models efficiently, contributing to unnecessary model reconstruction [2], [23].

This study adopts a comparative industrial case-study design using a before-and-after evaluation of PLM for CAE implementation in two large engineering organizations. The purpose of the research design was not to isolate causal effects under controlled experimental conditions, but to evaluate how the framework was configured and what operational changes were observed after deployment in two contrasting industrial contexts. The study combines process audit evidence, historical project records, interview inputs, PLM system logs, workflow records, and program management dashboards.

The two case organizations were selected through purposive sampling [24] because they represented contrasting governance environments. Case Study 1 was selected as a compliance-driven engineering environment where regulatory evidence chains, formal design-change impact assessment, and multi-site traceability were primary concerns. Case Study 2 was selected as a velocity-driven development environment where short product cycles, high program volume, simulation request prioritization, and model reuse were primary concerns. This contrast enabled assessment of whether the same PLM for CAE architecture could be configured for different engineering-management priorities without requiring fundamental redesign.

Table 2 summarizes the study scope, implementation duration, observation period, organizational scale, simulation activity volume, and interviewee roles for the two case-study deployments.

Exact calendar dates are withheld for confidentiality; however, both deployments were evaluated over a twelve-month post-implementation observation period.

Pre-implementation baselines were reconstructed using process audits, interviews with simulation leads and program managers, and review of historical project records. Because pre-implementation workflows were not consistently governed in PLM, some baseline values are estimated ranges rather than direct system-extracted measurements. Post-implementation values were collected primarily from PLM object relationships, workflow records, system activity logs, dashboards, and simulation team records. Therefore, reported improvements should be interpreted as directional and order-of-magnitude operational changes rather than statistically isolated causal effects.

Metric-specific record counts were not consistently recoverable for the reconstructed pre-implementation baselines. Therefore, the overall task volumes reported in Table 2 should be interpreted as study-level population indicators, rather than as the exact denominator for every reported performance metric. The railway case reviewed approximately 500+ simulation tasks and included approximately 1,400 migrated CAE model records, while the consumer goods case reviewed approximately 600+ simulation tasks and included approximately 2,100 CAE-related records. Metric-specific denominators varied by indicator: traceability was assessed against active simulation activities with PLM product-revision linkage, reuse was assessed against new analyses initiated during the observation period, preparation and turnaround time were assessed from available workflow timestamps and audit samples, and retrieval-time measures were based on audit exercises and PLM search records. Where exact baseline record counts were unavailable, the values are reported as estimated ranges and interpreted as directional operational indicators rather than statistically precise sample estimates. Table 3 summarizes the pre-implementation and post-implementation data sources used for each reported performance metric and indicates the status of the corresponding baseline evidence.

Table 4 defines the performance metrics, calculation rules, observation periods, and interpretation of the reported ranges used in the subsequent case-study evaluations.

Model adaptation is defined as initiation of a new CAE Analysis Revision through a formal variant relationship to a prior CAE Model Revision where mesh topology is substantially retained (greater than 50% mesh reuse) and only load cases, boundary conditions, or minor geometry modifications are applied. Adaptation of boundary conditions alone without mesh reuse is counted as full reconstruction. Where one simulation is associated with multiple product revisions in a parametric study, it is associated with the primary governing product revision and counted once in the traceability numerator.

The PLM for CAE framework is founded on the principle that simulation data, workflows, and artifacts constitute integral components of the product lifecycle and must therefore be governed within the same enterprise data management environment that controls product design information. In traditional industrial practice, simulation outputs are produced and stored independently of PLM systems, resulting in the traceability deficits and governance failures documented in Section 3. The framework addresses this by positioning the PLM system as the authoritative backbone for simulation lifecycle governance—managing metadata, workflow state, and relational structure—while preserving the computational autonomy of HPC environments for solver execution. This separation of governance and computation is consistent with the architectural principles established in SPDM literature [1], [4] and with the digital thread concepts advanced by Grieves and Vickers [7] and the U.S. Department of Defense (DoD) Digital Engineering Strategy [22].

The framework architecture comprises four integrated components: an integration concept defining the governance boundary between PLM and HPC; a simulation workflow structure embedded within the PLM process engine; an extended PLM data model representing simulation lifecycle entities and their relationships; and an HPC connectivity layer implemented through boundary-layer integration agents. Each component is described in the subsections that follow.

The PLM for CAE integration concept establishes a clear boundary between two operational environments: the PLM system, which governs simulation metadata, workflow state, relational structure, and lifecycle traceability; and the HPC platform, which executes computationally intensive simulation workloads. This separation ensures that PLM remains the authoritative environment for governance, lifecycle relationships, traceability, and reuse, while dedicated computational environments manage numerical execution and transient simulation data [1], [10], [11].

Within this framework, PLM manages key simulation information, including analysis requests, CAD references, simulation metadata, technical reports, and result summaries. Analysis requests are captured as PLM-native objects linked to the governing design revision, while CAD references maintain version-controlled associations between simulation activities and source geometry. Simulation metadata, such as model definitions, solver settings, boundary conditions, and material assignments, is managed under PLM revision control and change processes [7], [9], [17].

HPC remains responsible for solver execution, including FEA, CFD, and multiphysics analysis using tools such as ANSYS, Abaqus, or OpenFOAM. Rather than storing raw computational datasets in PLM, the framework governs metadata, relationships, and result references. Figure 4 illustrates this PLM–CAE–HPC integration concept and the governed interface connecting the three operational layers [1], [4].

The PLM for CAE framework integrates the simulation lifecycle into a structured, PLM-managed workflow that enforces governance through state management, notifications, approvals, and audit trails. The workflow consists of sequential stages with defined entry conditions, mandatory data capture, and exit criteria before progression [3].

The process begins with a formal CAE Request object in PLM, capturing the analysis purpose, scope, product structure node, design revision, load cases, and acceptance criteria. This replaces informal email- or spreadsheet-based requests and establishes the traceability anchor for all downstream simulation artifacts [2], [5].

After approval, the required CAD geometry is retrieved from the PLM vault at the referenced design revision, ensuring that simulation work is based on the controlled master design rather than unmanaged local copies. The geometry is then prepared for CAE use, with the simulation-ready representation stored in PLM or formally linked to the originating design revision [6].

Simulation execution is performed on the HPC platform, while PLM manages task definition and lifecycle tracking. After solver completion, results are post-processed, documented in technical reports, reviewed through a structured approval workflow, and archived with metadata and result references in PLM. Figure 5 illustrates the end-to-end workflow from request initiation to result archival, including the governance gates at each transition.

Embedding this workflow in PLM also enables automatic design-change notifications. When a Change Notice affects a product structure node, associated open simulations are flagged for review, ensuring that the impact of design changes is assessed before final disposition [3].

Table 5 summarizes the principal organizational roles involved in the PLM for CAE workflow and clarifies how technical and managerial responsibilities are distributed across the simulation lifecycle.

These roles distribute simulation governance across both technical and managerial responsibilities. The framework therefore does not treat CAE governance as a purely IT function; rather, it formalizes the interaction among requesters, simulation engineers, reviewers, approvers, program managers, and PLM/HPC administrators.

To support simulation lifecycle governance within PLM, the PLM for CAE framework introduces simulation-specific object types as an overlay to the standard product structure. As shown in Figure 6, this data model extends existing PLM relationships without disturbing the established product data architecture, aligning with Principle P1 (Overlay-based limited modification) [9], [19].

At the top of the hierarchy, the product revision serves as the authoritative reference object. It is linked to simulation-derived entities through bidirectional Source and Target relationships, ensuring that every simulation artifact remains associated with the governing design state. This provides the configuration provenance needed for traceable engineering analysis and enables queries in both directions: from a product revision to its related simulations, and from a simulation artifact back to the product configuration it represents [7], [17].

The CAE Model Revision represents the reusable simulation model asset within the PLM for CAE data model. It is associated with the governing Product/Design Revision through Source and Target relationships so that the model remains traceable to the controlled product configuration it represents. The CAE Analysis Revision represents an individual simulation analysis or execution instance and is linked to the CAE Model Revision through a formal Defining Relationship, ensuring that each analysis instance is associated with at least one managed simulation model. Where no dedicated CAE Geometry Revision exists, the CAE Model Revision connects directly to the Design Revision through the fallback Source/Target relationship, preserving design-to-simulation traceability while maintaining the overlay approach [9], [19].

The CAE Geometry Revision manages two geometry artifact types aligned with simulation preprocessing practice: neutral representations, such as standard for the exchange of product model data (STEP), for exchange across CAD and CAE systems, and simplified or defeatured geometry prepared specifically for meshing and numerical analysis [6], [25]. Managing these artifacts separately ensures that both the interoperable geometry and the simulation-specific idealization remain traceable to the originating design revision. Source and Target relationships link the CAE Geometry Revision to the Design Revision, while Made By relationships capture any child design parts created during CAE geometry instantiation, supporting assembly-level traceability.

The CAE Analysis Revision represents a specific simulation instance associated with CAE Model Revision. It governs the artifacts needed to execute and reproduce an analysis, including input files, solver parameters, and result datasets [1], [5]. Self-referencing Include relationships support sub-analyses and parametric variants, while relationships to CAE Technical Report, CAE Specification, and CAE Report objects ensure that reporting artifacts remain formally linked to the governing analysis record and controlled under the same revision framework.

Mesh files and solver parameter files are associated with the CAE Model Revision through Specification relationships, supporting repeatability and reproducibility in accordance with Verification and Validation (V&V) expectations [8], [9]. The CAE Results Revision captures formal simulation outputs and links them to the corresponding CAE Analysis Revision through a Result relationship. Result datasets, processed visualizations, and validation reports are managed as structured documents to support traceability, auditability, reuse, and long-term archival [1], [3].

Together, these relationships establish a governed PLM-based simulation data model linking product design, geometry preparation, model definition, analysis execution, and result archival. This enables traceability, querying, reproducibility, and reuse of simulation knowledge across the lifecycle [4], [5], [14], [21].

This relationship-oriented representation is consistent with recent lifecycle information-model and digital-thread research, in which explicit object relationships are used to maintain continuity among engineering models, lifecycle states, and heterogeneous information systems [11], [13].

A defining architectural principle of the PLM for CAE framework is the explicit preservation of the distributed computational model that characterizes industrial simulation practice. Figure 4 illustrates the PLM governance environment and the CAE-HPC execution layer. Although CAE and HPC are functionally distinct, they are grouped within a single execution region in the figure because both operate outside the PLM-controlled data-management layer. The framework does not conflate these tiers; rather, it establishes governed interfaces between them that enforce traceability without constraining computational throughput or workflow flexibility. This approach is consistent with the SPDM architectural principle of separating simulation governance from simulation execution, as documented by NAFEMS [1] and Siemens Digital Industries [4].

Figure 7 illustrates the integrated PLM–CAE–HPC digital thread architecture, including PLM-governed input retrieval, HPC solver execution, simulation result generation, and the return of execution metadata and result references to PLM.

Simulation execution remains on HPC infrastructure, including on-premises central processing unit/graphics processing unit (CPU/GPU) clusters, cloud-based services, and hybrid environments, because large-scale FEA, CFD, and multiphysics workloads require parallel storage and distributed execution capabilities that are not suitable for PLM-resident computation [1], [4]. The PLM for CAE framework therefore does not move solver execution into PLM; instead, it establishes a governed boundary between the PLM vault and the HPC execution environment.

This boundary is managed through lightweight integration agents. At job initiation, the agents retrieve version-controlled and approval-gated solver input decks and geometry packages from the PLM-managed vault, ensuring that simulations use only formally approved inputs. This reduces the risk of analyses being executed against uncontrolled or superseded geometry, a key traceability risk in unmanaged CAE workflows [6].

The agents also enforce configuration control at the simulation execution boundary. Only approved and versioned inputs are used, and deviations from the approved configuration must be recorded before execution. This extends established PLM configuration-management principles to HPC-based simulation workflows, where configuration mismatch is a common governance failure [5], [6], [8], [13].

Upon job completion, the agents harvest execution metadata, including solver version, execution timestamp, runtime, convergence status, HPC environment identifier (ID), and references to generated datasets, validation reports, and post-processed outputs. These records are registered against the originating CAE Analysis Revision in PLM, linking simulation outputs back to the governing product revision and closing the simulation digital thread [7], [12], [13], [14].

This bidirectional governance loop—PLM-controlled inputs to HPC and HPC-generated metadata back to PLM—forms the central integration principle of the PLM for CAE framework and directly addresses HPC–PLM traceability loss.

Table 6 summarizes the HPC boundary-agent interface, including workflow triggers, inputs, agent actions, outputs returned to PLM, and failure-handling rules.

Very large result files are not necessarily transferred into the PLM vault. Instead, the framework registers governed file-location references, metadata records, checksums, and lifecycle state information. Only formal reports, reduced datasets, validation evidence, and required archival artifacts are stored as managed PLM objects when full raw-result storage is impractical.

Agent authentication with the PLM system is managed through a dedicated service account with read access to the simulation document vault and write access to CAE Analysis Revision status fields. Authentication with the HPC scheduler uses the scheduler's native application programming interface (API), such as Simple Linux Utility for Resource Management (SLURM) Representational State Transfer (REST) API or Portable Batch System (PBS) Professional API, with credentials stored in an encrypted agent configuration file accessible only to the agent service process. Job status is synchronized through periodic polling at configurable intervals, with status updates written to the CAE Analysis Revision in PLM after each poll cycle. Result file integrity is maintained through 256-bit secure hash algorithm (SHA-256) checksum verification performed at registration and periodically thereafter, with any discrepancy flagged within the PLM record and routed to the responsible simulation engineer for resolution.

Table 7 maps the core PLM for CAE framework components to their governing PLM object types, governance functions, and the specific CAE data-management challenges addressed.

The PLM for CAE architecture is governed by four design principles that inform each component of the framework:

P1—Overlay-based limited modification: simulation governance extensions shall be implemented as an overlay to the existing PLM product structure, limiting modification to core product-revision entities and preserving established design data workflows. [9], [19].

P2—Separation of governance and computation: PLM governs metadata and workflow state; HPC executes simulation workloads. Neither environment shall assume the responsibilities of the other [1], [4].

P3—Mandatory traceability at initiation: Every simulation engagement shall be formally associated with a governed product revision before any analysis activity is authorized to proceed [3], [7].

P4—Closed digital thread for governed analyses: Each simulation activity used for formal design review, release, certification, or program decision-making shall return governed metadata and result references to the PLM environment upon completion. Exploratory, sensitivity, or transition-period analyses may be temporarily executed outside the formal workflow; however, they must be registered in PLM before being used as formal design evidence.

Exceptions to the governed workflow are limited to exploratory simulations, preliminary sensitivity studies, and transition-period activities. Such exceptions must be authorized by the responsible simulation lead or program engineering authority. Unregistered simulations may not be used for formal design release, certification evidence, or customer-facing technical approval unless they are subsequently registered in PLM with the required design revision linkage, execution metadata, and result references.

The first deployment was conducted at a global manufacturer of railway maintenance-of-way equipment with engineering sites in North America, Europe, and Asia. The organization operates in a regulated environment governed by structural safety standards such as EN 12663, UIC 566, and customer-specific technical requirements. As a result, formal simulation evidence chains are required for certification submissions and technical approvals. Simulation activities include static structural analysis, fatigue and fracture assessment, dynamic load evaluation, crash energy management, and thermal analysis of traction systems.

The pre-implementation baseline was established through process audits, interviews with simulation leads and program managers, and review of historical project records. Before PLM for CAE implementation, simulation data was highly fragmented. Analysis requests were managed through email, with no formal linkage to product structure nodes or design revisions. FEA models were stored in program-specific network folders using informal naming conventions, and results were archived at the program level, limiting cross-program retrieval and reuse.

This created significant challenges of governance and compliance. Regulatory audits required manual reconstruction of simulation evidence chains, consuming engineering effort and increasing audit risk [3], [22]. Design change notifications also did not systematically propagate to open simulation activities, creating the risk that analyses could continue against outdated configurations [7].

A pre-implementation maturity assessment using an internal maturity assessment informed by NAFEMS simulation governance guidance [3], conducted through structured interviews and project record review, placed the organization at Level 1 (Ad Hoc) for simulation request Governance, Model and Data Management, and Results and Knowledge Management, and at Level 2 (Repeatable) for Process Integration and Automation—reflecting established HPC operational processes but the absence of PLM integration. The assessment was conducted by the author in collaboration with the organization's simulation team lead and PLM administrator. Organization identity and program-specific details were anonymized for commercial confidentiality.

The PLM for CAE framework was deployed within the organization’s existing PLM environment through a structured implementation program encompassing five domains: data model extension and change management integration, simulation request formalization, HPC integration, legacy data migration, and reference library governance. Implementation was conducted over a phased deployment period, with each domain reviewed against the governance requirements established in Section 5 before advancing to the subsequent phase.

The product structure was extended with simulation-specific object types and configured within the existing PLM environment without modifying core item or document schemas. This overlay preserved established product data relationships while adding governed simulation objects for traceability and lifecycle control [9], [19].

Change management integration was a key focus. Formal Change Notices in PLM were configured to notify owners of open simulation activities linked to affected product structure nodes, ensuring configuration impact review before change disposition. This addressed the design–simulation traceability gap identified in Section 3.2 [3], [22].

A structured FEA Request object was introduced as the governed entry point. Mandatory metadata—including analysis scope, product structure node, design revision, load case, regulatory standard, and solver environment—are captured at request creation, replacing informal email-based requests [2], [5].

Upon submission, the request is reviewed by an FEA Gatekeeper for completeness, resource availability, and methodology fit. Once approved, PLM automatically creates a governed FEA Analysis process object, links it to the Engineering Design Assembly, CAE Model Revision, geometry artifacts, and result objects, and assigns it to the simulation workflow queue. Figure 8 illustrates the five-stage end-to-end digital thread from request initiation to result archival.

Integration agents were deployed to interface the PLM environment with the organization’s on-premises solver cluster, implementing the boundary-layer governance mechanism described in Section 5.4. At job initiation, agents retrieve approved and version-controlled solver input decks and geometry packages from the PLM vault, ensuring that each analysis execution is conducted against formally governed inputs. Upon job completion, agents harvest execution metadata—including solver version, wall-clock time, convergence status, and HPC environment IDs together with references to the generated result artifacts and register these records against the originating FEA Analysis process object within the PLM data model. Structured workflow templates were configured to align with the organization’s standard simulation methodology, incorporating mandatory review gates for load case confirmation, mesh quality sign-off, and result approval prior to archival—ensuring that no simulation output advances to the formal knowledge archive without satisfying defined quality criteria.

A structured migration program was conducted to import simulation metadata from the organization’s prior program portfolio, encompassing approximately 1,400 validated CAE models accumulated across multiple product generations and regulatory submission cycles. Metadata records—including model purpose, analysis type, governing product revision, applicable regulatory standard, solver environment, and validation status—were ingested into the PLM data model, establishing a governed simulation knowledge base accessible through the PLM search and retrieval interface. This migration ensures that institutional simulation knowledge accumulated across prior programs is formally managed and discoverable within the same governance framework applied to new simulation activities, directly addressing the model reuse limitations identified in Section 3.4 [2], [5]. Figure 9 illustrates the streamlined FEA archival process enabled by the PLM for CAE framework for both new and migrated simulation records.

Material property libraries and standard load case specifications—including EN 12663 load case sets and organization-specific fatigue assessment parameters—were integrated into the PLM data model as governed reference objects. As illustrated in Figure 10, simulation engineers reference approved material definitions and load specifications directly from within the PLM environment at the point of analysis setup, eliminating reliance on locally maintained or informally shared reference data. This integration ensures that simulation inputs remain traceable to formally approved reference sources and are subject to the same revision control and change management processes applied to product data, a governance capability identified as critical for compliance-driven simulation environments by the NAFEMS Governance Benchmark [3].

Figure 10 illustrates a separate but complementary governance capability: the controlled FEA report library within PLM. Released simulation reports are organized within governed folders and retained under PLM lifecycle control, improving report discoverability, revision management, and auditability of completed simulation evidence.

Post-implementation metrics were collected over twelve months using PLM reports, simulation activity records, and program management feedback. Baseline values were established from the pre-implementation process audit described in Section 6.1. The results are summarized in Table 8.

Design-to-simulation traceability improved from an estimated 20–30% to 90–95% after implementation. This improvement was associated with the introduction of mandatory metadata capture at request initiation and the requirement to link simulation activities to governed product revisions. Following implementation, simulation evidence chains could be assembled more directly from PLM records in most cases, reducing reliance on manual reconstruction for compliance purposes.

Model reuse increased from approximately 5–10% to 30–40% during the post-implementation period. This increase coincided with migration of the 1,400-model knowledge base and deployment of PLM search and retrieval capability. Simulation preparation time was reduced by 20–30%. This reduction was associated with governed geometry packaging, standardized workflows, and increased availability of reusable migrated models. The time required to locate prior simulation results decreased by approximately 50%, shifting from several days to same-day retrieval in most cases [2].

A post-implementation maturity reassessment using the same NAFEMS framework and methodology placed the organization at Level 3 (Defined) for simulation request Governance and Model and Data Management, and at Level 4 (Managed) for Results and Knowledge Management and Process Integration and Automation. The advancement of two to three levels across all four dimensions within twelve months is consistent with the progression expected when simulation-governance practices become increasingly formalized and managed [3]. The assessment was conducted by the author; independent verification would further strengthen the reliability of these ratings.

Table 8 presents the pre- and post-implementation metrics for Case Study 1, with primary data sources identified.

The second deployment was conducted at a global consumer goods manufacturer with products spanning personal care, household appliances, and packaging-intensive lines. Unlike the railway case, this organization operated under compressed product development cycles, with some programs moving from concept to production within three to six months. Simulation activities included drop and impact analysis, packaging integrity, durability correlation, electronics thermal management, and injection molding simulation.

The pre-implementation baseline was established using the same methodology as Case Study 1: process audits, simulation team interviews, and historical project record review. The primary challenge was development velocity rather than regulatory compliance. Simulation teams faced tight timelines, but the absence of a structured model reuse framework forced engineers to rebuild models for minor design variations because prior validated models were difficult to locate in unstructured archives [2], [5].

Informal simulation request processes also limited resource planning and program prioritization. Urgent requests often disrupted planned analysis queues, reducing efficiency and limiting management visibility into simulation workload and status [2], [3]. A pre-implementation maturity assessment using the NAFEMS simulation governance and Process Maturity framework [3], conducted through structured interviews and project record review, placed the organization at Level 1 (Ad Hoc) across all four governance dimensions: simulation request Governance, Model and Data Management, Results and Knowledge Management, and Process Integration and Automation. The assessment was conducted by the author in collaboration with the organization's simulation team lead and PLM administrator. Program-specific details were anonymized for commercial confidentiality.

The PLM for CAE implementation at this organization was configured with particular emphasis on three operational priorities: simulation request prioritization and resource planning visibility, model variant management for rapid design derivative analysis, and packaging simulation workflow automation. The implementation approach applied the same core architecture described in Section 5, with configuration choices reflecting the velocity-driven requirements of the consumer goods development environment rather than the compliance-driven requirements of the railway context—demonstrating the configurability of the framework across substantially different organizational profiles [1], [4].

The PLM for CAE data model was implemented as a governed overlay on the organization’s existing part and design data model, introducing simulation-specific object types that integrate directly with established product structure entities without modifying the existing architecture. As illustrated in Figure 11, the existing data model—comprising Part and Design objects with associated revisions, Drawing Revisions, General Design Revisions, Material Type and Material Grade Revisions, General Documents, and Specifications—was preserved without structural modification, consistent with the overlay principle described in Section 5.3 [8], [9]. More broadly, this approach is compatible with current efforts to integrate MBSE and PLM by maintaining structured information continuity between system-level engineering representations and downstream product-development data [15].

The CAE Analysis Revision represents an individual simulation analysis or execution instance and is identified by a unique CAE Analysis ID that is passed to the HPC execution environment, linking the PLM-managed analysis record to its computational job. The CAE Analysis Revision is connected to the CAE Technical Report Revision through an Analysis Relation. The CAE Technical Report Revision, in turn, is linked to the CAE Report through an Attaches Relation and to the Specification Revision through the CAE Specification relationship, ensuring that reporting artifacts remain within the governed revision-control framework.

The CAE Model Revision represents the reusable simulation model asset and is linked to the CAE Analysis Revision through a Defining Relationship, ensuring each analysis is associated with at least one governed simulation model. The CAE Analysis Revision also maintains a governed relationship with the Material Grade Revision, which is associated with the corresponding Material Grade reference object. This enables the material configuration applied to a specific simulation analysis to be governed and traced to approved material reference data. The relationship allows different analysis revisions derived from the same CAE model to use different approved material configurations while preserving the material state associated with each analysis [1], [5].

The CAE Geometry Revision connects the CAE Model Revision and Design Revision through Source and Target relationships. It manages CAD Part/ CAD Product references, and Direct Model artifacts in Jupiter Tessellation (JT) format through Specification Relationships, supporting both native CAD and lightweight visualization formats. Where no dedicated CAE Geometry object exists, the CAE Model Revision connects directly to the Design Revision through the fallback relationship shown in Figure 11, preserving design-to-simulation traceability, as described in Section 5.3.

The analysis request workflow was extended with a resource planning integration module providing simulation team leadership with consolidated, real-time visibility into the queue of pending analysis requests, the associated program priorities, and the projected capacity utilization of the simulation team. This capability enables resource allocation decisions to be made proactively at the program level rather than reactively at the individual engineer level—replacing the informal, disruption-prone request management process characterizing the pre-implementation baseline. Supporting simulation throughput management across concurrent product development programs through PLM-managed visibility is consistent with the workflow governance principles established in the SPDM literature [1], [4] and with the program management integration requirements identified by the DoD Digital Engineering Strategy [22].

A simulation model variant management capability was implemented within the PLM data model, enabling simulation engineers to formally register a CAE model as a variant or derivative of a prior validated model through a governed variant relationship recorded in the PLM data structure. This capability—combined with the governed simulation knowledge base accessible through PLM search and retrieval—was intended to help simulation teams locate and adapt existing validated models for new product variants rather than initiating model preparation from a geometry baseline, addressing the redundant reconstruction pattern identified as the primary efficiency constraint in the pre-implementation assessment.

Variant relationships are formally recorded within the PLM data model, ensuring that the lineage between a new model and its validated predecessor is traceable and auditable—a governance requirement for organizations in which model adaptation decisions must be defensible during design reviews or product liability assessments. This capability addresses the CAE data-management and reuse challenges identified by Saarelainen et al. [5] by embedding model-variant traceability within the PLM relational structure rather than relying on informal documentation conventions.

The CAE Technical Report approval workflow, shown in Figure 12, governs the formal review and release of simulation reports within PLM. At initiation, the workflow performs an automated completeness check. If required information is missing, an error notification is issued and the workflow stops, preventing incomplete reports from entering review. If validation passes, designated stakeholders receive an early notification.

The workflow then checks whether a Reviewer is assigned. If present, the Reviewer Decision gate determines whether the report is rejected or marked as reviewed. If no Reviewer is assigned, the process moves directly to the Approver Decision gate, which serves as the primary control point. Rejection returns the report for correction and resubmission, while approval triggers a revision check. For non-initial revisions, the prior revision and attached dataset are formally superseded before approval.

After approval, completion notifications are sent to the document owner and nominated recipients. This structured sequence ensures that simulation reports are released only after meeting defined review and approval criteria, while prior revisions are superseded in a controlled and auditable manner [3]. The workflow applies product data management lifecycle principles to the simulation reporting context [8], [9].

For packaging simulation workflows, the framework was integrated with the organization’s packaging CAD environment to enable automated geometry packaging triggered by packaging design freeze events within the PLM workflow. When a packaging design freeze milestone is reached and formally recorded within PLM, the integration automatically initiates a governed geometry export from the packaging CAD environment and registers the resulting geometry package within the PLM vault, associated with the frozen design revision and linked to the relevant simulation request objects. This automation eliminates the manual geometry handoff step that previously introduced latency and geometry version risk at the critical design-freeze-to-simulation transition—a vulnerability directly consistent with the geometry currency risk identified by Hamri et al. [6] and documented in Section 3.2. By coupling geometry exports to the PLM-managed design freeze event, the framework ensures that packaging simulation is consistently initiated against the correct, formally frozen geometry configuration for each product launch program.

Post-implementation metrics were collected over twelve months using the same methodology as Case Study 1. Baseline values were established from the pre-implementation process audit described in Section 7.1, and results are summarized in Table 9.

Design-to-simulation traceability improved from approximately 15–25% to 85–90% during the post-implementation period. This improvement was associated with mandatory metadata capture at FEA Request creation and increased use of PLM-based product-revision linkage. The remaining 10–15% gap reflects rapid exploratory analyses conducted outside the formal workflow during the transition period.

Model reuse increased from approximately 5–10% to 50–65%, the largest improvement across both case studies. This increase coincided with the introduction of model variant management, the governed knowledge base, and PLM search capability, which together improved engineers’ ability to locate and adapt prior validated models [1], [4].

Simulation preparation time was reduced by 30–40%, with the greatest gains observed in packaging workflows where automated geometry packaging was implemented. Turnaround time improved by 25–35%, and the time required to locate prior simulation results was reduced by 60–75%, a change associated with improved discoverability through the PLM-governed knowledge base [2].

PLM dashboards also provided program management with real-time visibility into simulation status, improving planning and gate review integration [4]. A post-implementation maturity reassessment using the same NAFEMS framework and methodology placed the organization at Level 3 (Defined) for simulation request Governance and Model and Data Management, and Level 4 (Managed) for Results and Knowledge Management and Process Integration and Automation—consistent with the advancement observed in Case Study 1 despite the different operating context [3]. The assessment was conducted by the author; independent verification would further strengthen the reliability of these ratings.

Table 10 compares the two industrial deployment contexts, including their primary drivers, simulation domains, integration focus, HPC environments, key outcomes, knowledge-base structures, and governance maturity progression.

This section interprets the findings in relation to the three research questions introduced in Section 1. Because the study uses a before-and-after industrial case-study design rather than a controlled experimental design, the reported outcomes are interpreted as observed improvements associated with the PLM for CAE implementation, not as isolated causal effects of the framework alone.

RQ1 asked how CAE lifecycle governance can be embedded within an existing enterprise PLM environment while limiting modification to the established product data structure. The two deployments indicate that the most practical approach is to extend the existing PLM structure through a governed simulation overlay rather than replacing the core product model. In this approach, established product revision, design revision, document, and material-reference structures remain authoritative, while CAE-specific objects are added to manage simulation requests, CAE models, geometry packages, solver inputs, execution metadata, results, and reports.

This overlay approach enabled simulation governance to be introduced with limited modification to the core product structure. However, it should not be described as “zero disruption,” since configuration work was still required. The implementation required new object types, metadata fields, workflow templates, approval roles, and HPC interface logic. The contribution is therefore best understood as a controlled PLM extension that preserves core product-data relationships while adding simulation lifecycle governance.

From an engineering-management perspective, this is important because the framework formalizes accountability for simulation evidence. Instead of treating simulation files as detached technical outputs, it links CAE activities to specific product revisions and workflow states. This makes simulation evidence more traceable, reviewable, and reusable within the enterprise digital thread. The findings are consistent with recent digital-thread research emphasizing relationship-based lifecycle information structures rather than the consolidation of all engineering data into a single monolithic repository [12], [13], [14].

No major PLM platform-version upgrade occurred during the twelve-month observation period in either deployment; therefore, the study confirms limited modification to the deployed product data structure but does not empirically verify upgrade compatibility across a major PLM platform release.

RQ2 asked which PLM-based governance mechanisms are associated with improvements in traceability, reuse, retrieval efficiency, and reproducibility. The results suggest that the observed improvements were associated with a combination of governance mechanisms rather than a single isolated intervention. The CAE Request object was associated with improved traceability because it required design revision, product structure node, analysis scope, load case, acceptance criteria, and solver environment information at initiation. Version-controlled CAD/CAE relationships were associated with reduced configuration-mismatch risk. Approval gates were associated with stronger review discipline and audit readiness. HPC boundary agents supported reproducibility by retrieving approved inputs and returning execution metadata to PLM. The simulation knowledge archive and variant relationships were associated with improved model reuse by making prior validated models more discoverable and traceable. The observed importance of structured model relationships and simulation metadata is also consistent with recent simulation data management in the digital twin (SDM-DT) research emphasizing explicit associations among CAE behavior models, simulation conditions, and lifecycle data [10], [11].

Table 11 maps the principal PLM for CAE governance mechanisms to the actions introduced and the observed outcome measures associated with each mechanism.

This interpretation provides a more defensible explanation than attributing all gains to the framework. For example, model reuse in the consumer goods case likely reflected the combined influence of searchable model records, variant relationships, and a high proportion of derivative product programs. Similarly, preparation-time reduction likely reflected governed geometry packaging, model reuse, and workflow automation rather than PLM integration alone.

RQ3 asked how the PLM for CAE architecture should be configured differently for compliance-driven and velocity-driven organizations. The two case studies show that the same core architecture can support different governance priorities.

In the railway case, the primary driver was compliance. The configuration emphasized design-revision linkage, regulatory standards, load-case governance, change-driven re-analysis notification, and formal result archival. The strongest observed outcome was design-to-simulation traceability, which reached approximately 90–95% after implementation.

In the consumer goods case, the primary driver was development velocity. The configuration emphasized request prioritization, model variant management, packaging simulation automation, and resource visibility. The strongest observed outcome was model reuse, which increased to approximately 50–65%, reflecting the greater number of derivative product programs.

Table 12 provides a structured comparison of PLM for CAE architectural components across both deployments.

The observed benefits were accompanied by implementation effort. In Case Study 1, the deployment was completed over approximately four to five months from initiation to full production rollout across three engineering sites. Legacy data migration covering approximately 1,400 CAE model records required a dedicated data-cleansing and ingestion effort over approximately six to eight weeks. Training was delivered to simulation engineers, FEA Gatekeepers, and program managers across all sites. User adoption—measured as the proportion of new simulation activities initiated through the formal PLM workflow—reached approximately 70% at three months, 85% at six months, and 90–95% at twelve months post-deployment, with the residual reflecting exploratory analyses managed under the authorized exception policy described in Section 5.4 (Principle P4).

In Case Study 2, the deployment covered five engineering sites over approximately six to eight months. The broader scope of simulation variant management configuration and packaging CAD integration required additional workflow setup time. User adoption followed a similar trajectory, reaching approximately 85–90% at twelve months.

In both cases, recurring administrative workload was introduced: mandatory metadata entry at request creation, approval-gate review, exception monitoring, and failed-job resolution. Average metadata entry time per simulation request was estimated at five to ten minutes above the pre-implementation baseline. These costs should be weighed against the governance value of traceability, reuse, audit readiness, and reproducibility. The framework is most suitable where simulation volume, compliance requirements, or program complexity justify the governance investment. Detailed implementation labor records were not retained in a form that allows precise person-month calculation by workstream. Based on retrospective implementation planning records and participant estimates, the railway deployment required an estimated 8–10 person-months across PLM configuration, CAE workflow design, HPC integration, legacy data migration, testing, training, and rollout support. The consumer goods deployment required an estimated 11–14 person-months, reflecting the broader scope of model variant management, resource-planning configuration, and packaging CAD automation. These values should be interpreted as approximate implementation-effort ranges rather than audited labor measurements.

Several limitations remain. First, this was a before-and-after case-study evaluation, not a controlled experiment. Second, both organizations experienced concurrent changes during the observation period, including team restructuring and program-management process changes. These factors may have influenced preparation time, turnaround time, reuse, and management visibility.

Third, some pre-implementation baselines were reconstructed from process audits, interviews, and historical records because earlier workflows were not consistently tracked in PLM. Post-implementation values were more system-generated. Therefore, part of the measured improvement may reflect improved measurement capability as well as operational improvement.

Fourth, both cases involved large engineering enterprises with established PLM environments and dedicated simulation teams. The findings should not be generalized automatically to small and medium-sized enterprises, organizations without mature PLM platforms, or sectors outside discrete manufacturing.

Fifth, upgrade compatibility was not directly tested during the observation period. Although the framework was implemented as an overlay with limited modification to core product-revision entities, neither deployment underwent a major PLM platform-version upgrade during the twelve-month evaluation window. Future work should evaluate whether the configured simulation objects, workflows, relationship rules, and HPC boundary agents remain stable across major PLM platform upgrades.

Future research should evaluate the framework across additional industries, smaller organizations, and controlled comparison settings. Further work should also develop a PLM for CAE-specific maturity model, investigate AI-assisted simulation retrieval and reuse, and extend the digital thread to include physical test data and field-performance feedback.

Overall, the two case studies suggest that CAE governance can be strengthened when simulation requests, design revisions, CAE models, HPC metadata, result artifacts, and approval workflows are managed as part of the enterprise PLM digital thread. The framework provides a structured path for moving simulation data from fragmented technical outputs toward governed enterprise knowledge.

This paper presented PLM for CAE, a structured framework for integrating simulation lifecycle management with the enterprise PLM environment. The framework addresses the persistent disconnect between CAE and PLM environments by extending the PLM data model to represent simulation artifacts, embedding simulation workflows within the PLM process engine, and integrating HPC execution environments through governed interface agents.

Evaluation across two industrial deployments provided preliminary empirical evidence regarding the practical applicability of the framework in large, PLM-enabled engineering enterprises. The railway equipment case emphasized regulatory compliance and multi-site traceability, while the consumer goods case emphasized model reuse velocity and resource planning. Over the twelve-month post-implementation observation period, both deployments reported improvements in traceability, model reuse, preparation time, retrieval efficiency, and governance maturity indicators.

These findings should be interpreted as before-and-after observations rather than controlled causal evidence. The observed improvements may reflect the combined effect of the PLM for CAE framework, concurrent organizational changes, increased management attention, and improved measurement capability after system deployment. Further research across additional organizations, small and medium-sized enterprises, and controlled comparison settings is needed to assess generalizability and isolate the effect of individual framework components.

Overall, the study suggests that simulation data governance can be strengthened when CAE Requests, models, HPC execution metadata, result artifacts, and approval workflows are managed as part of the enterprise PLM digital thread.