OpenTurbine is a reading layer. It takes the operating history a fleet already produces from a historian or an export, and returns findings into the system where work is actually scheduled.
One required input and three that improve the analysis. None of the three blocks a first assessment.
A standard ten-minute SCADA export is sufficient to begin, delivered from a historian, an operator's own data platform, or a scheduled file transfer. Higher-resolution data improves fault detection where a fleet retains it, and is not required.
Work orders and service history give the models the ground truth for what was replaced and when. Without them, a repaired machine appears as an unexplained change in behavior and a corrected fault appears as an unexplained gain.
Met mast and lidar measurements, curtailment instructions, and a price basis allow a lost megawatt-hour to be valued at what it would actually have earned rather than at an assumed average.
Findings are available as a scheduled export, through an API, or as records raised in the maintenance management system, so a ranked list becomes scheduled work rather than another report somebody has to read first.
The required input is the ten-minute operating history the turbines already write. Everything else raises the precision of the analysis and none of it blocks a first assessment. That ordering is deliberate, because an integration program that has to complete before any finding is produced is a program that gets deferred to the next budget cycle.
The channels the models use are the ones common to essentially every modern turbine: active power, nacelle wind speed and direction, nacelle position, rotor speed, pitch angle, operating state, and whichever temperature channels the turbine model exposes. Where a fleet records vibration, or a dedicated condition monitoring system is installed, that data is read alongside the SCADA record and improves detection on the drivetrain in particular.
Data moves by whichever mechanism the operator's own policy allows: a scheduled export to object storage, a secure file transfer, or a read-only connection to the historian. A first assessment is usually a single historical export, because there is no benefit in building a live connection before either party knows what the analysis finds.
Operational data remains the operator's. It is not pooled with data from other operators and it is not used to train models that serve anyone else. That is stated in the commercial agreement before any export is transferred, and it is the term most technical evaluations raise first.
There is no hardware to fit, no change to the control system, and no interaction with the original equipment manufacturer's certification. The platform never writes to a turbine and issues no control instruction of any kind.
That boundary is a design constraint rather than a stage the product has not reached yet. Anything that touches the machine converts a data question into a warranty conversation, and a capability that requires an operator to renegotiate a service agreement before it can be evaluated is a capability that does not get evaluated.
The list is short on purpose. A long one is the reason most fleet analytics programs never produce a finding.
See how OpenTurbine can help your team understand performance, anticipate operational issues, and make better decisions across your wind assets.