Electronics/Mechatronics Data Management in Railway Manufacturing: A Review of Product Lifecycle Management-based Strategies for Digital Continuity and Lifecycle Configuration Control

The railway manufacturing industry is undergoing rapid transformation driven by Industry 4.0 initiatives, the Industrial Internet of Things, increasing regulatory expectations [1], [2], [3], and rising customer demand for intelligent, efficient, and highly reliable transportation systems [4], [5]. Today’s railway vehicles are no longer just mechanical machines; rather, they are sophisticated, connected systems that combine mechanical components, electrical systems, embedded software and intelligent control networks [4], [5]. These vehicles are expected to operate for decades, all while improving energy efficiency, enhancing passenger experience and providing advanced monitoring and diagnostics capabilities that support safety and efficient operation.

This evolution introduces significant engineering and operational complexity. Railway manufacturers must manage multi-site production environments, extended supplier ecosystems, frequent engineering modifications, and long-term configuration traceability across the full lifecycle. Maintaining alignment between the as-designed, as-built, and as-maintained states of fleet assets is particularly challenging, yet essential for ensuring safety compliance, service continuity, and lifecycle cost control.

Modern rail products depend heavily on electronics and mechatronics subsystems, including traction and braking control, passenger access systems, HVAC automation, onboard diagnostics, condition monitoring, and increasing software-defined functionality. As a result, product development involves mechanical computer-aided design (MCAD), electrical and electronic design automation (ECAD), and embedded software development environments. These domains generate large volumes of tightly interdependent lifecycle artifacts such as PCB layouts, wiring harness definitions, firmware releases, calibration parameter sets, and verification evidence [6].

Traditional engineering systems often operate in silos, with limited integration between mechanical, electrical, and software applications. As a result, revision control, variant management, and change management remain a common weak point. In safety-critical railway programs, these gaps can lead to integration mismatches, incompatible hardware–software deployments, configuration drift across fleets, and expensive rework during commissioning or in service [7].

Product Lifecycle Management (PLM) systems have emerged as a foundational backbone for addressing these challenges. Beyond serving as a document repository, PLM increasingly functions as the Single Source of Truth (SSOT) for product definitions, controlled baselines, and lifecycle configuration governance [5], [6], [7], [8], [9]. Effective PLM implementations enable structured integration of MCAD, ECAD, and software workflows, providing a unified digital thread that connects engineering intent with manufacturing execution, supplier collaboration, certification evidence, and long-term fleet support. In electronics- and mechatronics-intensive manufacturing, PLM plays a critical role in governing multi-domain bills of materials, effectivity and variant rules, engineering change processes, and compliance requirements [9], [10], [11], [12], [13], [14], [15], [16], [17], [18]. These capabilities are particularly vital in railway manufacturing, where product families evolve over decades through upgrades, supplier challenges and component obsolescence.

This paper reviews how PLM can be used to manage electronics and mechatronics lifecycle data within railway product development. It synthesizes industry practices and reference integration architectures that support controlled change process, and alignment across mechanical, electrical, and embedded software domains.

To structure the analytical scope of this review, the following research questions guide the synthesis:

RQ1: What configuration and lifecycle governance challenges are specific to electronics- and mechatronics-intensive railway manufacturing?

RQ2: How do PLM-centered integration strategies address multi-domain data alignment, effectivity control, and hardware–software traceability across long asset lifecycles?

RQ3: What theoretical, methodological, and applied research gaps remain in achieving configuration-centric digital continuity under railway lifecycle constraints?

The main contributions of this paper are summarized as follows:

• Railway-specific lifecycle framing: This review focuses on electronic and mechatronics data governance challenges within long railway lifecycles, including fleet baselining, retrofits, and safety-critical configuration control [1], [2], [3].

• Cross-domain PLM integration synthesis: The paper evaluates PLM-centered approaches for integrating MCAD, ECAD, and embedded software workflows—Application Lifecycle Management (ALM)—into a unified digital continuity model [10], [12].

• Configuration and variant governance analysis: It highlights the role of PLM in managing multi-domain BOM synchronization, effectivity control, disciplined engineering change propagation, and hardware–software co-release baselines [1], [10], [18].

• Implementation pattern identification: Recurring integration archetypes and practical deployment strategies are compared, illustrating how railway manufacturers can advance toward robust digital thread maturity [6], [19].

• Interoperability gap assessment: The review identifies persistent limitations in semantic integration, lifecycle decision support, and closed-loop service feedback across distributed engineering and supplier networks [7], [20].

This study adopts a structured narrative review methodology to examine PLM-enabled practices for electronics- and mechatronics-intensive systems, with specific application to railway rolling stock and trackside equipment. The review is research-question driven and thematically synthesized. While not a full systematic review under Preferred Reporting Items for Systematic Reviews and Meta-Analyses (PRISMA), it follows the transparency and reporting principles outlined in PRISMA 2020 [9].

The methodological choice reflects the interdisciplinary nature of the topic, spanning PLM theory, digital thread architectures, safety governance standards, and multi-domain engineering integration. Structured review approaches of this type are consistent with prior lifecycle and digital twin literature [7], [8].

The scope is framed around lifecycle challenges characteristic of railway systems engineering: long operational service life, safety-critical electronics, stringent configuration control, hardware–software integration, and traceability across design, manufacturing, maintenance, and retrofit. Foundational PLM lifecycle theory [4] and digital twin conceptualizations [1], [5] provide the conceptual baseline for lifecycle continuity. Configuration management and functional safety standards [1], [2], [3] establish the governance context relevant to rail electronics and embedded systems.

A structured literature search was conducted using Scopus, Web of Science, IEEE Xplore, ACM Digital Library, and Google Scholar. Search strings combined lifecycle governance terms with multi-domain integration constructs, including PLM, digital thread, digital twin, electronics lifecycle management, mechatronics integration, MCAD–ECAD integration, configuration management, hardware–software traceability, and variant management.

Publications from 2010–2025 were prioritized to capture Industry 4.0 and emerging Industry 5.0 developments [4], [5], [21], [22]. Earlier foundational works were retained where conceptually significant [4], [5], [6], [7], [8], [23]. Standards and interoperability frameworks were deliberately included, including ISO 10007 (configuration management) [1], IEC 61508 and ISO 26262 (functional safety) [2], [3], STEP AP210 for electronic design data [10], and ECAD–MCAD collaboration standards (IDX) [12].

Forward and backward citation tracing was applied to high-relevance review articles [7], [8]. To reflect industrial practice in electronics-intensive manufacturing, practitioner documentation and platform descriptions from major PLM vendors were also examined [9], [18], [19].

Sources were included if they addressed (i) PLM architectures or lifecycle integration models [4], [5], [7]; (ii) configuration or safety governance in complex engineered systems [1], [2], [3]; (iii) ECAD–MCAD interoperability or structured electronic product data exchange [6], [10], [11], [12]; or (iv) enterprise PLM capabilities relevant to electronics-dominant industries [9], [10], [11], [12], [13], [14], [15], [16], [17], [18]. Cross-domain evidence from automotive, aerospace, and high-tech sectors was included where lifecycle complexity was analogous to railway systems.

Sources focused solely on component-level electronics design or vendor-specific procedural guidance were excluded. Grey literature was incorporated where it provided transferable architectural or governance insight [6], [10], [19], and is treated as implementation-oriented evidence.

Synthesis was thematic, structured around configuration governance, digital thread continuity, digital twin enablement, and multi-domain integration within long-lifecycle railway systems.

PLM is more than a document repository; in electronics and mechatronics manufacturing it functions as the system-of-record for product definition and the orchestration layer for cross-domain processes. PLM enables controlled, traceable digital thread connecting requirements, multi-disciplinary design [4], verification/validation, manufacturing planning, supplier collaboration, and in-service configuration management [7]. This role is particularly important in long-lifecycle industries such as railway manufacturing, where fleets evolve through engineering changes, supplier substitutions, retrofit programs, and service-driven updates over decades.

Electronics/mechatronics-intensive products require consistent alignment across mechanical structures (enclosures, mounting interfaces, thermal paths), electrical and electronic systems (schematics, Printed Circuit Board Assemblys (PCBAs), harnesses, connectors, sensors), embedded software and firmware (versions, parameters, calibration sets), verification artifacts (simulation results, test reports, trace matrices), and manufacturing and service definitions (Manufacturing Bill of Materials (MBOM), work instructions, test procedures, service BOM). Without PLM, these artifacts remain fragmented across disconnected toolchains and shared repositories, increasing the likelihood of mismatches between “as-designed,” “as-built,” and “as-maintained” configurations.

This review draws on three complementary analytical lenses to examine PLM’s role and effectiveness. First, systems engineering theory—and specifically the principles of interface management and configuration control as described in ISO 10007 [1] and SE standards—provides the conceptual basis for evaluating how PLM governs cross-domain product definitions. Second, lifecycle management theory frames PLM not merely as a repository but as an orchestration layer that must maintain coherent product identity across design, production, service, and end-of-life states [4]. Third, configuration management theory, the formal discipline of identifying, controlling, and auditing the functional and physical attributes of products [1]—provides the evaluative criteria against which integration strategies are assessed throughout this review. Together, these lenses allow us to move beyond descriptive accounts of PLM tool use toward an analytical interpretation of why certain practices succeed, fail, or remain contested in engineering management practice.

In complex products—such as electric vehicles, industrial robots, rail systems, and smart industrial equipment—engineering data is created and managed across multiple authoring domains:

• MCAD for mechanical structures, assemblies, packaging, and drawings;

• ECAD for schematics, PCB layout, harness definition, and connectivity [10];

• Embedded software/firmware for control logic, diagnostics, and communications;

• Simulation/analysis for thermal, structural, EMI/EMC, and control-system validation.

A recurring challenge is that each domain uses its own identifiers, versioning schemes, and release processes [8]. PLM addresses this by establishing master data governance and standardized objects such as part masters, document masters, baselines, revisions, configurations, and effectivity [1]. When implemented as a SSOT, PLM supports:

• Consistent identification: internal part numbers linked to manufacturer part numbers, approved vendor lists (AVL/AML), and compliance attributes [24].

• Controlled release baselines: formal “released” packages that lock the correct set of MCAD/ECAD/software artifacts for manufacturing and service [1].

• Change visibility: a change in a PCB, harness, enclosure, or firmware triggers workflow tasks and notifications to affected stakeholders [9].

In railway manufacturing, centralized governance becomes essential because the same subsystem may exist across multiple vehicle types and fleet configurations, and changes must be propagated with clear traceability to avoid deploying mismatched hardware/software combinations into service.

A digital thread is the traceable flow of data and decisions across the lifecycle—from requirements and concept through design, verification, manufacturing, commissioning, service, and end-of-life. For electronics/mechatronics, the thread must explicitly connect multi-domain configuration states. PLM provides this continuity by enabling:

• Cross-domain structure linkage: mapping ECAD artifacts (schematics, PCBAs, harnesses) into the same top-level product structure used by MCAD assemblies and Engineering Bill of Materials (EBOM) [10], [12].

• Hardware–software association: linking firmware/software versions, parameter sets, and cybersecurity updates to specific hardware configurations, revisions, and serial effectivity [20].

• Verification traceability: associating simulation and test results (e.g., thermal margin, vibration compliance, EMC results) with design revisions and released baselines [2].

• Manufacturing definition continuity: connecting released baselines to process plans, test procedures, and production documentation, so changes drive controlled updates downstream [9], [11].

A practical example of digital thread value is changing propagation: a motor-control board update in ECAD can trigger packaging and clearance checks in MCAD, a compatibility check against firmware versions, and an update to manufacturing test sequences, reducing late-stage integration failures as illustrated in Figure 1.

Rail Context: Rail assets undergo retrofit programs and in-service changes; PLM should therefore support configuration reconciliation so service teams can identify which vehicles contain which revisions and approved substitutions, ensuring coherent “as-designed/as-builts/as-maintained” mapping [1].

Regulated industries—including automotive, aerospace, rail, and medical devices—require evidence of compliance, controlled change, and traceable verification. For electronics/mechatronics, compliance is rarely limited to a single standard; it often spans safety (functional safety) [2], [3], cybersecurity, quality management, and documentation control.

PLM supports compliance by:

• Maintaining full revision history with approval status and role-based sign-off [1].

• Linking requirements to design, test, and evidence artifacts (requirements traceability) [2].

• Managing certification and audit packages (test reports, inspection results, approvals) [1].

• Tracking supplier and part compliance attributes (restricted substances, lifecycle status, certifications) [24].

For example, in a railway brake-control subsystem, PLM can provide an audit-ready package connecting safety requirements, design baselines, verification evidence, approval records, and released manufacturing/service configurations [2]. This capability is particularly valuable when changes are introduced after vehicles are deployed, as it supports impact analysis and controlled deployment into fleet service.

In electronics/mechatronics-intensive manufacturing, PLM’s primary contribution is not merely data storage, but the enforcement of structure, governance, and traceability across multi-domain artifacts [1], [4]. The remainder of this review synthesizes integration patterns and operational workflows that enable MCAD–ECAD–software continuity, and critically evaluates persistent gaps in semantic interoperability, effectivity management, supplier collaboration, and human-centric decision support [20], [23].

Electronics and mechatronics product realization depends on managing heterogeneous data objects created in different authoring environments while keeping them synchronized across lifecycle stages [6]. A robust PLM implementation must manage both content data (e.g., schematics, CAD, firmware) and context data (e.g., effectivity, approvals, compliance evidence, supplier qualification) [1]. This is especially important in long-lifecycle industries such as railway manufacturing, where product configurations evolve through engineering changes, supplier substitutions, retrofit programs, and service-driven updates. The principal data types, their descriptions, and typical source tools are summarized in Table 1.

PLM must support product structures representing how products are designed, built, and maintained. The EBOM reflects design intent, the MBOM reflects production sequencing, and the Service Bill of Materials (SBOM) supports spares and repair kits [4]. Electronics/mechatronics complexity increases because BOMs include PCB assemblies, harnesses, sensors, controllers, and software configurations alongside mechanical parts [10]. PLM must maintain traceable relationships between CAD assemblies, ECAD artifacts, harness connectivity, and firmware/hardware compatibility [6], [12]. In rail systems, effectivity may extend to serial number or retrofit campaigns, preventing failures such as mismatched harness variants, incorrect spares ordering, or firmware incompatibility [1].

Mechanical data includes 3D models, assemblies, drawings, packaging envelopes, and interface definitions. In mechatronic products, MCAD is tightly coupled to electronics through PCB placement, harness routing, connector access, thermal paths, and maintainability constraints. PLM manages MCAD datasets as revision-controlled objects linked to part definitions, interface requirements, and released baselines [9], [11]. Railway examples include electronics enclosures, inverter cabinet thermal designs, and sensor integration in bogies. PLM is essential for assessing mechanical impacts when ECAD changes occur, ensuring packaging conflicts are identified early [6].

ECAD data includes schematics, PCB layouts, netlists, stack-ups, PCBA definitions, component attributes, and manufacturing outputs [10]. ECAD changes frequently due to obsolescence, EMI/EMC refinements, DFM adjustments, and supplier-driven redesigns [24]. PLM must treat ECAD information as structured lifecycle objects—not file drops—linked to PCB revisions, qualified component definitions, compliance attributes, and production inspection requirements. Railway applications include brake-control boards, door controllers, diagnostic units, and power distribution modules. Without PLM governance, outdated PCB builds, unqualified alternates, or broken traceability between reference designators and component substitutions can occur [24].

Mechatronic systems are defined by both hardware and embedded software. Key objects include firmware binaries, release packages, bootloader versions, configuration files, calibration parameters, diagnostic definitions, and cybersecurity updates [20]. PLM must enable hardware–software traceability by linking software versions to specific controller variants and PCB revisions, and parameter sets to product variants and serial effectivity [1], [20]. In rail fleets settings such as braking behavior or traction limit often vary by baseline, so tight configuration control is required [2]. Without it, teams risk loading the wrong firmware or parameters—and losing visibility into exactly which software is running on each vehicle.

Manufacturing requires executable definitions: routing, work instructions, test procedures, tooling definitions, inspection plans, and as-built records. PLM must connect released engineering baselines to shop-floor processes, ensuring test scripts align with the correct firmware and hardware revision [9], [11]. It should also feed nonconformance and corrective actions back into design control. Rail examples include harness test procedures, commissioning checklists, and end-of-line validation tied to vehicle serial numbers. Failures arise when plants are built from obsolete revisions or test procedures lag engineering changes.

Configuration context defines what is valid for a given product variant, customer option set, plant, and serial/date range. PLM controls variant rules, effectivity, baselines, and engineering change workflows—Engineering Change Request (ECR) and Engineering Change Order (ECO) [1]. In railway fleets undergoing phased upgrades, effectivity ensures the right combination of hardware, harness variants, and software baselines is installed per vehicle. Poor control results in mixed fleet configurations, incorrect spares provisioning, and inability to reproduce as-built states [1].

Service and field data closes the lifecycle loop through failure reports, retrofit deployment records, service bulletins, maintenance histories, and as-maintained BOM updates. PLM should capture configuration drift, link field issues back to design baselines, manage retrofit kits as controlled objects, and improve spares strategies using operational feedback [7]. Railway examples include selective retrofits of control electronics and recurring sensor failures driving redesign. Without PLM integration, fleet differences become unknown, corrective actions are delayed, and lessons learned fail to improve product definitions.

Electronics and mechatronics data management is challenging not only due to the large volume of lifecycle artifacts, but also because these artifacts are tightly interdependent across mechanical, electrical, and software disciplines. Maintaining consistency across “as-designed,” “as-built,” and “as-maintained” states is essential, particularly in railway manufacturing, where long asset lifecycles, safety-critical requirements, distributed supply chains, and retrofit-driven evolution amplify complexity. The most persistent barriers occur across MCAD–ECAD–software toolchains and PLM-centered operating models.

MCAD and ECAD ecosystems were historically developed for different purposes, identifiers, and exchange formats. Even when connectors exist, integration often stops at file synchronization rather than preserving semantic relationships such as connectivity, pin mapping, interface constraints, and effectivity. This creates friction in electrical and mechanical designs. In rail applications, even a minor PCB outline or connector change can affect enclosure clearance, harness routing, maintainability access, and thermal performance. Without explicit interface modeling, conflicts often appear late during installation or commissioning, resulting in rework. Common failures include harness routing clashes, connector inconsistencies, uncontrolled “shadow BOMs,” and PCB revisions released without mechanical revalidation. Improved practice requires managed interface objects in PLM, defined MCAD–ECAD checkpoints, and validated integration strategies.

Electronics and mechatronics evolve through frequent revisions, parallel variants, supplier-driven substitutions, and embedded software updates. This creates revision proliferation, variant explosion, and the need for strict effectivity control by plant, serial range, build batch, or retrofit campaign. Hardware–software compatibility introduces a second axis of configuration management, where firmware versions and parameter sets must remain synchronized with specific board or controller revisions. Railway fleets often include multiple baselines for subsystems such as door or traction control units depending on build history. Without disciplined PLM configuration governance, organizations risk installing incorrect spares, deploying incompatible firmware, or maintaining inconsistent as-built records across sites

Electronics/mechatronics products must meet multiple regulatory and compliance requirements including safety, environmental standard, and cybersecurity. Changes after release require impact assessment, re-verification, and traceable evidence. For example, a component substitution can affect EMC or material compliance, while a software update may change system behavior. Strong practice requires controlled evidence packages, integrated requirements-to-test traceability, and compliance attributes embedded into part and supplier master data. In safety-critical railway subsystems, audit-ready traceability from requirements to baselines, verification evidence, approvals, and service bulletins are mandatory

Electronics supply chains face volatility from lead-time shifts, supplier changes, and component obsolescence. Long-lifecycle industries like rail frequently outlive component availability, forcing redesigns and retrofit strategies. PLM must support lifecycle intelligence integration, AML/AVL governance, qualified substitution workflows, and alignment between engineering definition and procurement execution. Without this, organizations encounter production stoppages, unqualified alternates, inconsistent part numbering across sites, and poorly controlled retrofit deployments

Railway manufacturing intensifies these challenges because fleets operate for decades and undergo phased upgrades, controlled substitutions, and software-driven modifications. Maintaining accurate baseline and effectivity management is essential to prevent configuration drift, incorrect spare usage, and service disruptions caused by mismatched mechanical–electrical interfaces or incompatible hardware–software combinations

The challenges synthesized in Section 5 have a direct bearing on the integration architecture decisions discussed here. Multi-domain data fragmentation and semantic interoperability limitations motivate the progression from file-based to connector-based strategies described in Section 6.1. Variant and effectivity management challenges are specifically addressed by the configuration governance patterns in Section 6.1.2 and Section 6.3. Hardware–software traceability gaps are the primary driver for PLM–ALM integration (Section 6.2). Supplier collaboration limitations are addressed through the ERP/MES integration and portal patterns in Section 6.3.

PLM integration for electronics/mechatronics is best understood as a layered problem, as depicted in Figure 2: authoring tool integration (MCAD/ECAD/ALM), product definition integration (multi-domain BOM and configuration control), and enterprise execution integration (ERP/MES/supplier/service). In review terms, successful implement-ations tend to follow repeatable patterns that balance interoperability, governance rigor, and deployment complexity. This section synthesizes practical integration strategies and their trade-offs, with emphasis on multi-variant, long-life-lifecycle contexts such as railway manufacturing.

MCAD–ECAD integration is foundational because it coordinates geometry-driven constraints (packaging, mounting, clearances) with connectivity-driven constraints (schematics, netlists, pinouts, harnessing) [6], [12]. Two dominant approaches are observed in industry.

File-based MCAD–ECAD collaboration exchanges design data through neutral formats such as IDF/IDX [12], [13], STEP AP210 [10], and PDF/3D viewable with redlines [25]. This approach is easier to adopt incrementally, works across mixed tool ecosystems and supplier networks, and supports lightweight packaging and clearance validation. However, it often lacks semantic traceability, carries risk of “file drift” from uncontrolled exchanges, and requires strong version discipline to prevent mismatched revisions [6]. Automation for change impact analysis and baseline synchronization remains limited. It best fits early-maturity organizations or supplier-driven integration needs.

Direct MCAD–ECAD integration uses PLM-managed connectors to synchronize structures, metadata, and baselines across mechanical and electrical domains [9], [10], [11]. It supports controlled check-in/out, interface object management (connectors, keep-outs), aligned multi-domain BOMs, and structured review workflows [19]. This approach enables a SSOT, automated change propagation, and stronger traceability between MCAD assemblies and ECAD artifacts [4], [23]. However, it requires higher setup effort, governance discipline, and consistent part master control [1]. It best suits high-complexity, long-lifecycle industries like rail with frequent changes.

A mature MCAD–ECAD–PLM workflow is less about following a fixed sequence and more about keeping teams aligned through controlled baselines and clear interface checkpoints [1], [4]. Typically, requirements and high-level architecture are first captured, including rail-specific safety, operational, and maintainability constraints [2]. Mechanical, electrical, and embedded software teams then proceed concurrently, developing and packaging solutions, schematics and harness connectivity, and firmware logic. PLM supports domain integration through synchronization of interfaces such as board outlines, connector accessibility, clearance zones, routing corridors, and serviceability constraints, thereby reducing late-stage “fit-and-route” rework [6]. Consolidation into a unified multi-domain BOM links mechanical assemblies, electronics structures, and firmware/parameter configurations. Subsequent engineering changes are governed through structured ECR/ECO workflows with impact analysis and enforced hardware–software compatibility [1], [20]. Finally, released baselines flow to manufacturing and suppliers via EBOM–MBOM synchronization, controlled work instructions, and aligned test procedures, ensuring consistent build and service configurations [11].

Selection between file-based MCAD–ECAD exchange and connector-based PLM synchronization should be guided by explicit criteria, including product complexity, variant frequency, harness and PCB change rates, and lifecycle demands such as long service life and retrofit management in rail [1]. Additional factors include regulatory traceability expectations [2], supplier manufacturing models, toolchain heterogeneity, and organizational maturity in governance and change discipline [4]. Review evidence supports a staged adoption path, beginning with controlled file exchange and progressing toward connector-based integration as numbering standards and baseline control stabilize [23]. Industry practice commonly follows file-based, connector-based, or hybrid phased strategies and the key trade-offs and best-fit scenarios for each are compared in Table 2.

The evolution of modern mechatronics has necessitated a shift from siloed data management to a unified digital thread [23]. As software becomes the primary determinant of product behavior, the traditional boundaries between PLM, ALM, and MES must dissolve to manage complex hardware-software dependencies effectively [20].

In the context of electronics-heavy products, the integration of PLM with ALM (e.g., Git-based repositories, CI/CD pipelines) is critical for configuration integrity [20]. While the ALM serves as the authoritative source for source code, the PLM system functions as the source of truth for the released configuration baseline and cross-domain compatibility rules [1], [2], [3], [4].

A mature PLM–ALM integration facilitates several core functions:

• Hardware/Software Co-release: Ensuring specific software binaries are validated and baselined against compatible hardware revisions (e.g., PCB variants or controller modules) [24].

• Multidimensional Traceability: Establishing a bidirectional link between requirements, source code commits, build artifacts, and verified test results within the released configuration [2], [23].

• Parameter and Calibration Management: Governing controlled parameter sets and firmware patches tied to specific product variants or serial effectivity [1].

To maintain scalability, industry leaders often adopt a reference-based metadata model, where PLM stores pointers to ALM artifacts rather than the binaries themselves, ensuring a high-fidelity audit trail without duplicating heavy data sets [20].

The bridge between PLM and ERP/MES converts engineering intent into executable manufacturing actions [4], [9]. This synchronization is vital for managing high-frequency changes and component substitutions typical in electronics manufacturing [24].

• BOM Transformation: The seamless translation of the EBOM into a MBOM, incorporating plant-specific routing and work instructions [11].

• Change-Driven Continuity: ECOs must trigger real-time updates across procurement, manufacturing test procedures, and quality inspection plans [1], [9].

• As-Built Reconciliation: Capturing real-time deviations and non-conformances on the shop floor and reconciling them back to the PLM to maintain an accurate As-Built record [1].

Railway manufacturing imposes unique demands on PLM due to long asset lifecycles, phased upgrades, and frequent supplier-driven changes [1]. Unlike short-lifecycle products, rail assets must preserve configuration continuity across engineering, production, service, and retrofit operations over their entire lifespan.

Effective PLM integration requires fleet-level baselining and precise effectivity management by serial number, batch, plant, or campaign. Released mechanical, electrical, and firmware data should be packaged as controlled baselines, consumed downstream based on effectivity rules rather than latest revisions, with deviations captured to maintain an accurate as-maintained record.

Harnessing and connectivity represent a major risk area due to regional variants, installation constraints, and supplier alternates. Harness definitions, pin tables, and connectors must be managed as controlled objects related to mechanical context, with explicit validation of routing, access, and pin compatibility [6], [12].

As embedded software becomes critical, PLM–ALM integration must support co-released commissioning packages that bundle compatible hardware, firmware, and parameter sets with full verification traceability [2], [20].

Given long lifecycles, supplier collaboration must address obsolescence through lifecycle intelligence, governed substitutions, and revision-controlled supplier packages. Finally, closed-loop integration of service data—failures, bulletins, and retrofit deployments—ensures fleet experience continuously improves engineering and service strategies.

Unlike short-lifecycle industries, railway manufacturing must sustain configuration integrity across fleets operating for decades under strict safety and regulatory constraints. Configuration governance should align with formal configuration management principles [1], functional safety frameworks [2], and railway-specific RAMS lifecycle standards such as EN 50126, EN 50128, and EN 50129 [26], [27], [28]. These standards emphasize controlled change, traceability, and long-term safety case continuity—requirements that directly shape PLM implementation in railway environments.

A railway-oriented common data model must integrate MCAD, ECAD, and software artifacts while preserving disciplined configuration control [1]. Because railway fleets operate for decades and maintain concurrent baselines, the model must support serial-number and campaign-based effectivity rather than simple “latest revision” logic.

Explicit linkage among PCB revisions, harness variants, firmware versions, and vehicle serial ranges prevents configuration drift and supports lifecycle traceability expectations under EN 50126 and EN 50129 [27], [28]. The goal is not only cross-domain alignment, but preservation of certified baselines over long operational lifetimes as represented in the common data model shown in Figure 3.

Railway engineering changes often apply to specific fleets, retrofit campaigns, or build batches. Change workflows must incorporate structured impact analysis consistent with configuration control standards [1] and safety reassessment principles under IEC 61508 and EN 50129 [2], [27].

Best practice includes:

• Cross-domain impact analysis (mechanical–electrical–software);

• Hardware–software compatibility validation;

• Explicit effectivity definition before release;

• Downstream synchronization with manufacturing and service.

Software changes must maintain traceability between requirements, code, and released baselines in line with EN 50128 expectations for railway control systems [26]. This fleet-aware governance prevents incompatible deployments and protects certified configurations.

Figure 4 illustrates a representative fleet-oriented mechatronics change workflow implementing these governance principles.

A railway digital thread must satisfy regulatory traceability requirements, not merely enable data visibility. Digital thread frameworks described in the study [29] and digital twin foundations articulated in the study [8], [23] emphasize lifecycle continuity across design, manufacturing, and service.

In railway contexts, each released baseline should trace:

• Safety and functional requirements;

• Verification and validation evidence;

• Approved hardware–software compatibility matrix;

• Deployment effectivity conditions.

Closed-loop feedback from service—failures, retrofit campaigns, and configuration deviations—must be reconciled into the system-of-record, consistent with digital twin lifecycle feedback models [5], [7]. This strengthens audit readiness and supports long-term fleet configuration governance.

Model-Based Systems Engineering supports structured system decomposition across functional, logical, and physical domains. In railway programs, these models must be configuration-controlled and aligned with lifecycle documentation expectations defined in EN 50126 [28].

Architectural modifications should automatically trigger downstream validation workflows, including:

• Mechanical interface revalidation;

• Harness and connectivity compatibility checks;

• Firmware dependency verification;

• Safety integrity reassessment per IEC 61508 [2] and EN 50128 [26].

This integration reduces integration defects while ensuring architectural changes do not compromise certified safety baselines.

Railway supply chains must manage long-term obsolescence, safety-qualified substitutions, and regulated documentation exchange. PLM collaboration frameworks grounded in configuration management principles [1] should ensure:

• Controlled supplier data packages;

• Managed substitutions with safety impact visibility;

• Fleet-level effectivity governance;

• Accurate as-maintained reconciliation.

Given multi-decade service lifecycles, extending configuration control into depot and service operations is essential to maintain compliance with EN 50129 safety documentation expectations [27] while enabling structured lifecycle feedback.

The integration challenges identified in Section 5 like, fragmented multi-domain data, semantic interoperability limitations, incomplete hardware–software traceability, and configuration drift across long-lived fleets—are not fully resolved by the current integration strategies described in Section 6. Emerging technologies, particularly digital twin architectures and AI-driven data intelligence, offer substantive pathways to address these residual gaps, though they introduce new governance and data quality requirements of their own. Rather than standalone solutions, they represent evolutionary layers built on disciplined configuration management [1] and digital thread foundations [29].

Current PLM practices are largely tool- and workflow-driven, lacking a unified theoretical model for representing mechanical geometry, electrical connectivity, and software behavior within a single configuration framework. Configuration management standards such as ISO 10007 [1] define control principles but do not resolve semantic integration across disciplines.

Future research should focus on:

• Unified configuration ontologies capable of representing structural, functional, and behavioral dependencies;

• Formal hardware–software compatibility models beyond revision-level matching;

• Fleet-level coexistence theory, where multiple certified baselines operate concurrently for decades under EN 50126 lifecycle constraints.

Without stronger theoretical foundations, interoperability efforts risk remaining platform-specific rather than domain-generalizable.

Digital twin models [1], [8] and digital thread architectures [29] emphasize lifecycle continuity, yet they typically assume stable baseline integrity. In railway systems governed by IEC 61508 and EN 50129 safety expectations, configurations evolve through phased retrofits, supplier substitutions, and service-driven updates.

Methodological research is needed to develop:

• Automated reconciliation techniques between as-designed, as-built, and as-maintained states;

• Scalable effectivity modeling across serial ranges and retrofit campaigns;

• Structured automation of safety evidence traceability aligned with EN 50126/50129 governance;

• Validation frameworks for AI-assisted change-impact analysis in safety-critical contexts.

A key trade-off emerges between automation efficiency and certification assurance: increased algorithmic support must remain auditable and human-accountable under safety regulations.

AI-driven PLM intelligence [20], [28] can predict obsolescence, detect compatibility risks, and forecast change propagation. However, these approaches expose systemic weaknesses in data quality, effectivity discipline, and baseline consistency.

Applied research should investigate:

• Data governance maturity models tailored to multi-decade railway fleets;

• Human-in-the-loop architectures for AI decision support in safety-regulated systems;

• Quantitative metrics for measuring configuration drift and semantic misalignment;

• Economic trade-offs between proactive retrofit strategies and reactive correction.

Absent robust governance, AI may amplify inconsistencies rather than mitigate them.

Section 8 identified theoretical, methodological, and applied research gaps in configuration-centric lifecycle governance. The implementation archetypes examined below serve as a contextual validation lens, illustrating how these gaps manifest differently across industries and under varying lifecycle constraints. Rather than functioning as independent case summaries, these archetypes provide empirical grounding for the boundary conditions and transferability limits discussed in the research agenda.

Each archetype has been evaluated through: (i) contextual drivers, (ii) critical success factors, (iii) boundary conditions, and (iv) railway-specific adaptation implications.

(1) Distinctive context

Railway manufacturing is characterized by multi-decade asset lifecycles, concurrent certified baselines, retrofit-driven evolution, and safety case continuity requirements under EN 50126 and EN 50129. Configuration governance principles align with ISO 10007 but operate at greater effectivity granularity (serial- and campaign-level) [14].

(2) Critical success factors

• Serial-level effectivity modeling;

• Co-baselined hardware–software commissioning packages;

• Strict reconciliation of as-designed, as-built, and as-maintained states.

(3) Boundary condition

This model succeeds only where organizational maturity supports disciplined baseline control. In immature environments, added process layers may increase overhead without reducing configuration drift.

(4) Transferability insight

Unlike industries optimized for rapid phase-out of prior revisions, railway requires coexistence management across fleets, fundamentally shifting PLM priorities from iteration speed to long-term governance resilience.

(1) Distinctive context

Automotive and EV sectors operate with shorter product lifecycles, high prototype velocity, and centralized production synchronization. Digital thread implementations emphasize concurrency and iteration compression [29].

(2) Success Factor

Connector-based ECAD–MCAD integration reduces late packaging conflicts because baseline turnover is rapid and obsolete configurations phase out quickly.

(3) Boundary limitation in railway

Railway fleets maintain certified baselines for decades. Changes require effectivity-specific deployment and may trigger safety reassessment under IEC 61508 and EN 50129 [2]. Therefore, time-to-market gains are secondary to compatibility longevity.

(4) Transferability implication

Railway adaptation should prioritize interface durability and traceability depth over iteration acceleration.

(1) Distinctive context

Industrial automation shares strong hardware–software coupling with railway systems. Digital twin and lifecycle feedback models [1], [8] enhance traceability and failure containment. However, installed bases are typically smaller and upgrade cycles more centralized.

(2) Success drivers

• Enforced compatibility rules;

• Controlled commissioning packages;

• Baseline-linked failure analytics.

(3) Boundary condition

In railway contexts, firmware changes may require structured safety impact analysis under EN 50128/50129, increasing governance complexity relative to industrial automation.

(4) Transferability implication

Conceptual co-release governance transfers well, but railway demands deeper effectivity granularity and certification traceability.

(1) Distinctive context

Medical and regulated consumer sectors emphasize auditability, supplier qualification, and documented trace-ability—aligned with configuration control principles [14] and formal lifecycle evidence management.

(2) Transferability rationale

• Baseline-linked compliance artifacts;

• Structured supplier governance;

• Lifecycle intelligence for substitutions.

(3) Boundary limitation

Compared to railway fleets, medical products typically exhibit shorter baseline coexistence windows and lower retrofit-driven structural evolution.

(4) Transferability implication

Compliance governance practices are highly applicable, but railways must scale them to serial-level fleet complexity and long-term certification continuity.

Cross-industry evidence suggests that PLM value correlates with baseline discipline, effectivity control, interface management, synchronized change propagation, and closed-loop lifecycle intelligence [4], [29]. However, outcome magnitude depends on lifecycle structure, as compared across industries in Table 3:

Digital twin models [1], [8] and digital thread frameworks [29] enhance lifecycle visibility across industries. Yet railway manufacturing uniquely combines long baseline coexistence with safety-governed modification cycles under EN 50126/50129. Consequently:

• Automotive gains primarily from iteration speed reduction.

• Railway gains primarily from configuration drift prevention and certification continuity.

This structural distinction explains why certain PLM approaches deliver rapid cycle-time improvements in automotive but generate value in railway through risk reduction and lifecycle stability.

Viewed collectively, these archetypes reinforce the central argument advanced in Section 8: that lifecycle structure—not tool sophistication alone—determines PLM effectiveness. Cross-industry evidence confirms that configuration discipline, effectivity modeling, and baseline governance consistently drive value; however, the magnitude and nature of benefits vary according to lifecycle duration, safety oversight intensity, and baseline coexistence requirements. Railway manufacturing represents the most governance-intensive boundary condition among the archetypes, thereby highlighting the need for formal semantic, methodological, and AI-governance advances outlined in the future research agenda.

Electronics and mechatronics have become central to modern railway products, coupling mechanical assemblies with electronics, harnessing, embedded software, and control logic across safety- and mission-critical subsystems. This review demonstrates that the dominant challenge is not the creation of domain artifacts in MCAD, ECAD, and software environments, but the governance of their interdependencies across the lifecycle—particularly multi-domain BOM synchronization, revision and variant/effectivity control, and alignment of “as-designed,” “as-built,” and “as-maintained” configurations over long service horizons. In this context, PLM functions as the backbone of digital continuity, enabling controlled baselining, structured change management, compliance traceability, and consistent downstream propagation into manufacturing and service.

Across the integration strategies synthesized, the strongest outcomes are associated with three recurring practices: (i) explicit management of cross-domain interfaces rather than file-only exchange; (ii) baseline-driven releases binding hardware revisions with compatible firmware and parameter sets; and (iii) effectivity-based applicability rules preventing configuration drift across production sites and fleet maintenance. Cross-industry evidence indicates that these practices reduce late-stage integration failures, shorten ECO cycles, and improve production and service readiness—effects that are particularly consequential in railway manufacturing due to retrofit programs, supplier substitutions, and multi-decade lifecycle support.

Despite these advances, persistent gaps remain in semantic interoperability, hardware–software compatibility governance, and systematic reconciliation of field feedback into authoritative configuration records. Emerging technologies, including digital twin architectures, AI-enabled lifecycle intelligence, and cloud-based PLM—offer promising extensions but also elevate requirements for cybersecurity, data governance, and auditability in safety-regulated environments.

For engineering leaders and program managers in railway and analogous long-lifecycle manufacturing sectors, the practical takeaways from this review can be organized around four decision areas:

• Investment prioritization: The strongest return on PLM investment is found not in deploying the most feature-rich platform, but in achieving governance discipline—clean part masters, consistent effectivity definitions, and structured change processes. Organizations with weak governance see limited benefit from advanced connector-based integration.

• Staged adoption: The evidence consistently supports a staged approach—beginning with controlled file-based exchange and baseline discipline, then advancing to connector-based synchronization as governance matures. Attempting full integration before governance foundations are stable and typically increases, rather than reduces, integration friction.

• Fleet and service configuration: Decision-makers in railway organizations should specifically prioritize ‘as-maintained’ configuration traceability. The long-term operational risk from configuration drift across fleets substantially exceeds the short-term cost of implementing effectivity discipline during initial PLM rollout.

• Cross-disciplinary governance: PLM integration is ultimately an organizational and process challenge as much as a technical one. Systems engineers should champion the definition of interface management agreements between MCAD, ECAD, and software teams as explicit governance artefacts, not informal conventions.