1 Introduction↩︎

1.1 Background↩︎

The global transition towards renewable energy has underscored the critical importance of wind power within the modern energy system. However, as existing wind turbine fleets age, the industry faces escalating operation and maintenance costs, necessitating robust reliability engineering and advanced maintenance optimisation strategies [1]. Foundational to these efforts is the analysis of historical failure data to calculate empirical failure rates and quantify downtime. Traditionally, these macro-level reliability studies rely on the frequency of work orders mapped to generic subsystems, as demonstrated in foundational offshore studies [2] and extensive onshore surveys [3]. While these analyses are highly valuable, they frequently exhibit high variance and inconsistencies across different fleets, primarily due to a lack of standardised data collection practices and varying operational taxonomies [4].

To move beyond generic failure rates and implement highly targeted, condition-based maintenance strategies, the industry standard relies on methodologies such as failure modes and effects analysis (FMEA) [5]. Despite its widespread adoption, this approach suffers from universally acknowledged weaknesses, most notably the qualitative nature of failure mode curation and scaling of risk parameters. Recognising these limitations, researchers have spent years developing complex workarounds to mathematically correct the inherent subjectivity of the method. These efforts range from the application of fuzzy logic to mitigate human bias [6], to the introduction of hybrid cost-weightings that capture true operational impacts [7], and the deployment of improved analytical models tailored for complex offshore architectures [8].

Ultimately, these analytical limitations cascade directly from how maintenance data is processed and labelled. Early digitisation efforts recognised the immense value locked within structureless work order text [9], leading to initial workflows aimed at standardising this information to compute reliability KPIs [10]. Consequently, traditional natural language processing (NLP) and machine learning (ML) text classifiers were deployed. While an improvement over manual expert labelling, these ML approaches require massive training datasets and often introduce algorithmic misclassifications that inherently skew downstream reliability calculations [11], [12]. Recently, large language models (LLMs) have initiated a paradigm shift in the sector, offering reasoning capabilities to recommend offshore wind turbine repair actions [13] and facilitating automatic labelling through dynamic schema integration [14].

Building upon this technological shift, our prior exploratory works demonstrated the feasibility of using LLMs for the deep semantic clustering of maintenance logs to extract empirical dictionaries [15], and established a comprehensive benchmarking tool to compare model performance on these highly specialised labelling tasks [16]. While these preliminary studies validated the conceptual approach and determined the optimal model architecture, the industry still lacks a fully automated, open-sourced pipeline deployed at a massive scale. The current study bridges this gap by moving beyond simple text classification to the autonomous extraction of evidence-based failure modes.

1.2 Problem statement↩︎

The overarching challenge in wind turbine reliability engineering manifests at both macro-analytical and micro-operational levels. On a macro scale, the majority of available reliability studies exhibit a significant limitation: they predominantly focus on high-level failure rates rather than detailed root-cause analyses. This constraint is not an omission by researchers, but is rather fundamentally dictated by the lack of granular, structured data necessary to perform such deep diagnostics.

Furthermore, established reliability methodologies, such as FMEA, suffer from inherent subjectivity and uncertainty. This subjectivity is not fundamentally a mathematical flaw, but rather a symptom of a profound data deficit. Because the empirical truth remains locked away in unstructured text, experts are forced to estimate occurrence rates and theorise failure mechanisms. Consequently, failure mode lists are curated based on individual experience, and the three constituent components of the risk priority number (RPN), severity, occurrence, and detection, are typically labelled manually using arbitrary numeric scales or subjective categorical descriptors. Despite previous efforts in the literature to introduce weighting functions to the RPN or to integrate cost factors, FMEA remains heavily reliant on qualitative expert judgement. For instance, advanced multi-criteria decision-making models are frequently required just to untangle the complex risk profiles of the pitch system [17].

These macro-scale analytical limitations cascade directly from micro-scale defects within the source data, specifically the maintenance records stored in computerised maintenance management systems (CMMS). As identified in the literature, systemic data quality issues, such as unstructured text, semantic ambiguity, and missing hierarchical codes, severely limit automated reliability analyses [18]. While state-of-the-art methodologies can derive high-confidence failure rates by fusing supervisory control and data acquisition (SCADA) readings and alarms with maintenance logs [19], these sophisticated models remain severely bottlenecked by the manual effort required to decipher and categorise unstructured text. A detailed review of legacy CMMS records reveals several systemic issues that prevent automated analysis:

1. Missing or incorrect system codes: Maintenance records frequently contain incorrectly assigned or entirely missing hierarchical system code entries.

2. Taxonomy hierarchy: System codes are often assigned at the highest hierarchical level of the applied taxonomy. For example, a fault may be categorised simply as a power converter issue while the specific failed subsystem remains hidden within the free-text description. This issue stems from both inconsistent data entry practices and inherent limitations within standard taxonomies. For instance, the Reference Designation System for Power Plants (RDS-PP) [20], [21], normally utilised in the industry, classifies the pitch system under the rotor blade hierarchy, which frequently leads to mislabelling in practice.

3. Unstructured free-text descriptors: There is a heavy reliance on unstructured free-text fields for technicians to record observations, iterative repair histories, and failure codes. These fields are highly susceptible to typographical errors, non-standardised formatting, and arbitrary abbreviations.

4. Misleading maintenance type labels: Maintenance type labels are often inaccurately assigned, actively diverging from the reality described in the text left by technicians.

5. Generic maintenance action labels: Labels specifying the action taken are frequently inaccurate or missing. When present, these labels are universally generic, such as logging a repair without specifying the exact component or the nature of the intervention.

Table 1 illustrates a sample of legacy CMMS maintenance records, demonstrating the unstructured nature of the textual descriptors and the prevalence of missing or generic categorical labels.

4pt

Ultimately, the fundamental problem addressed in this paper is the critical loss of valuable reliability intelligence. High-fidelity operational data remains trapped within unstructured maintenance logs, rendering it inaccessible to traditional quantitative reliability models and automated processing pipelines.

1.3 Research objectives and scope↩︎

To bridge the gap between unstructured observations from wind turbine technicians and the rigorous data requirements of advanced reliability engineering, this study poses the following research question:
Can we leverage the semantic capabilities of LLMs to automate data labelling, extract common failure modes, and structure maintenance records?

The novelty of this study lies in transitioning LLM application from rudimentary text classification to deep semantic reasoning within a highly specialised engineering domain. Specifically, it introduces a system-aware, dynamically prompted pipeline that not only corrects inaccurate legacy labels but also autonomously extracts evidence-based maintenance taxonomies with granular failure mode components directly from unstructured historical data, providing a scalable solution to a pervasive bottleneck in the field.

It is imperative to clarify the precise boundaries of this research. While the methodologies developed herein directly enable subsequent quantitative reliability studies and evidence-based FMEA, executing a comprehensive reliability assessment falls outside the current scope and is reserved for planned future work. Although the results section presents adjusted failure rate profiles and frequently occurring failure modes, these metrics are provided strictly to showcase the advanced analytical capabilities unlocked by the newly structured dataset. The core evaluation of this paper remains squarely focused on assessing the potential of LLMs in executing these complex data-structuring tasks.

2 Methodology↩︎

2.1 Data description↩︎

The empirical foundation of this study is built upon a dataset of maintenance logs collected from a diverse fleet of wind turbines. To ensure the robustness and generalisability of the proposed methodology, the data encompasses 32 distinct onshore wind farms comprising a total of 280 individual turbines. The fleet represents a highly diverse operational environment, utilising 12 different wind turbine models distributed across varying population densities, with power capacities ranging broadly from 0.66 MW to 3.2 MW.

The raw dataset consists of 16,316 maintenance logs. Of these, 15,009 logs directly pertain to wind turbine maintenance, while the remaining 1,307 logs document interventions on the balance of plant infrastructure. The observation period spans more than nine years, capturing data between 2017 and 2026. Cumulatively, this represents over 22 million operational hours, providing a rich, highly representative sample of the patterns in maintenance data from modern wind energy assets.

2.2 Clarifications on used terminology↩︎

Given the multidisciplinary intersection of reliability engineering and artificial intelligence (AI) within this study, a precise operational vocabulary is essential.

All maintenance data originates from a CMMS, specifically IBM Maximo [22]. Within this platform, it is necessary to distinguish between two closely related terms: work orders authorise specific interventions, while the maintenance logs analysed herein represent the chronological, textual records of executed tasks and field observations for a given asset.

For data filtering and labelling purposes, a failure event is defined as any corrective intervention addressing an actual or predicted functional failure. This encompasses physical hardware repairs, system resets required to restore operation, and corrective actions stemming from inspection findings. To isolate these events, an initial extraction filtered out routine preventive maintenance.

To categorise these events by wind turbine systems, the RDS-PP taxonomy is employed in the legacy dataset [20], [21]. This taxonomy utilises system codes to classify the hierarchical level of an intervention, ranging from major functional blocks (systems) to smaller operational sections (subsystems). Crucially, individual components or parts frequently fall below standard RDS-PP granularity and must therefore be dynamically extracted from the unstructured text.

Additional data science and generative artificial intelligence terminology (e.g., hallucinations, human-in-the-loop workflows [23]) is formally defined in the glossary.

2.3 Data processing and automated labelling pipeline↩︎

To systematically resolve the macro and micro-scale data defects previously identified, a sequential, multi-phase data processing and automated labelling pipeline was developed. This workflow transitions the unstructured CMMS records into a highly structured, machine-readable dataset suitable for advanced reliability analytics.

2.3.1 Database integration and pre-processing↩︎

Traditional analytical workflows within the wind industry commonly query only the primary WORKORDER table from CMMS data, which inherently limits the available context to the most recent update. To capture the full chronological evolution of iterative maintenance tasks, this methodology integrates the WORKORDER table with historical observations stored in the WORKLOG table. Furthermore, descriptive failure dictionaries extracted from the FAILURECODE table were merged to clarify the often obscure fault codes logged by technicians. This integration generated a unified, comprehensive description column for each unique work order identifier. The consolidated dataset was then subjected to a robust text-cleaning process using regular expressions to remove syntactic noise, inconsistencies, formatting artefacts, and commercially sensitive asset identifiers.

2.3.2 Taxonomy alignment and system code corrections↩︎

The accuracy of any component-level reliability analysis depends on a robust system taxonomy. The standard RDS-PP, originally adapted for wind turbines during the Reliawind project [20], [21], was utilised as the baseline. However, because this legacy taxonomy has not been comprehensively updated, slight but necessary structural improvements were implemented. Most notably, the RDS-PP traditionally nests the pitch system under the rotor blade hierarchy, a classification that frequently causes inaccurate system code labelling in practice. To correct the dataset, the LLM was deployed through a three-step auditing sequence:

1. Targeted Pitch System Correction: Textual patterns indicative of pitch system interventions were detected within the merged descriptors, and the associated logs were relabelled using the updated, isolated pitch taxonomy.

2. Missing Code Recovery: A similar semantic logic was applied to recover and assign system codes to logs where the hierarchical classification was left entirely blank by the technicians.

3. Comprehensive Discrepancy Audit: The model evaluated the remaining logs to detect clear semantic discrepancies between the currently assigned system code and the written descriptors, dynamically relabelling those that failed the audit.

2.3.3 Semantic extraction of empirical taxonomies↩︎

With the system codes standardised, the workflow progressed to a critical semantic analysis phase. The logs were batched by their corrected system codes. Where applicable, these batches were further subdivided based on specific component topologies, acknowledging that different hardware designs, such as electromechanical versus hydraulic yaw brakes, exhibit fundamentally different fault mechanisms. The LLM processed these batches to extract common intervention patterns, constructing evidence-based taxonomies for both the specific maintenance actions and the failure modes that occurred within each subsystem. In this context, the failure mode dictionaries comprise a failure mode name, dominant mechanism, observed symptom, and candidate or inferred cause. The mechanism and cause fields should therefore be interpreted as evidence-supported descriptors derived from aggregated subsystem or topology semantics, rather than as forensic proof of a unique root cause in every individual maintenance log.

2.3.4 Granular labelling↩︎

In the final phase, the LLM processed each log individually to apply the newly derived semantic taxonomies. First, the maintenance type and action were evaluated. Although the raw dataset was initially filtered to include only corrective and predictive events, observed discrepancies between legacy labels and actual work performed necessitated a complete relabelling using a universally adopted taxonomy (corrective, reset, preventive, predictive, inspection, retrofit). The specific action taken was assigned from the empirical taxonomy generated in the previous step. Following this, each individual log description was first and foremost matched to the most specific failure mode name supported by its text. The associated mechanism, symptom, and candidate-cause fields were then populated from the wider empirical dictionary, meaning that sparse logs inherit the dominant subsystem-level interpretation rather than an independently proven causal diagnosis.

2.4 Design considerations and decisions↩︎

The robustness of the automated labelling pipeline relies upon several critical architectural and domain-specific design choices, implemented to ensure high fidelity, mitigate AI hallucinations, and optimise computational efficiency.

2.4.1 Model configuration and processing architecture↩︎

The pipeline’s foundation utilises the GPT-5.4 Thinking model [24], available at the time of conducting this study. The model is accessed via the OpenAI application programming interface (API) in Python [25]. However, the underlying architecture remains fundamentally model-agnostic, ensuring seamless substitution with future LLMs. This specific model was selected due to institutional API availability, state-of-the-art capability assessments, and prior evaluations using the previously developed LLM benchmarking framework [16]. To balance analytical depth with computational cost, distinct reasoning efforts were applied: a medium effort for log-by-log labelling and a high effort for the complex semantic clustering of system batches.

To prevent context contamination, an isolated log-by-log processing approach was strictly enforced in labelling tasks, providing the model with a clean memory state for each iteration. The inherent time penalties of this sequential processing were mitigated by deploying asynchronous API requests. Easily scalable concurrency limits were established at 10 simultaneous requests for individual logs and 5 for system batches in semantic extraction tasks.

2.4.2 Dynamic prompting and data schema validation↩︎

One of the primary strengths of this methodology is the implementation of dynamically adjusting, system code-specific prompts. The pipeline programmatically filters the prompt content based on the assigned system code and its specific topology, rather than exposing the model to an exhaustive, static list of the entire wind turbine taxonomy. This targeted exposure significantly reduces the model’s cognitive load and the probability of misclassifications.

Furthermore, rigorous data schema validation guaranteed the programmatic utility of the output. Every response was parsed against a strict data schema, and any errors or content deviations automatically triggered a prompt re-run to ensure seamless dataset integration.

2.4.3 Reasoning and evidence-based labelling↩︎

To further suppress LLM hallucinations, a Chain-of-Thought (CoT) framework was embedded into the system prompts [26]. The model was required to generate a concise, one-sentence rationale prior to label selection, output a self-assigned confidence score, and flag ambiguous entries for human review.

Crucially, this deductive reasoning is firmly grounded in evidence-based taxonomies derived directly from the empirical semantic analysis of historical log batches. These taxonomies actively account for subsystem topologies, utilising separate action and failure dictionaries to reflect the distinct fault natures of different component architectures, such as geared versus direct-drive drivetrains, or electromechanical versus hydraulic yaw brakes. By formulating the dominant mechanisms, observed symptoms, and candidate causes based on aggregated historical evidence, the pipeline empowers the model to apply consistent contextual labels when processing sparse individual logs while retaining the distinction between observed evidence and inferred causal interpretation.

2.4.4 Deterministic safeguards and escape categories↩︎

The LLM-driven processes were augmented with a layer of strict deterministic rules to save computational resources and further reduce the chance of errors. Labels that could be logically inferred between pipeline steps were assigned programmatically. For example, if the maintenance type and action taken definitively indicated a planned inspection or retrofit, the pipeline deterministically flagged the failure mode fields as "Not applicable", confirming the absence of a functional failure. To handle inherently poor source data, specific escape categories were integrated into the taxonomies, such as "Not enough information" for uninformative descriptors and "Other" for valid information falling outside the used taxonomy.

2.4.5 Randomised sample validation↩︎

To empirically validate the efficacy of these safeguards and quantify the residual risk of model hallucination, a verification process was integrated into the methodology. While resource constraints inherently limited manual review of the entire processed dataset, a randomised sample of 300 logs was extracted for expert evaluation. The manual review confirmed a high degree of agreement between the LLM-generated labels and expert judgement. This targeted validation was used to verify the accuracy with further reliance on the model’s self-assessed confidence metric as a robust threshold for deterministic data inclusion.

2.4.6 Randomised sample validation↩︎

To empirically validate the efficacy of these safeguards and quantify the residual risk of model hallucination, a verification process was integrated into the methodology. While resource constraints inherently limited manual review of the entire processed dataset, a randomised sample of 300 logs was extracted for expert evaluation. The manual review reported an agreement rate of 80% to 90% between the LLM-generated outputs and expert opinion. This range of agreement applies for both, the accepted labels with a high self-assigned confidence score, and the outputs assigned a lower confidence score with a human review flag, which successfully identified genuinely uninformative logs. This confirms the model’s accuracy across its varying confidence tiers, justifying further reliance on its self-assessed confidence metric as a robust threshold for deterministic data inclusion.

Considering these comprehensive design decisions, the pipeline presented in this study is highly recommended for large-scale data processing and integration into applied reliability studies. It represents a significant architectural evolution from our previously developed framework [16], transitioning from the strict comparative evaluation of LLM performance to the high-throughput, topologically aware standardisation of industrial maintenance data.

2.5 Data input and output structure↩︎

To operationalise the previously detailed design considerations, strict data schemas were defined for each distinct stage of the automated pipeline. Table 2 outlines the specific input parameters, requested outputs, and evaluation metrics associated with each task type.

4pt

Several of these parameters require explicit clarification within the context of this study:

• Merged log description: The primary input for all tasks. This consists of the aggregated records of conducted maintenance written by technicians, often encompassing chronological iterations of a single fault investigation and repair.

• Topology: Provided conditionally when applicable, this parameter informs the model of specific hardware configurations that inherently alter the expected fault profile. This includes the generator type (which concurrently affects the converter), the drivetrain type (distinguishing between geared and direct-drive configurations), the pitch system architecture (electrical or hydraulic), and the yaw brake mechanism (electromechanical, hydraulic calipers, or friction brakes).

• Failure mode profile: A structured label comprising the failure mode name, dominant mechanism, observed symptom, and candidate cause. The symptom field is closest to the directly reported technician observation, whereas the mechanism and cause fields may represent inference from the subsystem- or topology-specific empirical dictionary.

• Relabelling flag: A binary indicator specifically utilised during the system code audit phase. It signals a clear semantic discrepancy between the currently assigned system code and the merged log description, prompting a full relabelling pass.

• Reasoning: As part of the CoT prompting framework [26], the model is required to generate a one-sentence rationale. Crucially, this reasoning is generated prior to the label itself, serving as a deductive process rather than a post-hoc justification of an arbitrary choice.

• Confidence level: A self-assigned qualitative metric (categorised as High, Medium, or Low) indicating the model’s certainty regarding its generated output.

• Human review flag: A binary label used to isolate ambiguous or highly complex logs that require expert validation. This flag is predominantly triggered when the model assigns a Low confidence level.

3 Results↩︎

3.1 Labelling results↩︎

Before detailing the statistical success rates of the automated pipeline across the entire fleet, it is essential to examine the tangible transformation of individual maintenance records. To illustrate this qualitative improvement, Table 3 presents the post-processing output for the same two legacy maintenance records previously introduced in Table 1 as a part of the problem statement.

4pt

A comparative analysis of these logs demonstrates the pipeline’s capacity to resolve both categorical noise and semantic ambiguity. In the first example, the legacy data contained an incorrectly assigned hydraulic systems code and entirely omitted the maintenance action. The LLM successfully corrected the system code to drive train brake based on the contextual text and restored the missing action as a replacement of brake pads. Furthermore, the model synthesised the unstructured text into a highly granular failure mode profile, assigning the dominant degradation mechanism (friction material wear) and a candidate cause (repeated braking duty and temperature exposure) based on the wider log batch from this system.

The second example highlights the pipeline’s ability to recover missing data and rectify fundamental misclassification issues. The legacy record lacked a system code entirely and generically classified the intervention as a corrective repair. The automated process successfully inferred the missing system code, assigning it to the gearbox lubrication system, and extracted a highly specific action label: removal of corrosion from cooler-to-gearbox tubing. Crucially, by semantically parsing the description of a visual inspection and subsequent corrosion removal, the model correctly reclassified the maintenance type from corrective to inspection. The unstructured text was then distilled into a structured diagnostic format, capturing the observed corrosion symptom, dominant surface corrosion mechanism, and candidate environmental cause.

These individual transformations exemplify the core value proposition of the methodology. By systematically applying this deep semantic extraction across thousands of records, the framework transitions the dataset from a state of unstructured operational logging to a structured format suitable for advanced reliability analytics. The quantitative success rates of this scaled process are detailed in the following subsections.

3.1.1 System code corrections↩︎

The primary objective of this part of the workflow was to audit, correct, and recover missing system code labels critical for reliability analysis. A relabelling attempt was only deemed successful if the LLM generated an output with a self-assigned high confidence score and explicitly omitted the human review flag. Consequently, the success rates presented in this section simultaneously represent the distribution of high-confidence outputs suitable for integration into reliability analytics.

Figure 1 illustrates the proportional success rates and global dataset impact of the LLM-driven system code corrections across three targeted tasks: restoring empty logs, extracting the pitch system taxonomy, and executing post-audit corrections.

Cumulatively, the pipeline processed 2,984 logs exhibiting hierarchical defects. Of these, 2,178 logs were successfully relabelled with high confidence, representing an overall success rate of 73.0%. This automated recovery effort successfully corrected 13.35% of the entire dataset, a substantial volume of data that would otherwise have been either excluded from quantitative reliability modelling or lead to inaccuracies in the results.

The performance varied significantly depending on the specific nature of the data defect being addressed. The targeted extraction of the pitch system taxonomy achieved the highest success rate at 99.1% (1,095 out of 1,105 logs). This exceptionally high yield is attributed to the algorithmic pre-screening, which detected explicit semantic mentions of pitch components in the text before prompting the model. This correction represents a major improvement to the dataset’s analytical value, as legacy data structures typically lacked an isolated pitch system code, frequently mistaking these critical faults under the broader system codes, mainly rotor blades and rotor hub.

Similarly, the post-audit corrections demonstrated a high success rate of 93.5% (587 out of 628 logs). This robust performance was expected, as the preceding audit phase inherently isolated logs whose textual descriptions were already informative enough to reveal a direct semantic discrepancy with their legacy system codes.

Conversely, the task of restoring logs that completely lacked a system code exhibited the lowest success rate at 39.6% (496 out of 1,251 logs). This lower rate highlights a systemic data entry deficiency: maintenance records lacking basic categorical metadata at the time of creation generally correlate with severely uninformative or entirely empty text descriptions. Despite this limitation, recovering nearly 40% of these previously unclassified records provides a significant influx of usable data (3.04% of the entire dataset) that would have otherwise been discarded.

Overall, the application of dynamically prompted LLMs to resolve micro-scale system code defects yielded a demonstrable reduction in categorical noise. This foundational improvement to the dataset’s quality directly enables more precise component-level analytics, the downstream effects of which will be visualised in the subsequent analysis of shifted failure rate profiles.

To visualise the categorical shifts resulting from the successful automated pipeline, a Sankey flow diagram is presented in Figure 2. This chart illustrates the complex reallocation of maintenance logs from their original, often inaccurate or missing legacy classifications, to their corrected hierarchical designations within the updated taxonomy.

A prominent finding from this visualisation is the profound misclassification of pitch system maintenance within the legacy dataset. Historically, interventions on the pitch system were systematically recorded under broader or adjacent categories, predominantly rotor blades, rotor hub, and general hydraulic systems. By applying the targeted pitch taxonomy, the pipeline not only corrected these broad misclassifications but also introduced a significantly higher degree of granularity. The dataset now clearly distinguishes interventions across specific pitch subsystems, successfully isolating faults within the emergency power supply and batteries, controllers, and hydraulic oil tanks. While a subset of logs remains classified under the general pitch system code, this only occurs when the original textual description lacked the specificity required to deduce the exact subsystem.

The recovery of entirely missing system codes reveals a distinctly different pattern of data omission. Logs lacking any initial classification were most frequently resolved into the low voltage electrical distribution, turbine tower, and turbine foundation system codes. This was accompanied by a highly diverse tail of smaller subsystem interventions, which have been grouped within the "Other Restored" group of labels. This distribution suggests that technicians may habitually bypass categorical data entry when performing maintenance on structural, foundational, or low-voltage electrical components, perhaps viewing them as peripheral to the core electro-mechanical drivetrain.

Finally, the logs that failed the initial semantic audit and underwent subsequent post-audit corrections exhibited no singular dominant pattern on the legacy side. This wide distribution reflects the inherently random nature of human error during the manual CMMS data-entry process. However, it is highly noteworthy that even within these random discrepancies, the largest proportion of the corrected logs was ultimately redirected to the pitch system. This reinforces the observation that accurately capturing pitch-related faults using standard, unoptimised taxonomy structures remains a pervasive challenge for maintenance personnel.

3.1.2 Maintenance type corrections↩︎

Beyond standardising the hierarchical system codes, refining the categorical maintenance type labels is essential for accurate reliability modelling. The automated pipeline successfully deduced a definitive maintenance type for 14,251 logs, representing 87.34% of the total dataset, based on the rigorous criteria of high model confidence and the absence of human review flags. Within this successfully processed subset, the LLM corrected the maintenance type for 3,997 logs, revealing that nearly a quarter of the entire global dataset (24.50%) had been misclassified. To illustrate the specific categorical shifts, a Sankey flow diagram is presented in Figure 3. It is important to note that this visualisation strictly displays only the 24.50% of the dataset that underwent a label correction, omitting the logs where the legacy label was deemed accurate.

A critical observation from the legacy data is its dominance by the corrective maintenance, with predictive interventions representing a significantly smaller secondary category. However, the results revealed that the reporting practice masked a highly diverse reality of operational interventions.

The most substantial correction was the reallocation of logs initially marked as corrective maintenance to the preventive category. This correction is profoundly important for downstream reliability analytics. In rigorous reliability modelling, it is paramount to isolate unexpected functional failures that occur during active operation from scheduled maintenance activities. Even if a preventive intervention involves the physical repair or replacement of a component, executing this action on a scheduled basis prior to a functional breakdown should not be statistically treated as an unexpected failure. Leaving these logs classified as corrective actions would artificially inflate the perceived failure rates of the affected subsystems.

The second largest reallocation from the legacy corrective category was to inspections. As will be detailed in the subsequent failure mode analysis, while routine inspections can certainly uncover latent defects that necessitate immediate correction, the primary nature of the logged intervention was exploratory rather than a direct response to an operational stoppage.

Furthermore, the semantic analysis isolated a significant volume of resets that had been previously masked under the corrective maintenance. Distinguishing between a soft reset, such as clearing a software fault or restarting a control loop, and a hard corrective intervention, such as replacing a mechanical component, is vital for understanding true downtime drivers and resource allocation.

Finally, the reallocation patterns involving the predictive maintenance type highlight further inconsistencies in legacy data entry. A large proportion of maintenance initially marked as predictive was corrected to routine inspections. Conversely, the fourth largest flow originating from the legacy pool of corrective maintenance was reclassified as predictive, representing interventions that were genuinely driven by condition monitoring or failure forecasting algorithms but were historically logged as standard unexpected repairs.

3.1.3 Actions taken relabelling↩︎

Beyond standardising the maintenance type, capturing the precise nature of the physical intervention is critical for component-level reliability analysis. The automated pipeline successfully deduced a definitive maintenance action for 13,179 logs, representing 80.77% of the total dataset, based on the established criteria of high model confidence and the absence of manual review flags.

Within this successfully processed subset, the core maintenance action type, categorised by its primary active verb, was corrected for 8,611 logs (52.78% of the dataset). Furthermore, unlike the maintenance type field which was generally populated in the legacy data, the action taken field was frequently left entirely blank. The pipeline successfully inferred and restored specific action labels for 1,350 previously empty logs, recovering critical instructional information for 8.27% of the global dataset.

To visualise the macroscopic shifts in how these interventions are categorised, Figure 4 presents a Sankey flow diagram mapping the legacy action labels to their corrected counterparts. To maintain visual clarity, the newly generated labels are clustered solely by their active verb, with exceptionally low-count clusters grouped into "Other Actions".

As anticipated for a dataset initially filtered for corrective and predictive events, interventions involving repairs and replacements remain the dominant categories. However, the semantic extraction process introduced a significantly higher degree of descriptive granularity and a much broader diversity of specific active verbs, which will be visually detailed in the subsequent semantic analysis section.

The most profound categorical shift observed in this phase is the massive reallocation of logs from the repairs to replacements. In the legacy dataset, generic repairs outnumbered replacements by a factor of more than ten to one. Following the relabelling process, this ratio inverted entirely, with replacements now outnumbering repairs by more than three to one.

This dramatic inversion represents more than the correction of simple inaccuracies; it highlights a fundamental divergence in categorical data definitions. In historical data entry, technicians frequently logged the physical replacement of a subcomponent (such as swapping a bearing or an insulated-gate bipolar transistor) as a general repair to the parent system (the generator or the power converter). For the purposes of advanced reliability engineering, however, defining a replacement as the physical exchange of any specific part is often strictly necessary to accurately track parts consumption, inventory logistics, and granular component lifespans.

From a purely operational perspective, neither definitional approach is inherently incorrect, as the optimal taxonomy depends entirely on the objectives of the subsequent analysis. The primary advantage of the proposed LLM-based methodology is its inherent flexibility. It empowers reliability engineers to establish a specific, goal-oriented definitional framework and autonomously standardise years of highly variable historical logs to precisely match that newly desired schema.

3.1.4 Failure modes extraction↩︎

The final and most analytically complex phase of the automated pipeline was the semantic extraction of subsystem-specific failure modes. This stage evaluated the contents of each log to populate the four core pillars of a reliability event: the failure mode name, the dominant physical mechanism, the observed symptoms, and the candidate or inferred cause. Figure 5 presents an overview of the extraction success rates across the entire processed dataset.

The LLM successfully assigned a comprehensive failure mode profile for 11,662 logs, representing 71.5% of the total dataset. This constitutes a massive influx of highly granular, structured reliability intelligence that was previously inaccessible to standard quantitative models. By leveraging the empirical dictionaries generated in earlier phases, the pipeline successfully standardised the highly variable text entries into uniform diagnostic categories.

Furthermore, a subset of 1,213 logs (7.4% of the dataset) was deterministically classified as non-failures. Rather than representing a model failure, this is a direct application of the adopted deterministic logical rules. When the preceding stages confidently identified the maintenance type and action taken as routine, preventive, or non-corrective (for example, a scheduled inspection or a retrofit), the pipeline accurately flagged a functional failure mode as not applicable, effectively isolating these non-failure events from future failure rate calculations.

The remaining 3,441 logs, constituting 21.1% of the dataset, were categorised under non-informative. This category predominantly captures legacy records where the original textual descriptions were either completely empty or lacked the necessary diagnostic detail for the model to confidently infer a specific failure mode. While a part of this category accounts for instances where the model failed to generate a high-confidence output, it also reflects the inherent limitations of the source data.

Ultimately, while successfully structuring over 70% of the historical data into an advanced reliability format is a substantial achievement, the 21.1% information deficit starkly highlights the persistent operational consequences of poor data entry practices in the field.

3.2 Project economics↩︎

Transitioning automated NLP from traditional ML to LLMs introduces new operational variables, specifically financial costs associated with API usage and different computational runtime constraints. Evaluating these economics is essential for assessing the viability of scaling this methodology to larger industrial fleets. The key metrics are shown in Figure 6 with a detailed breakdown in the respective subsection.

3.2.1 Cost, runtime, and processing throughput↩︎

All financial metrics are calculated in US dollars, reflecting the direct API pricing model at the time of execution. Including preliminary testing and iterative prompt refinement, the total cost of executing the complete pipeline adds up to nearly $370. When normalised across the successfully processed dataset, this translates to an average cost of $0.0226 per log, providing a highly accessible baseline estimate for operators.

The total processing runtime adds up to nearly 7 hours. This duration was dictated by the model’s inherent generation speed and strict asynchronous concurrency limits (10 simultaneous requests for standard labelling tasks and 5 for heavy semantic analysis).

The global average throughput across the entire project was 0.67 items per second, though this varied significantly depending on task complexity. An item in this context refers to a fully processed input, which may be an individual log or a batched subset, and its corresponding generated output. The initial system code corrections proved to be the most efficient process, facilitated by a highly constrained taxonomy size and straightforward semantic matching. Conversely, the semantic clustering required to build empirical taxonomies was the most computationally intensive and slowest process, driven by the sheer volume of contextual data passed in each batch and the high reasoning effort required.

3.2.2 Token utilisation and computational load↩︎

Beyond financial cost and execution time, the computational footprint of an LLM is measured in tokens. A token is the fundamental unit of data processed by the model, representing a sequence of characters or a sub-word rather than a complete linguistic word. Tracking token volume is essential for optimising prompt architecture and estimating computational hardware requirements, particularly if operators choose to deploy locally hosted open-source models to ensure strict operational data privacy.

Figure 7 details the token utilisation across the project, illustrating the ratio between input tokens (the dynamic prompts) and output tokens (the model’s thinking window with generated responses).

Globally, the pipeline processed significantly more input tokens (84.4%) than it generated output tokens (15.6%). This distinction is a critical economic metric, as API providers universally price generation tasks higher than prompt processing tasks. Analysing specific pipeline phases reveals a direct correlation between token distribution and the nature of the analytical task. Large-scale classification tasks, such as failure mode labelling, were heavily skewed towards input tokens. This reflects a process where the model digests substantial context of applicable taxonomies alongside rigid deterministic rules to generate a highly constrained output.

In stark contrast, semantic clustering tasks exhibited a completely inverted distribution, with output tokens forming the majority. This inversion is highly characteristic of generative knowledge extraction, where the model evaluates a system-based batch of historical observations to synthesise and write highly detailed empirical taxonomies.

3.3 Analytical capabilities unlocked by structured data↩︎

The ultimate objectives of deploying LLMs to standardise CMMS records are to correct the inaccuracies brought by data entry practices and transition from qualitative text to quantitative reliability intelligence. By successfully isolating true functional failures from routine interventions and correcting hierarchical misclassifications, the resulting dataset provides a highly accurate foundation for advanced analysis.

3.3.1 Variance in maintenance-log-derived failure rates↩︎

The most immediate application of this structured data is the recalculation of system-level failure rates. Historically, operators rely on the frequency of logged maintenance interventions to estimate these rates and prioritise maintenance resources [2], [3]. However, as demonstrated by the automated pipeline, relying on raw, uncorrected legacy data introduces significant noise and categorical bias. To illustrate the impact of these data corrections on high-level reliability metrics, Figure 8 presents a diverging bar chart mapping the variance in normalised failure rates across the primary wind turbine systems.

The most profound categorical shift is the emergence of the pitch system as a distinct category. Accounting for 9.67% of the newly structured data, this system was previously absent from the legacy dataset. Because these pitch interventions were historically hidden within adjacent structural codes, the rotor blades experienced the most significant corresponding reduction in its perceived failure rate share (-6.99%).

Beyond the pitch system, the semantic filtering of non-failure events, such as routine inspections and scheduled preventive replacements, heavily impacted other major classifications. The hub with main shaft and non-pitch hydraulic systems both experienced substantial reductions in their perceived failure rates (-2.71% and -2.57%, respectively), causing both systems to drop four positions in the overall failure rates ranking. Conversely, systems like the yaw saw a relative increase in prominence (+0.85%), rising three positions in the fleet-wide ranking.

These variance metrics confirm that systematic data corrections are vital for robust reliability analytics. The automated structuring process profoundly alters not only the absolute failure rates but also the relative ranking of critical systems. Since operators utilise these rankings to dictate inventory logistics and planned maintenance priorities, relying on uncorrected legacy data inevitably leads to the misallocation of resources.

It is important to acknowledge that the failure rates presented here are derived strictly from the counts of confirmed corrective actions, normalised by the number of turbines and years of operation. For a comprehensive reliability analysis, the current industry best practice involves fusing these structured maintenance logs with SCADA data and operational alarms. This integration is necessary to definitively confirm the associated downtime for each event, which may yield a slightly different distribution of failure criticality when weighted by lost production.

3.3.2 Empirical taxonomy of maintenance actions↩︎

A major limitation of the legacy CMMS dataset was the sparsity and generic nature of the recorded maintenance actions. Historically, technicians were restricted to highly ambiguous categorical selections, predominantly defaulting to repairs and replacements, with a significant portion of labels left blank. By deploying the LLM to semantically cluster the system-specific interventions, the pipeline successfully extracted a highly precise, evidence-based taxonomy of maintenance actions. To visualise the increased richness and diversity of this new diagnostic vocabulary, Figure 9 presents a treemap detailing the proportional distribution of the primary active verbs that initiate each extracted maintenance action label.

While replacements (53.1%) and repairs (16.8%) remain the dominant actions, accurately reflecting the corrective and predictive filtering of the source data, the semantic extraction has unlocked a vast secondary tier of operational interventions. Activities that were previously hidden beneath generic legacy codes are now explicitly categorised. For instance, the dataset now precisely isolates diagnostic and preventative actions such as inspections (7.1%), adjustments (3.2%), and cleaning works (2.6%), alongside interventions like resets (2.1%) and installations (1.5%).

Furthermore, the taxonomy captures a highly diverse long tail of specific technical interventions, ranging from fluid management ("Top-up", "Lubricate") to fine mechanical corrections ("Align"). This dramatically expanded vocabulary not only provides a more transparent operational picture but also enables operators to track precise resource consumption, allowing reliability engineers to statistically distinguish between the downtime required to physically align a mechanical drivetrain component versus simply resetting its associated control logic.

While the distribution of active verbs provides a macroscopic view of maintenance types, the full action strings demonstrate the precise, component-level granularity achieved by the automated pipeline. By synthesising the unstructured descriptors, the LLM generated labels that are highly concise yet specific enough to clearly identify the targeted subcomponent. To illustrate this practical output, Figure 10 details the twenty most frequent specific maintenance actions extracted across the entire fleet, alongside the primary turbine systems in which they occurred.

A primary observation from this distribution is the dominance of structural component interventions. Actions associated with the rotor blades and the tower structure occupy the highest frequencies. The most common action across the dataset, repairs of blade surface, is a massive outlier with 669 occurrences. This reflects the critical operational reality of wind energy generation, where regular inspections and proactive surface repairs are strictly necessary to mitigate environmental wear and maintain aerodynamic efficiency.

The taxonomy also highlights the difference between highly localised interventions and cross-system maintenance trends. While actions like replacements of pitch system batteries are inherently unique to their respective subsystems, other actions reveal fleet-wide vulnerabilities. For example, replacements of fuses is the third most common action globally, having been independently extracted and assigned across seven different functional systems, including the converter, drivetrain, and transformer.

Furthermore, the extracted labels accurately capture major, high-capital interventions. The replacement of the gearbox as an entire system appears 101 times. Contextualised against a fleet of 280 turbines over a nine-year operational period, this metric provides immediate, actionable intelligence for lifecycle cost modelling and strategic spares procurement.

Finally, reinforcing the previously discussed diversity of the active verbs, it is notable that three of the top twenty actions fall entirely outside the traditional corrective paradigms of repairing or replacing. The prevalence of inspections of tower surface and fibre-converter operation within the condition monitoring system, as well as cleaning oil retention trays within the hub and hydraulic systems demonstrates the model’s high fidelity in capturing preventative and diagnostic operational reality.

3.3.3 Foundations for evidence-based failure modes and effects analysis↩︎

Traditional FMEA heavily relies on the qualitative, experience-based judgement of expert panels to define fault categories and theorise their underlying mechanisms [5], [6]. The methodology presented in this study offers a paradigm shift, enabling the autonomous extraction of empirical, evidence-based failure mode dictionaries directly from historical CMMS data. By semantically parsing thousands of technician entries, the LLM successfully populated the four critical pillars of a reliability event: the designated failure mode, the dominant physical degradation mechanism, the observable symptoms, and the candidate or inferred cause. To illustrate the depth and utility of this analytical asset, Table 4 details the ten most frequent failure modes extracted across the entire fleet.

4pt

The generated dictionary immediately highlights the vulnerability of external structural components. Blade shell or coating damage requiring repairs emerges as an extreme outlier, accounting for 704 recorded instances. The taxonomy associates these events with mechanisms such as surface coating breakdown and laminate wear, and with candidate drivers including long-term environmental exposure and cyclic loading. The structural integrity of the rotor is further challenged by the second most frequent failure mode, involving the fracture or loosening of blade root attachment bolts. The LLM links this critical fault to candidate mechanisms and causes such as high cyclic pitch loads, fretting, and preload loss, providing a precise mechanical context that is often lost in generic legacy codes.

The data also provides profound insights into the electro-mechanical drivetrain and its associated diagnostic infrastructure. Rolling-contact fatigue in generator bearings is highly prevalent, ranking third for the drive-end (DE) and seventh for the non-drive-end (NDE). Crucially, the extracted symptoms reveal that these faults are predominantly detected via condition monitoring system vibration growth, validating the operational value of these sensors. However, the taxonomy simultaneously exposes the inherent vulnerability of the monitoring hardware itself. The detachment of vibration sensors due to adhesive loss and communication failures at the fibre converter rank prominently in the top ten. This reveals a critical operational reality: the diagnostic systems deployed to prevent catastrophic drivetrain failures constitute a significant maintenance burden in their own right.

Finally, the empirical dictionary captures the fragility of power electronics and turbine control networks. Failures within InterBus nodes, converter printed circuit boards, and main inverter contactors feature heavily in the most frequent interventions. The model associates these electrical faults with candidate causal factors, including thermal ageing, electrical arcing, moisture ingress, and over-voltage stress. By providing this level of mechanistic detail automatically, the structured dataset provides an evidence-linked starting point for FMEA, reducing the need for manual root-cause speculation while still requiring later validation for definitive causal claims.

3.3.4 Topological comparisons↩︎

The topology-aware nature of the semantic pipeline enables deep comparative analyses between varying architectural designs. This capability is critical for modern reliability engineering, as fundamentally different subcomponent topologies exhibit entirely distinct degradation profiles and require tailored FMEA strategies. Of the 280 turbines analysed, 130 turbines (46.4%) use electrical pitch systems and 150 turbines (53.6%) use hydraulic pitch systems. All turbines in the observed fleet are represented with equal operating-hour exposure in the dataset; therefore, topology-specific operating hours and turbine-years are proportional to the number of turbines in each group. To illustrate this, Table 5 contrasts the most frequent failure modes extracted for turbines equipped with electrical pitch systems against those utilising hydraulic pitch actuation, reporting record counts and associated subsystems.

4pt

The generated failure profiles reveal a stark divergence in the underlying physical nature of the faults, even after adjusting for the modest difference in topology population size. The electrical pitch system is dominated by the degradation of its emergency power supply (EPS) and solid-state power electronics. The most frequent fault by a significant margin is pitch battery capacity loss or voltage collapse, associated in the extracted dictionary with calendar ageing and cyclic charge-discharge stresses. Normalised against the electrical-pitch population, this corresponds to 50.0 records per 100 electrical-pitch turbines, compared with 19.3 records per 100 hydraulic-pitch turbines for the most common hydraulic failure mode, combined hydraulic leakage and mechanical play. This is closely followed by failures in battery contactors, inverters, and charging electronics, all of which are linked to candidate stressors such as thermal cycling, electrical overstress, and vibration.

From a criticality perspective, this electrical failure profile presents a severe operational risk. The EPS ensures the turbine can autonomously pitch the blades to a safe aerodynamic stall during a grid loss or critical failure. The high frequency of battery and contactor faults indicates a fragile fail-safe mechanism, where sudden electronic death or voltage collapse can immediately compromise the turbine’s survival capability, necessitating rigorous, calendar-based preventive replacements and resulting in high component costs.

Conversely, the hydraulic pitch system profile is characterised by progressive mechanical and fluid power degradation. The dominant issues involve combined hydraulic leakage and mechanical play, alongside degraded accumulator pressure storage, and cylinder external oil leakage. The semantic extraction identifies candidate causal patterns for these faults, including elastomer fatigue, seal ageing, age-related gas permeation, and fluid contamination. Interestingly, the hydraulic profile also highlights a specific vulnerability to vibration, evidenced by the high frequency of controller area network (CAN) communication cable faults associated with loosened terminations.

The criticality of the hydraulic profile differs fundamentally from its electrical counterpart. While the degradation of the hydraulic accumulator mirrors the safety-critical risk of the electrical batteries (loss of fail-safe energy storage), the majority of hydraulic faults are gradual rather than sudden. Progressive seal wear and minor leakages do not immediately threaten the turbine systems, but they lead to chronic losses in pitch precision, continuous fluid replenishment costs, and potential environmental hazards within the hub.

Ultimately, this comparison demonstrates that treating the pitch system as a monolithic category in legacy CMMS data severely obscures the reality of turbine operation. By autonomously extracting these topology-specific empirical dictionaries, the LLM pipeline empowers operators to transition from generic maintenance checklists to highly targeted, condition-based FMEA frameworks.

4 Discussion↩︎

While the preceding results section detailed the quantitative success rates of the automated pipeline, the categorical correction flows, the underlying project economics, and the advanced analytical capabilities unlocked by the structured data, a broader evaluation of the methodology is required. This section critically examines the proposed framework, addressing the inherent limitations of applied AI in this domain, evaluating its comparative advantages over traditional ML and manual expert processing, discussing its scalability to other industrial sectors, and outlining the necessary directions for future research.

4.1 Limitations↩︎

The primary limitation of this methodology, as with any application of generative AI, is the inherent risk of model hallucinations. LLMs, despite their advanced semantic reasoning, operate probabilistically and will occasionally generate plausible but factually incorrect labels or infer inaccurate causal links. The pipeline developed in this study incorporates multiple layers of mitigation to suppress this behaviour, including robust prompt engineering, rigorous adherence to strict data schemas, CoT reasoning protocols [26], and the application of deterministic rules based on reported confidence levels and intermediate labels. Nevertheless, a residual risk remains that the LLM may misclassify a complex or highly ambiguous maintenance description.

However, this technological limitation must be contextualised against the current baseline of industrial reliability engineering. Traditional FMEA is a highly subjective, qualitative process [6], [7]. Component failure lists are typically curated based on the personal experience of specific engineering panels, and the constituent factors of the RPN are manually assigned using arbitrary, qualitative scales. Despite previous efforts in the literature to introduce weighting functions and cost variables to the RPN equation, human inconsistency remains a profound source of error [7], [8]. Consequently, a systematic, deterministic, data-driven LLM pipeline, even with a marginal hallucination rate, is arguably more reliable and vastly more consistent than a fragmented, manual FMEA workflow reliant on subjective interpretation.

To further suppress the hallucination risk and elevate the accuracy of the automated pipeline, two distinct future improvements are required: domain-specific fine-tuning and continuous model benchmarking.

The most effective method for mitigating classification errors is to fine-tune an LLM exclusively on domain-specific wind turbine maintenance data. However, training such a model requires a massive, high-fidelity dataset of manually verified, gold-standard labels. Building this foundational dataset demands a significant investment of expert engineering resources. Once established, this verified dataset would not only enable the development of highly specialised, hallucination-resistant LLMs but would also facilitate the rigorous, application-specific benchmarking of new, continuously evolving models entering the market.

While our research group has previously developed and published a dedicated framework for benchmarking LLM performance on maintenance log labelling tasks [16], executing that framework across the complete, full-scale dataset used in this current study was limited by the resource constraints associated with manual expert labelling. Developing this gold-standard dataset remains a critical prerequisite for the next evolutionary stage of LLM-assisted reliability engineering.

4.2 Comparative methodological advantages↩︎

4.2.1 Traditional machine learning bottlenecks↩︎

Historically, efforts to automate the processing of CMMS data have relied heavily upon traditional NLP and ML techniques [9], [11], [12]. While these legacy methods represent a significant improvement over manual data entry, the transition to LLMs offers profound methodological advantages.

For foundational classification tasks with the CMMS data, traditional ML approaches present distinct logistical bottlenecks. Firstly, they require the curation of massive manually labelled training datasets. Secondly, to achieve acceptable accuracy in a highly specialised engineering domain, developers must often design highly specific rules to explicitly map thousands of text patterns to exact turbine subsystems. Furthermore, these models are inherently language-dependent. Because wind turbine maintenance logs are typically recorded in the native language of the host country, a traditional NLP pipeline developed for a UK wind farm would require complete retraining to be deployed at a site in Portugal or Germany. In contrast, state-of-the-art LLMs act as language-agnostic tools [13], [14], seamlessly processing multilingual data without a preliminary translation step.

However, when the objective shifts from simple classification to the deep semantic clustering required for deriving empirical taxonomies, traditional NLP libraries fundamentally reach their architectural limits. Extracting highly specific maintenance actions and formulating comprehensive failure mode labels requires the ability to analyse the underlying physical meaning of the text and infer plausible causal relationships. Because LLMs are supported by massive pre-trained knowledge bases spanning multidisciplinary engineering domains, they can propose evidence-supported links between reported symptoms and candidate causes. Replicating this level of evidence-based taxonomy generation using non-generative ML clustering techniques ultimately still requires human subject-matter experts to manually interpret the abstract data clusters and author the final failure modes.

4.2.2 Limitations of manual expert review↩︎

Because legacy ML models ultimately defer to human interpretation for complex taxonomy generation, the traditional gold standard for extracting reliability intelligence remains manual review by subject-matter experts. While human interpretation is highly nuanced, relying on manual processing of large datasets presents severe logistical and economic bottlenecks that prohibit fleet-wide scalability.

The most immediate constraint is the sheer time required to execute the task. Human cognitive bandwidth fundamentally limits the speed at which complex, unstructured maintenance logs can be read, cross-referenced, and accurately categorised. For large-scale wind farm operators managing multi-gigawatt fleets, the volume of generated data rapidly eclipses the capacity of any manual review team. Directly coupled with this temporal constraint is the prohibitive financial cost. Accurately diagnosing system faults and inferring failure mechanisms from sparse technician notes requires personnel with numerous years of applied engineering experience. Diverting such highly qualified experts away from active operational problem-solving to perform repetitive, fatigue-inducing data categorisation represents a highly inefficient allocation of expensive resources.

In stark contrast, the LLM-driven pipeline offers unparalleled temporal scalability and standardisation. As demonstrated in the project economics, the automated framework successfully processed thousands of complex logs in a matter of hours, unlocking vast archives of historical data for mere cents per log. Furthermore, whereas manual processing is inherently susceptible to subjective bias, the LLM applies a uniform, deterministic analytical logic across the entire dataset, guaranteeing standardisation and transitioning the sector from automated data sorting to automated reliability reasoning.

4.3 Scalability to other fields↩︎

Although this study focuses explicitly on the wind energy sector, the underlying methodology is highly modular and readily scalable to other industrial domains. Because the pipeline relies on the semantic reasoning capabilities of LLMs rather than hard-coded classification rules, its application extends well beyond wind turbine architectures.

Within the broader renewable energy sector, this framework can be directly adapted for emerging technologies, such as tidal turbines and wave energy converters. These assets operate in similarly harsh environments, utilise comparable electro-mechanical drivetrains, and face equivalent challenges regarding remote maintenance logging and component reliability.

Beyond renewable energy, the framework offers significant value to any heavy industry reliant upon CMMS logging. Platforms such as IBM Maximo are ubiquitous across manufacturing, maritime, aviation, and oil and gas operations [22]. Crucially, the micro-scale data defects identified in this study, including unstructured free-text descriptions, omitted hierarchical codes, and subjective action labels, are universal symptoms of manual data entry in field environments, irrespective of the specific industry.

To redeploy this automated pipeline in a new sector, the underlying software architecture remains unchanged. The primary modifications required are the provision of a domain-relevant system taxonomy and the adjustment of the contextual system prompts. Consequently, this approach provides a generalisable blueprint for standardising maintenance intelligence across the wider industrial landscape.

4.4 Future model development↩︎

A core strength of the presented methodology is its model-agnostic architecture. Operating on fundamental semantic reasoning capabilities and strict programmatic data schemas, the pipeline avoids reliance on proprietary features from a single AI provider. Consequently, researchers and operators can seamlessly integrate any future, highly capable LLM into this established framework without structural changes to the underlying procedural logic.

Looking forward, this model-agnostic nature directly facilitates the strategic transition towards locally hosted, domain-specific models. Currently, flagship models accessed via third-party APIs offer superior semantic reasoning compared to smaller, open-source alternatives. However, by fine-tuning these local models on the high-confidence, structured datasets generated by pipelines such as the one presented herein, the industry can actively bridge this capability gap. Deploying highly specialised, locally hosted LLMs will ultimately eliminate the reliance on external API providers, drastically reduce long-term processing costs, and ensure strict operational data privacy. Once developed, these fine-tuned models should be subjected to rigorous benchmarking against human domain experts to definitively quantify their comparative accuracy and establish a new baseline for automated data processing.

4.5 Future research directions↩︎

The successful standardisation of the legacy dataset directly resolves the macro-level data bottlenecks previously identified in the problem statement, paving the way for highly advanced downstream applications.

The immediate next step in this research trajectory is the execution of a comprehensive reliability study, achieved by fusing this newly structured maintenance intelligence with SCADA data and operational alarms. This integration will enable the candidate causes extracted here to be tested in a definitive root-cause analysis, linking the extracted component failures directly to actual production downtime and lost revenue. Furthermore, this enriched dataset will facilitate the execution of a fully evidence-based FMEA. Crucially, the constituent parameters of the RPN calculation, which are traditionally reliant on subjective expert estimation, can now be rigorously quantified. Specifically, the occurrence parameter can be calculated using the empirical failure frequencies extracted by the automated pipeline, while the severity parameter can be objectively measured through the resulting downtime and financial losses.

Furthermore, the availability of granular, machine-readable maintenance records unlocks several advanced engineering applications across the wider wind energy sector. The empirical failure modes and their associated candidate causes provide the necessary foundation for building robust operations and maintenance optimisation frameworks, allowing operators to dynamically allocate resources based on genuine risk prioritisation.

Beyond the retrospective cleaning of legacy data and subsequent predictive analytics, the capabilities demonstrated in this study suggest a transformative approach to future maintenance management. Rather than relying solely on post-hoc standardisation, a similar LLM-agent framework could be integrated directly into the CMMS interface at the point of data entry. Operating within a human-in-the-loop paradigm [23], the LLM could serve as an interactive bridge between field technicians and the central database. By semantically analysing a technician’s free-text input in real time, the agent could proactively suggest the correct hierarchical system codes, standardise the action verbs, and prompt for missing failure mechanisms before the work order is closed. This proactive quality control would drastically improve data standardisation at the source, preventing categorical noise from ever entering the reliability pipeline.

Ultimately, the methodology demonstrated in this paper advocates for a systemic shift in how the industry categorises asset maintenance data. It suggests that future, globally adopted maintenance taxonomies should be designed organically from empirical operational evidence, rather than relying solely on static, theoretical design specifications.

5 Conclusion↩︎

This paper has demonstrated the transformative potential of LLMs in resolving the pervasive data quality bottlenecks within industrial maintenance management. By deploying a multi-phase automated pipeline, the study successfully transitioned over nine years of unstructured, noisy wind turbine maintenance logs into a highly granular, machine-readable dataset. The framework effectively overcame the limitations of traditional NLP and manual expert review, acting as a tool capable of deciphering complex, multilingual technician entries without the need for rigid heuristic rules or extensive model training.

The automated pipeline exhibited high efficacy in rectifying systemic misclassifications, successfully correcting hierarchical system codes for over 13% of the global dataset and recovering critical metadata from previously orphaned records. Notably, the model structured over 70% of the historical data into comprehensive failure mode profiles, autonomously extracting dominant physical degradation mechanisms, observable symptoms, and prevalent candidate causes. This deep semantic extraction revealed critical operational realities that were historically hidden by legacy generic labels, such as the severe impact of pitch system interventions and the profound degradation differences between electrical and hydraulic component topologies. Furthermore, the economic analysis confirmed that this methodology is highly scalable and cost-effective, operating at a fraction of the time and financial investment required for manual expert processing.

Ultimately, this research fundamentally advances the practices of reliability analysis. By autonomously generating empirical maintenance taxonomies directly from field observations, the framework provides a robust solution to the inherent subjectivity of traditional FMEA. The resulting structured intelligence yields a rigorous quantitative foundation for future operational assessments. When fused with SCADA data and operational alarms, this refined dataset will enable highly accurate predictive maintenance modelling, dynamic resource allocation, and a systemic shift towards evidence-based asset management across the wider renewable energy sector.

Data Availability Statement↩︎

To ensure the reproducibility and transparency of this study, the underlying Python code architecture, alongside the dynamic prompts and data schemas utilised herein, has been open-sourced as an adjustable template and can be accessed via the corresponding author’s GitHub repository. Please note that due to commercial sensitivity, the maintenance log dataset used in this study cannot be shared. This publicly available framework is intended for researchers and operators to apply to their own proprietary data, implement adjustments, suggest improvements, and test the performance of different models for labelling CMMS data. Researchers utilising this framework in their own work are kindly requested to cite this article.

Funding↩︎

This study is part of an ongoing PhD project on wind turbine reliability, funded by the School of Engineering at the University of Edinburgh. The project received no other grants from any funding agency in the public, commercial, or not-for-profit sectors.

Acknowledgements↩︎

The authors gratefully acknowledge EDINA, a centre for data and digital expertise based at The University of Edinburgh, for providing the OpenAI API keys utilised in the study.

Conflicts of Interest↩︎

The authors declare no conflicts of interest.

Author Contributions↩︎

Max Malyi: Conceptualisation, Formal analysis, Investigation, Methodology, Software, Visualisation, Writing–original draft, Writing–review & editing. Jonathan Shek: Resources, Supervision, Writing–review & editing. Alasdair McDonald: Supervision, Writing–review & editing. André Graça Biscaya: Data curation, Supervision, Writing–review & editing.

References↩︎

---

1. Corresponding author: Max.Malyi@ed.ac.uk↩︎