# Aperture: A Hybrid Digital Twin for Utility-Scale Wind Turbine Condition Monitoring and Operational Decision Support **Matthew Mitchell** MMKPC Studios · Independent Research memitchell@mmkpcstudios.com *April 2026* --- ## Abstract Unplanned drivetrain failures and chronic underperformance cost utility-scale wind operators tens of millions of dollars annually in lost generation and corrective maintenance. Academic digital twins for wind turbines are either physics-heavy tools requiring dedicated compute infrastructure or lightweight dashboards lacking simulation capability—neither is deployable from a web browser. This paper presents **Aperture**, a hybrid browser-native digital twin integrating four pure-JavaScript machine-learning models against Kelmarsh-schema 10-minute SCADA data, physics-light scenario simulation, a procedural Three.js 3D scene, and a DCS-style alarm annunciator, all served as a zero-dependency static web application. Aperture implements a 9-layer reference architecture aligned to established digital twin engineering practice and demonstrates, within a single deployable artifact, all four canonical subject areas: DT foundations, ML for modeling and simulation, real-time simulation, and integrated operator-facing applications. Four contributions are reported: (1) a portable single-page DT reference architecture requiring no backend or cloud runtime; (2) a fault-injection testbed with seven reproducible failure modes; (3) a reproducible evaluation pipeline scoring four models—power-curve linear regression surrogate, gearbox KNN forecaster, operational-state tree classifier, and multivariate anomaly scorer—against held-out Kelmarsh records using walk-forward validation; and (4) a closed-loop actuator surface supporting operator-commanded pitch, yaw, shutdown, and alarm acknowledgment. Headline metrics: power-curve RMSE 88.63 kW, MAE 62.42 kW, R² 0.9758; gearbox forecast RMSE 3.36 °C; classifier accuracy 0.9243, macro-F1 0.5839; anomaly AUROC 0.8601, AUPRC 0.5172; median inference latency 0.869 ms, p95 0.970 ms. The published values are preserved in [`scripts/metrics.json`](../scripts/metrics.json); the full evaluation runner and raw dataset remain private development materials. --- ## 1. Introduction ### 1.1 Historical Context of Digital Twins The digital twin concept was first articulated by Michael Grieves at a Society of Manufacturing Engineers conference in 2002 and formalized in a widely circulated 2014 white paper [1]. Grieves described a virtual factory replication comprising three elements: the physical product, its virtual counterpart, and bidirectional data and information connections between them. The explicit goal was to use the virtual model to drive manufacturing excellence without requiring physical experimentation. The term "Digital Twin" entered aerospace engineering through Glaessgen and Stargel's 2012 AIAA paper, which defined a digital twin as "an integrated multi-physics, multi-scale, probabilistic simulation of an as-built vehicle" and argued that ultra-high-fidelity structural health management demanded both real-time sensor feeds and physics-based simulation operating in concert [2]. From those two foundational definitions, the field evolved rapidly. Tao et al. introduced the five-dimension (5D) model—physical entity, virtual entity, DT data, connections, and DT services—which became the most-cited DT taxonomy in manufacturing [3][7]. Kritzinger et al. refined the taxonomy into a three-tier maturity hierarchy: *digital model* (no automated data flow), *digital shadow* (one-way physical-to-digital flow), and *digital twin* (fully bidirectional automated connection) [6]. International standardization followed with ISO 23247-1, which specified a reference architecture for manufacturing digital twins organized into four functional domains: observable manufacturing elements, device communication, the DT core, and user interfaces [5]. Fuller et al. surveyed the enabling technology landscape—AI/ML, IoT, cloud, VR/AR—identifying the cross-disciplinary infrastructure a production DT requires [8]. ### 1.2 The Wind Energy Imperative Wind energy is one of the fastest-growing electricity sources globally. The International Energy Agency projects continued capacity additions through 2030, with both onshore and offshore wind contributing substantially to decarbonization targets. As fleets mature, operations and maintenance (O&M) costs become the dominant financial variable: Tautz-Weinert and Watson document that O&M represents 25–30% of the levelized cost of energy (LCOE) for wind, and that unplanned failures—particularly gearbox, generator bearing, and blade failures—account for a disproportionate share of that cost because they require heavy-lift crane mobilization and extended downtime [20]. SCADA-based condition monitoring, which uses the 10-minute mean telemetry streams that turbine controllers already record, has been shown in multiple field studies to detect anomalies weeks to months before mechanical failure [20][39]. The wind turbine digital twin literature has matured accordingly. Sivalingam et al. proposed a DT framework for remaining useful life prediction of offshore power converters [19]. Olatunji et al. surveyed physics-based, data-driven, and hybrid DT architectures for fault diagnosis, identifying open challenges in data quality, real-time synchronization, and model uncertainty [21]. Marykovskiy et al. demonstrated the Aerosense digital twin—a digital-shadow-class system for blade aerodynamic monitoring built on MEMS sensors, cloud API, and simulation services [22]. Tchakoua et al. provide a comprehensive failure-mode taxonomy covering vibration, acoustic emission, oil analysis, and SCADA-based monitoring methods [38]. Schlechtingen and Santos benchmarked ANN, polynomial regression, and SVR as normal-behaviour models for bearing temperature monitoring, showing that SVR generalizes better than ANNs on small SCADA datasets [39]. Despite this body of work, a consistent gap remains between academic DT prototypes and tools that a wind farm operator can actually deploy and interact with. High-fidelity physics platforms such as NREL's OpenFAST [23] require significant computational resources and domain expertise to configure. Cloud platforms such as Azure Digital Twins [32] and enterprise offerings such as NVIDIA Omniverse [33] provide production-grade infrastructure but impose licensing, backend, and integration costs that make them inaccessible for rapid prototyping or educational demonstration. Open-source frameworks such as OpenTwins [29][30] lower the barrier substantially but still require container orchestration. ### 1.3 Problem Statement and Thesis No existing open-source wind turbine DT runs entirely within a standard web browser, requires no backend infrastructure, and simultaneously demonstrates the full stack of digital twin engineering competencies: physics-light simulation, multiple ML surrogate models, fault detection, scenario branching, 3D visualization, and operator interaction. This absence creates a gap for both education and rapid operational prototyping. The thesis of this work is: **a portable, browser-deployable, hybrid physics/ML digital twin that runs against open SCADA data can exercise every pillar of digital twin engineering practice — fundamentals, ML surrogates, real-time simulation, and integrated operator-facing applications — while remaining honest about its fidelity limits relative to production-grade platforms**. The resulting system, Aperture, is a defensible reference prototype that prioritizes transparency, reproducibility, and operator-first design over photorealistic rendering or billing-grade accuracy. ### 1.4 Contributions This work makes four primary contributions: 1. **A portable single-page DT reference architecture**: a 9-layer browser-native implementation that maps directly to established DT engineering layer models, requiring only a static file host for deployment. 2. **A fault-injection testbed**: seven reproducible fault modes (gearbox overheat, pitch actuator stuck, yaw misalignment, generator bearing fault, blade icing, cut-out exceedance, normal) that drive the full inference and annunciator pipeline. 3. **A reproducible evaluation pipeline**: the private evaluation runner scores all four models against held-out Kelmarsh SCADA records using chronologically ordered walk-forward splits. This public mirror includes the resulting metrics and signal mapping as inspectable artifacts. 4. **A closed-loop operator interface**: DCS-style annunciator, actuator command surface (pitch, yaw, shutdown, reset), fault-injection selector, and scenario quick-buttons, all wired to the live twin state. ### 1.5 Paper Roadmap Section 2 surveys background literature across the four course areas and closes with a gap analysis table. Section 3 describes the methodology: design principles, 9-layer architecture, data model, ML specifications, simulation engine, and HMI. Section 4 details the implementation. Section 5 reports experiments and evaluation against Kelmarsh SCADA data. Section 6 discusses program alignment, design trade-offs, comparisons to commercial platforms, and threats to validity. Section 7 enumerates known limitations and planned future work. Section 8 concludes. Appendix A lists the module inventory; Appendix B provides reproducibility instructions. --- ## 2. Background and Related Work ### 2.1 Digital Twin Definitions and Taxonomies The canonical Grieves 2014 definition treats the digital twin as a closed-loop system: the physical product sends sensor data to its virtual counterpart, the virtual model runs simulations and predictions, and those outputs inform decisions that affect the physical product [1]. The NASA/USAF paradigm of Glaessgen and Stargel extends this to "ultra-high-fidelity" multi-physics simulation, motivating the use of probabilistic structural models for aerospace health management [2]. Both definitions emphasize bidirectionality as the distinguishing property. Tao et al. survey the state of the art in industrial digital twins, reviewing the 5D model across product design, production, and maintenance applications and noting that the service dimension—which encompasses analytics, simulation, and recommendation functions—is what differentiates a DT from a traditional simulation model [3]. The companion paper by Tao et al. comparing digital twins with cyber-physical systems clarifies that DTs extend CPS by adding the historical data integration layer and the digital twin aggregate concept, in which a fleet-level DT aggregates information across individual unit twins [4]. ISO 23247-1 operationalizes these ideas into a normative reference architecture specifying the observable manufacturing elements domain, the device communication domain, the DT core, and the user-application domain [5]. The Kritzinger taxonomy is particularly useful for positioning Aperture. Under that framework, a *digital model* has no automated data link to the physical asset; a *digital shadow* has a one-way automated link from physical to digital; and a *digital twin* has a fully automated bidirectional link [6]. Aperture targets the digital shadow tier during normal operation—it ingests synthetic SCADA samples that faithfully replicate the Kelmarsh signal schema, processes them through the full 9-layer pipeline, and presents predictions and alarms to the operator—with closed-loop actuator commands demonstrating the bidirectional feedback path required for the true digital twin tier. The Tao 5D model [7] is reflected in Aperture's architecture: physical entity (the Senvion MM92 turbine profile), virtual entity (Three.js 3D scene and state schema), DT data (SCADA stream and feature store), connections (event bus with typed channels), and DT services (inference engine, scenario manager, annunciator). Fuller et al. survey enabling technologies for DTs across manufacturing, healthcare, and smart cities, identifying AI/ML, IoT, cloud, and VR/AR as the four pillars [8]. Aperture implements the AI/ML and 3D visualization pillars natively in the browser, defers IoT ingestion to a synthetic SCADA generator designed around the real Kelmarsh schema, and acknowledges cloud deployment as a future step. ### 2.2 Machine Learning for Digital Twin Surrogates Rasheed, San, and Kvamsdal provide the most comprehensive treatment of DT modeling from first principles, covering reduced-order models, data assimilation, uncertainty quantification, and the spectrum from purely data-driven to purely physics-based surrogates [9]. They define a digital twin as "a virtual representation of a physical asset enabled through data and simulators for real-time prediction"—a definition that guides the hybrid design of Aperture's inference engine. Their taxonomy of surrogate types informs the choice of a polynomial linear regression for the power-curve model: the power-wind relationship follows a known cubic physical law in the partial-load region, making a polynomial feature expansion \([v, v^2, v^3, T]\) a principled rather than arbitrary surrogate. Physics-informed neural networks (PINNs), introduced by Raissi, Perdikaris, and Karniadakis, embed PDE residuals directly into the neural network loss function, enabling data-efficient surrogates that respect physical constraints [10]. For a wind turbine DT, PINNs could enforce the Betz limit (\(C_P \leq 16/27\)) and structural Euler-Bernoulli beam constraints during aerodynamic surrogate training. Aperture does not implement PINNs in the current prototype—the polynomial regression surrogate is simpler and interpretable—but PINNs are identified as the primary planned extension in Section 7. Bertsimas and Dunn's Optimal Classification Trees (OCT) algorithm formulates the entire decision tree as a mixed-integer optimization problem, producing globally optimal interpretable classifiers with 1–5% accuracy improvements over greedy CART [11]. Aperture's operational-state classifier implements depth-2 rule trees operating on canonical SCADA signals (wind speed, anomaly score, pitch angle, rotor RPM, power) as a practical approximation of the OCT concept within the constraints of a pure-JavaScript runtime. Garg et al. review AI-driven surrogate modeling for DTs in energy systems, covering Kriging, radial basis functions, SVR, and neural network surrogates, and mapping each to DT fidelity levels [12]. Their analysis supports the choice of KNN for the gearbox temperature forecaster: KNN is non-parametric, requires no distributional assumptions, and generalizes well when the feature space is low-dimensional and the training corpus is dense relative to the query region—conditions met by the five-dimensional gearbox feature vector used in Aperture. Qi et al. survey enabling technologies across modeling, simulation, IoT, big data, connectivity, and AI for DTs, connecting transfer learning and anomaly detection to real-time synchronization infrastructure [13]. The Schlechtingen and Santos benchmark study is directly relevant: using SCADA data from an operating wind turbine, they show that SVR outperforms both ANN and polynomial regression for generator bearing temperature monitoring on small datasets, providing empirical justification for residual-based anomaly detection over the bearing temperature channel [39]. Aperture's anomaly scorer computes a normalized tanh-scaled z-score across power, gearbox, bearing, pitch, and yaw residuals, which is the multivariate extension of the normal-behaviour model pattern validated in that study. ### 2.3 Real-Time Simulation and Industrial Connectivity Law's *Simulation Modeling and Analysis* defines the discrete-event simulation (DES) paradigm, time-advance mechanisms, input modeling, and output analysis as the methodological foundation for any step-through simulation system [14]. The 10-minute interval of the Kelmarsh SCADA data maps directly to the DES concept of a logical clock: each SCADA record advances the simulation by one time step, and the system interpolates continuous dynamics within that step. Aperture's simulation engine steps 30 logical records forward per scenario branch, computing wind integration, thermal drift, and power response at each step. OPC UA is the IEC 62541 standard for platform-independent, secure, semantic industrial data exchange [15]. IEC 61400-25 specifies the information models, object naming, and protocol mappings for SCADA communication at wind power plants, defining logical node (LN) classes for power, temperature, vibration, and electrical measurements [16][24]. The Kelmarsh dataset's Greenbyte SCADA column names are explicitly derived from this standard—for example, `Gearbox oil temperature_avg` maps to the IEC 61400-25-6 logical node for gearbox condition monitoring [24]. Aperture's SCADA schema in `core/schemas.js` adopts the same signal vocabulary to maintain standards alignment even in the browser context. MQTT and Apache Kafka represent the two dominant messaging patterns for industrial IoT data pipelines: MQTT provides lightweight device-level publish/subscribe from nacelle sensors; Kafka provides durable, high-throughput stream brokering for downstream analytics [17][18]. Aperture's internal event bus (`core/bus.js`) mirrors the channel topology of a Kafka-MQTT hybrid—typed channels for `event`, `state`, `prediction`, `simulation`, `behavior`, `scene`, `log`, and `latency`—while acknowledging that the current implementation uses in-process synchronous dispatch rather than a real message broker. Section 7 identifies genuine MQTT/OPC UA ingestion as a planned extension. ### 2.4 Wind Turbine Digital Twins and SCADA-Based Condition Monitoring Sivalingam et al. present one of the earliest domain-specific wind turbine DT proposals, combining physics-based degradation models with a DT framework for diagnosing and predicting power converter failures under offshore thermal cycling [19]. Their methodology—using SCADA temperature signals as the primary observable, fitting normal-behaviour models, and flagging deviations—is directly reflected in Aperture's gearbox temperature forecaster and anomaly scorer. Tautz-Weinert and Watson review five categories of SCADA-based condition monitoring (trending, clustering, normal-behaviour modelling, damage modelling, expert systems) and validate that 10-minute mean signals are sufficient for detecting gearbox, bearing, and blade failures weeks to months in advance [20]. Their review is the primary justification for the Kelmarsh dataset selection: the 10-minute mean/std/min/max quartet resolution is adequate for the monitoring objectives of Aperture. Olatunji et al. survey DT architectures specifically for wind turbine fault diagnosis, categorizing physics-based, data-driven, and hybrid approaches and identifying open challenges around data quality, real-time synchronization, and model uncertainty [21]. Their challenge list maps directly to the limitations in Section 7: Aperture uses synthetic priors rather than online-trained models, synthetic SCADA events rather than live OPC UA feeds, and simple polynomial physics rather than high-fidelity aeroelastic models. Marykovskiy et al. describe the Aerosense digital twin as a "Digital Shadow"-type system for blade aerodynamic monitoring, demonstrating a real-world DT instance aligned with the 5D model and highlighting the co-design challenge of matching sensor hardware to information model requirements [22]. Aperture does not include blade load sensing, but the Aerosense architecture reinforces the value of treating DT design as a systems engineering problem—an approach reflected in Aperture's strict layer separation and typed event contracts. Tchakoua et al. provide a comprehensive review of wind turbine condition monitoring technologies and failure modes, covering all major drivetrain components [38]. Their failure taxonomy—gearbox gear wear, bearing raceway spalling, pitch hydraulic actuator failure, yaw motor fault, blade erosion—directly informs the seven fault modes implemented in `data/scada_stream.js`. Schlechtingen and Santos validate SCADA-based normal-behaviour modelling for generator bearing temperature, motivating Aperture's use of residual-based anomaly scoring over the bearing temperature channel [39]. OpenFAST is NREL's open-source multi-physics wind turbine simulation tool, providing coupled aerodynamic-structural-control simulations [23]. It represents the physics baseline against which Aperture's surrogate models would be validated in a production-grade DT; Section 7 identifies FMU integration via OpenFAST as a planned extension. ### 2.5 Gap Analysis The following table positions Aperture relative to the existing literature across six capability dimensions: | System | Physics Fidelity | ML Integration | Real-Time Sync | Operator UX | Open Source | Reproducibility | |---|---|---|---|---|---|---| | OpenFAST [23] | High (multi-physics) | None native | Batch | None | Yes | High | | Aerosense DT [22] | Medium (MEMS/CFD) | Statistical | Yes (cloud) | Limited | No | Low | | Sivalingam DT [19] | Medium (degradation) | Physics model | Offline | None | No | Low | | OpenTwins [29][30] | Medium (FMU) | Plugin ML/AI | Yes (Kubernetes) | Grafana | Yes | Medium | | Azure Digital Twins [32] | Low (state graph) | Azure ML | Yes (IoT Hub) | 3D Scenes Studio | No (PaaS) | Medium | | NVIDIA Omniverse [33] | Very High (USD/PhysX) | Isaac Sim | Yes (GPU) | Photorealistic | Partial | Low | | **Aperture (this work)** | **Low–Medium (polynomial)** | **4 pure-JS models** | **Synthetic (1 Hz)** | **DCS panel + 3D** | **Yes (static)** | **High** | Aperture occupies a unique niche: the lowest deployment barrier (zero infrastructure), highest UX integration (unified HMI), and highest reproducibility (deterministic replay), at the cost of physics fidelity. This trade-off is appropriate for a reference prototype demonstrating DT engineering competencies in a portable, verifiable artifact. --- ## 3. Methodology ### 3.1 Design Principles Aperture is designed around four principles derived from the DT engineering literature and the requirements of a defensible reference prototype: **Portability**: The entire system must run from a single HTML file served by any static host. No Node.js server, no Python backend, no database, and no cloud subscription should be required. This constraint rules out WebGL compute shaders for ML and forces all model logic into pure ES2020 JavaScript—a constraint that, as Section 4 argues, is consistent with the interpretable surrogate approach recommended by the DT literature [9][12]. **Transparency**: Every prediction must expose its reasoning chain. The power-curve model returns feature contribution weights. The state classifier returns the rule path. The anomaly scorer returns the dominant residual channel and its z-score. The scenario manager reports branch summary statistics. This design philosophy is grounded in explainability requirements established in the DT literature and in the OCT literature's emphasis on interpretable decision rules [11]. **Reproducibility**: The SCADA stream has a deterministic seed for each fault mode, the replay harness captures every event with relative timestamps, and the evaluation pipeline runs against a fixed chronological train/val/test split. The public mirror preserves the published metrics and signal mapping; the raw dataset and full evaluation runner remain outside the portfolio boundary. **Operator-First UX**: The interface presents information in the vocabulary of a turbine control room operator—DCS annunciator panel, alarm severity levels (INFO/WARN/ALARM), actuator command surface (pitch, yaw, shutdown, reset)—not in the vocabulary of a data scientist (loss curves, confusion matrices). Prediction outputs are surfaced through sparklines, gauge meters, and state probability bars that convey operational significance without requiring statistical expertise. ### 3.2 Nine-Layer Architecture Aperture implements a nine-layer architecture adapted from canonical DT reference models to the wind turbine domain. The Avatar Runtime maps to the Three.js turbine scene, the Voice Layer maps to the DCS annunciator, and the Behavior Controller maps to the turbine actuator surface. ``` Physical Asset (Senvion MM92 / Kelmarsh SCADA) │ ▼ ┌─────────────────────────────────┐ │ Layer 1: Ingest Gateway │ gateway.js │ validate · normalize · stamp │ └────────────────┬────────────────┘ │ event (bus CH.EVENT) ▼ ┌─────────────────────────────────┐ │ Layer 2: Twin State Store │ state_store.js │ confidence-weighted reducer │ │ rolling history (1000 records) │ └────────────────┬────────────────┘ │ state (bus CH.STATE) ▼ ┌─────────────────────────────────┐ │ Layer 3: Feature Builder │ builders.js │ rolling means · slopes · vol │ │ window = 120 s wall-clock │ └────────────────┬────────────────┘ │ features struct ▼ ┌─────────────────────────────────┐ │ Layer 4: Inference Engine │ inference.js + models.js │ LR power curve │ │ KNN gearbox forecast │ │ OCT-style state classifier │ │ Multivariate anomaly scorer │ └────────┬───────────┬────────────┘ │ prediction │ CH.PREDICTION │ │ ▼ │ ┌──────────────────────────┐ │ │ Layer 5: Sim Engine + │ engine.js │ │ Scenario Manager │ │ │ baseline/optimistic/ │ │ │ stress branches (30 step)│ │ └─────────────┬────────────┘ │ │ CH.SIMULATION ▼ ▼ ┌─────────────────────────────────────────────────┐ │ Layer 6: 3D Scene (Three.js turbine_runtime.js) │ │ Layer 7: Dashboard UI (dashboard.js) │ │ Layer 8: Annunciator (ops/annunciator.js) │ └──────────────────────┬──────────────────────────┘ │ operator commands ▼ ┌─────────────────────────────────┐ │ Layer 9: Actuator │ behavior/actuator.js │ setPitch · setYaw │ │ triggerShutdown · resetAlarm │ │ trackWind (auto closed loop) │ └─────────────────────────────────┘ │ CH.BEHAVIOR → store.setActuator() ▼ Physical Asset (command feedback) ``` The event bus (`core/bus.js`) is the central nervous system: nine typed channels (`event`, `state`, `prediction`, `simulation`, `behavior`, `voice`, `scene`, `log`, `latency`) carry typed payloads between layers. All subscriptions are synchronous within a single JavaScript event loop tick, so the end-to-end latency from SCADA sample arrival to 3D scene update is bounded by the total processing time of the pipeline rather than by network round-trips. The `main.js` orchestration loop implements the real-time simulation workflow: receive event → validate and normalize → update canonical state → recompute features → run inference → run scenario simulation if triggered → publish behavior commands → update UI → log the full transition. ### 3.3 Data Model The canonical twin object in `core/schemas.js` defines a structured twin profile for the wind turbine domain. The top-level fields are: - `twin_id`: UUID, generated at initialization. - `entity_type`: fixed string `"wind_turbine"`. - `profile`: asset metadata (manufacturer, model, rated power, hub height, rotor diameter, commissioning date, cut-in/rated/cut-out wind speeds). - `state`: the live SCADA state snapshot, partitioned into Environmental, Electrical, Mechanical, and Control subsystems. - `actuator`: operator command state (pitch command, yaw command, alarm state, latched fault list). - `predictions`: the latest inference bundle (power prediction, gearbox forecast, state label, state probabilities, anomaly score, fault hypothesis, routing path, explanation string). - `simulation`: the active branch name and summary statistics for all three branches. - `timestamps`: ISO 8601 `created_at` and `updated_at`. The SCADA state fields are derived from the Kelmarsh dataset schema [25]. The Greenbyte secondary SCADA system exports each 10-minute statistic as a quartet of suffixed columns (`_avg`, `_std`, `_min`, `_max`). Aperture internalizes the `_avg` channel as the canonical state value and exposes the `_std` channel through the feature builder's volatility computation. The full signal map is documented in `dataset_schema.md`. Key state fields and their Kelmarsh provenance: | State Field | Kelmarsh Column | Unit | Notes | |---|---|---|---| | `wind_speed_ms` | `Wind speed_avg` | m/s | Hub-height anemometer | | `wind_direction_deg` | `Wind direction_avg` | deg | Nacelle vane | | `ambient_temp_c` | `Nacelle ambient temperature_avg` | °C | Outdoor | | `power_kw` | `Power_avg` | kW | Active electrical power | | `rotor_rpm` | `Rotor speed_avg` | RPM | Low-speed shaft | | `generator_rpm` | `Generator speed_avg` | RPM | High-speed shaft | | `gearbox_oil_temp_c` | `Gearbox oil temperature_avg` | °C | Oil sump | | `generator_bearing_temp_c` | `Generator bearing temperature (DE)_avg` | °C | Drive-end bearing | | `pitch_angle_deg` | `Blade angle pitch A_avg` | deg | Blade A pitch | | `yaw_angle_deg` | `Nacelle position_avg` | deg | Absolute heading | | `vibration_proxy` | `Drive train acceleration_avg` | m/s² | Drivetrain vibration | The event schema wraps each SCADA sample in an envelope that carries `event_id`, `twin_id`, `source`, `event_type`, `payload`, `confidence`, and `ts` fields. The `confidence` field (0.0–1.0) is used by the state store's reducer to weight the incoming sample against the previous state value through an exponential smoothing operation: `state[k] = prev * (1 - alpha) + new * alpha`, where `alpha = confidence`. This mechanism allows low-confidence synthetic events (e.g., simulated data under fault conditions) to exert reduced influence on the canonical state. Derived metrics computed from raw signals include: tip-speed ratio `(π × D × RPM) / (60 × v)`, power coefficient \(C_P = P / (0.5 \rho \pi R^2 v^3)\), capacity factor (`P / P_rated`), and delta gearbox temperature (`T_gearbox - T_ambient`). These derived quantities are computed in the feature builder and in the evaluation pipeline but are not persisted in the canonical state object. ### 3.4 Machine Learning Model Specifications All four models are implemented in `ml/models.js` and composed in `ml/inference.js`. Each model is seeded with physics-derived priors at initialization, so the system produces meaningful predictions from the first SCADA sample without requiring an offline training phase. #### 3.4.1 Power-Curve Surrogate (Linear Regression) **Purpose**: Predict active power output given wind speed and ambient temperature. The residual between predicted and actual power is the primary signal for icing, blade degradation, and yaw misalignment detection. **Model class**: `LinearRegression` in `ml/models.js`. Closed-form multivariate least squares via the normal equations: \(\mathbf{w} = (\mathbf{X}^T \mathbf{X})^{-1} \mathbf{X}^T \mathbf{y}\), solved by Gaussian elimination with partial pivoting. No external library. **Input features**: \([v, v^2, v^3, T]\), where \(v\) is wind speed in m/s and \(T\) is ambient temperature in °C. The cubic polynomial expansion is motivated by the physical relationship \(P = \frac{1}{2} \rho \pi R^2 C_P v^3\) in the partial-load region below rated wind speed. The ambient temperature term captures the air density dependence: at fixed \(C_P\), power is proportional to air density, which decreases approximately 0.4% per °C rise at sea level. **Output**: Predicted power in kW, clamped to \([0, 1.05 \times P_\text{rated}]\). **Training procedure**: The model is seeded from a synthetic prior corpus generated by sampling the IEC 61400-12-compliant physics power curve at wind speeds 0–26 m/s (0.5 m/s steps) and temperatures −5, 5, 15, 25°C, with a small temperature coefficient applied. This produces 216 prior samples. When the evaluation pipeline runs, the model is re-fitted on the chronological training split of the Kelmarsh dataset (2016–2019, approximately 21,232 records after filtering). **Hyperparameters**: No regularization; the feature dimensionality is 4 and the training corpus is large relative to that dimensionality, so overfitting risk is low. Filtering removes records with `turbine_state_avg > 0` (curtailment), `wind_speed_avg` outside [3, 25] m/s, and NaN values. **Known limitation**: The linear model under-predicts by approximately 5% near the rated wind knee (10–13 m/s) because the true power curve is nonlinear in that region (see Section 7). This residual is visible in the `fig_power_curve.png` diagnostic plot and is an expected property of the polynomial surrogate rather than a data quality artifact. #### 3.4.2 Gearbox Temperature Forecaster (KNN Regression) **Purpose**: Predict gearbox oil temperature 10 minutes ahead given recent operating conditions. The forecast feeds the stress scenario branch and triggers WARN/ALARM conditions when projected temperature exceeds operator-configurable thresholds. **Model class**: `KNNRegressor` in `ml/models.js`, with \(k = 4\) and inverse-distance weighting: \(\hat{y} = \sum_i w_i y_i / \sum_i w_i\), where \(w_i = 1 / (d_i + \epsilon)\). **Input features**: \([\bar{P}, \dot{P}, \bar{\omega}, T_\text{amb}, \bar{T}_\text{gear}]\)—mean power, power slope, mean rotor RPM, ambient temperature, and mean gearbox temperature, all computed over the rolling feature window. This five-dimensional feature vector captures the dominant determinants of gearbox thermal state: mechanical load, rotational stress, ambient heat sink, and thermal inertia. **Output**: Predicted gearbox oil temperature in °C at the 10-minute horizon, adjusted by the recent power slope: `forecast = KNN_pred + 10 × slope × 0.1`. **Training procedure**: Seeded from a synthetic prior corpus of 336 samples spanning power 0–2050 kW (200 kW steps), rotor RPM {4, 8, 12, 16}, and ambient temperature {−5, 5, 15, 25}°C. The evaluation pipeline re-fits on the Kelmarsh training split. **Note**: The KNN forecaster uses a synthetic prior corpus in the live demo and does not learn online from the replay buffer. This is documented as a known limitation in Section 7. #### 3.4.3 Operational-State Classifier (Tree Rules) **Purpose**: Classify turbine operational state into one of five labels: `Running`, `DeRated`, `Faulted`, `Stopped`, `MaintenanceStop`. The classifier provides a human-readable routing path and drives the state probability bar display. **Model class**: `TurbineStateClassifier` in `ml/inference.js`, implementing depth-2 deterministic rules over canonical SCADA signals. The rule structure approximates the Optimal Classification Tree (OCT) concept from Bertsimas and Dunn [11], which formulates tree induction as a mixed-integer optimization problem to produce globally optimal interpretable classifiers. **Decision rules** (evaluated in priority order): 1. If `anomaly_score > 0.75`: classify `Faulted`. 2. If `op_state = MaintenanceStop`: classify `MaintenanceStop`. 3. If `wind_speed_ms > 25`: classify `Stopped` (cut-out exceedance). 4. If `wind_speed_ms < 3`: classify `Stopped` (below cut-in). 5. If `wind_speed_ms > 12` AND `pitch_angle_deg > 3°`: classify `Running` (above rated, pitching to feather). 6. If `rotor_rpm < 4` AND `wind_speed_ms > 5`: classify `DeRated` (mechanical underspeed). 7. If `power_kw < 0.3 × P_\text{expected}(v)` AND `wind_speed_ms > 5`: classify `DeRated` (power underperformance). 8. Otherwise: classify `Running`. **Output**: Label string, rule path array (for explainability display), and softmax-style state probability vector over all five classes. **Threshold justification**: The 0.75 anomaly threshold for fault classification was chosen by inspection of the gearbox overheat fault injection trace—the anomaly score crosses 0.75 approximately 12 samples after the gearbox temperature begins drifting, which is approximately 2 minutes of wall-clock time or 120 minutes of compressed SCADA time, consistent with the lead time documented by Tautz-Weinert and Watson [20]. #### 3.4.4 Multivariate Anomaly Scorer **Purpose**: Detect anomalous operating conditions by scoring the magnitude of residuals across five signal channels. Outputs a normalized anomaly score in \([0, 1]\) and a fault hypothesis label when the score exceeds 0.35. **Model class**: `AnomalyScorer` logic embedded in `ml/inference.js`. The approach is a multivariate residual z-score, normalized through a \(\tanh\) function. **Input residuals**: - `power`: \((P_\text{actual} - P_\text{predicted}) / (0.5 P_\text{rated} + 1)\) - `gearbox`: \((T_\text{gear} - \bar{T}_\text{gear}) / 10\) - `bearing`: \((T_\text{bearing} - \bar{T}_\text{bearing}) / 10\) - `pitch`: \((\theta_\text{actual} - \theta_\text{commanded}) / 15\) - `yaw`: \(\Delta\psi / 30\) (shortest angular distance from wind direction) **Scoring**: `anomaly = tanh(max(|residuals|) × 0.9)`. **Fault hypothesis**: When `anomaly > 0.35`, the dominant residual channel is identified and mapped to a fault label: `gearbox_overheat`, `generator_bearing_fault`, `pitch_actuator_stuck`, `yaw_misalignment`, `icing_or_degradation`, or `cut_out_exceedance`. **Theoretical basis**: The residual-based approach follows the normal-behaviour model paradigm validated by Tautz-Weinert and Watson [20] and Schlechtingen and Santos [39]. The tanh normalization produces a bounded, monotone score that is robust to outliers and has a natural interpretation: scores near 0 indicate normal operation, scores near 1 indicate a dominant anomalous residual of approximately 3σ magnitude. **Evaluation metrics**: AUROC and AUPRC are used to evaluate the anomaly scorer against the Kelmarsh events file, which provides partial fault labels. Davis and Goadrich establish that AUPRC is more informative than AUROC for imbalanced classification problems—relevant here because fault events represent fewer than 5% of SCADA records [37]. ### 3.5 Simulation Engine The simulation engine (`sim/engine.js`) implements physics-light forward simulation for three scenario branches: baseline, optimistic, and stress. Each branch is parameterized by a profile specifying wind drift rate, wind noise amplitude, gearbox temperature drift, and bearing temperature drift per step. **Branch profiles**: | Parameter | Baseline | Optimistic | Stress | |---|---|---|---| | `windDrift` (m/s/step) | 0.00 | 0.08 | 0.02 | | `windNoise` (m/s σ) | 0.40 | 0.30 | 0.50 | | `gearDrift` (°C/step) | 0.00 | −0.02 | 0.30 | | `bearDrift` (°C/step) | 0.00 | −0.01 | 0.15 | **Wind integration**: At each step, wind speed is updated as \(v_{t+1} = v_t + \delta_\text{drift} + \mathcal{N}(0, \sigma^2)\), clamped to \([0, 28]\) m/s. **Thermal drift**: Gearbox and bearing temperatures evolve as \(T_{t+1} = T_t + \delta_\text{drift} + \mathcal{N}(0, 0.01)\), clamped to \([20, 110]\) and \([20, 120]\) °C respectively. **Power response**: Power is computed from the physics curve at each step wind speed, with exponential smoothing: \(P_{t+1} = 0.6 P_t + 0.4 P_\text{curve}(v_{t+1}) + \mathcal{N}(0, 900)\). The lag coefficient (0.6/0.4) approximates the mechanical inertia of the rotor drivetrain. **Scenario selection**: The `ScenarioManager.select()` method chooses the active branch by a priority rule: if the stress branch produces peak gearbox temperature above 85°C, the stress branch is selected; if the optimistic branch produces mean power above 80% of rated, the optimistic branch is selected; otherwise the baseline is selected. **Branch outputs**: For each branch, the engine returns the 30-step trajectory, the final state, mean power (kW), peak gearbox temperature (°C), and peak bearing temperature (°C). These are displayed as summary cards in the dashboard and as sparklines in the prediction panel. **Fault injection modes**: Seven fault modes are implemented in `data/scada_stream.js` as stateful payload mutators: 1. `gearbox_overheat`: gearbox oil temperature drifts +0.5°C per sample; triggers `Faulted` state at 95°C. 2. `pitch_stuck`: pitch angle freezes at the value present when the fault is activated; power overshoots above rated wind by 8%. 3. `yaw_misalignment`: nacelle heading diverges from wind direction by 20–40° (random at injection); power reduced by \(\cos^3(\Delta\psi)\). 4. `generator_bearing_fault`: bearing temperature drifts +0.4°C per sample with increasing vibration proxy; triggers `Faulted` at 100°C. 5. `icing`: power underperforms predicted by 15–30% (random); ambient temperature forced below −1°C. 6. `cut_out`: wind speed instantaneously set to 26–29 m/s; blades feather to 90°; turbine stops. 7. `normal`: no fault active. ### 3.6 Visualization and HMI **Three.js 3D scene** (`scene/turbine_runtime.js`): Aperture renders a procedural wind turbine in a Three.js WebGL scene. The turbine geometry is constructed programmatically without any asset import: tower (tapered frustum), nacelle (box), hub (sphere), and three blades (flattened box, offset 120° apart). The scene includes a ground plane with grid, a sky gradient via hemisphere light, a wind direction arrow, a status light, and an alert tint overlay. The scene updates on every SCADA tick: rotor rotation is driven by `rotor_rpm`, blade pitch is set per `pitch_angle_deg`, yaw rotation follows `nacelle_direction_deg`. When `anomaly_score > 0.75`, the nacelle tints red and the status light pulses. **Dashboard** (`ui/dashboard.js`): The dashboard is divided into six live panels reflecting the SCADA subsystem partition: Environmental (wind speed, direction, ambient temperature), Electrical (power, grid voltage, frequency), Mechanical (RPM, gearbox temperature, bearing temperature, vibration), Control (pitch, yaw, operational state), Prediction (power sparkline with actual-vs-predicted overlay, gearbox forecast sparkline, anomaly gauge, state probability bars), and Scenario (three branch summary cards). **Annunciator** (`ops/annunciator.js`): The annunciator maintains a ring buffer of 200 operator-relevant events with severity (INFO, WARN, ALARM), code, message, source, and acknowledge state. Events are raised from three sources: the inference engine (fault hypotheses from `considerPrediction()`), the actuator (shutdown and alarm commands via `CH.LOG`), and operator interactions (fault injection selector, scenario buttons). Unacknowledged WARN and ALARM events are surfaced in the active-alarms panel. **Actuator command surface**: The operator can issue four command types: `setPitch(deg)` (clamped to −2° to 90°), `setYaw(deg)`, `triggerShutdown(reason)` (feathers blades to 90°, latches fault, sets `Stopped`), and `resetAlarm()` (clears alarm state and acknowledges all annunciator events). Automatic closed-loop yaw tracking is implemented by `trackWind()`, which applies a 0.3 proportional gain toward the current wind direction each tick—a simplified first-order yaw controller for demo realism. **Developer API**: A `window.twin` object exposes `getState()`, `getHistory()`, `push()`, `predict()`, `simulate()`, `stream`, `actuator`, `annunciator`, and `on()` for programmatic interaction from the browser console. --- ## 4. Implementation ### 4.1 Technology Stack and Architecture Rationale Aperture is implemented as a zero-dependency single-page web application. The technology choices are deliberate and defensible: **ES2020 native modules over a bundler framework**: The module graph is wired statically via `