Every wind farm already has SCADA — the turbine OEM ships one with the machines. So why do operators keep shopping for another? Because the OEM system belongs to the turbine vendor's world: one portal per manufacturer, tags chosen by the OEM, and data that lives on their terms. The system you actually buy is the plant-level supervisory layer — the one that watches every turbine, the substation, and the met masts as a single operation, and calls your phone when something breaks at 3 a.m. This guide explains how the layers fit together, how turbine data actually gets out (IEC 61400-25 in theory, Modbus and OPC UA in practice), what to track, and how to choose in 2026.
Turbine OEM SCADA is the vendor-supplied system that controls and protects each machine — pitch, yaw, converter control, and the turbine safety chain — and it arrives with the turbines whether you want it or not. Plant-level (supervisory) SCADA is the layer the operator chooses independently: it aggregates every turbine, the collector substation, met masts, and the grid connection point into one operational picture with alarming, trending, and reporting.
The two layers exist for different masters. The OEM layer exists so the turbine manufacturer can run, protect, and service its machines — and, during the warranty and full-service period, so the OEM can meet its availability guarantee. The supervisory layer exists so you can run the plant: one alarm philosophy across the whole site, one historian that you own, one place where production, downtime, and grid events line up on the same timeline.
Three situations make the supervisory layer non-negotiable:
IEC 61400-25 is the communications standard written specifically for wind power plants. It extends the IEC 61850 information-modeling approach from substations to turbines, defining a common vocabulary for wind data — rotor speed, pitch angle, nacelle direction, production counters, status and fault codes — so that any compliant client can read any compliant turbine the same way.
That is the theory, and it is worth knowing because RFPs and grid operators reference it. The field reality in 2026 is messier: OEM adoption is uneven, native 61400-25 interfaces are far from universal, and much of the data that actually leaves turbine controllers travels over OPC UA or OPC DA (typically exposed by the OEM SCADA server), Modbus TCP (common on turbine and park controllers), or IEC 60870-5-104 (common at the grid interface). The practical buying requirement is therefore protocol breadth on the workhorse protocols, with 61400-25 fluency treated as a plus rather than a gate. If a vendor's entire wind story is "we support the standard," ask them to name the protocol they will actually poll on your specific turbines.
There are three well-trodden paths from turbine to supervisory platform, and most wind farms end up using more than one:
Most OEM SCADA servers expose an OPC UA (or legacy OPC DA) interface precisely so third-party systems can subscribe to turbine data. This is the cleanest path — the OEM controls what is published, you poll it read-only, and nothing touches control logic. Our MQTT vs OPC UA guide covers how these protocols behave over real networks.
Many turbine controllers and virtually all park controllers speak Modbus TCP, publishing a register map of live values. It is the least glamorous protocol in industrial automation and still the most universal — if you can get the register map from the OEM, any platform with a solid Modbus driver can read the machine. (New to Modbus? Start with our plain-English Modbus guide.)
The collector substation and grid connection speak the utility dialects: DNP3 in North America, IEC 60870-5-104 widely elsewhere and at many US grid interfaces. Breaker status, transformer alarms, and the interconnect meter belong on the same screens as the turbines.
This is where Merobix's positioning is straightforward and honest: it is a general-purpose supervisory platform, not a wind-specialist package — and its 20 protocol drivers across 7 families (Modbus TCP/RTU, OPC UA and OPC DA, DNP3, IEC 60870-5-104, MQTT Sparkplug B, EtherNet/IP, Siemens S7, and more) are exactly the paths described above. If your turbine controller, park controller, or OEM SCADA server exposes Modbus or OPC UA — and most do — the driver can poll it. The full driver list is on the features page. The caveats worth checking before you buy any platform are contractual, not technical: confirm your turbine service agreement's data-access terms and get the tag list from the OEM in writing.
Wind farm economics run on three families of numbers, and all three depend on raw data landing in a historian you own:
Time-based availability (was the turbine able to run?) and energy-based availability (how much production did downtime actually cost?) are the currency of OEM warranty claims and investor reporting. Both require a clean, timestamped record of turbine states and fault codes — independent of the party whose performance is being measured.
When the grid operator instructs the site to reduce output, that lost production is not the turbines' fault — and depending on your offtake agreement, it may be compensable. Tracking curtailment means logging grid instructions and setpoints alongside turbine output and wind conditions, so curtailed hours can be separated from fault downtime and low-wind hours after the fact. Operators that cannot make this distinction leave money in the dispute pile.
Met-mast wind speed against actual output, compared to the warranted power curve, is the earliest warning of blade degradation, pitch faults, and anemometer drift. None of this requires wind-specific software magic — it requires a historian that captures everything at honest resolution and a reporting engine that lets you line the series up. What an outage-free, well-instrumented year is worth is exactly what our ROI calculator is for.
Wind farms are built where the wind is, which is rarely where the people are. Sites are unmanned or lightly staffed, technicians cover territories measured in hours of driving, and backhaul is often cellular or otherwise bandwidth-constrained. That shapes the supervisory layer three ways:
Portfolios rarely stop at one site, and the supervisory layer should not either — see our guide to SCADA for multi-site operations for how the rollout math changes at fleet scale.
No single vendor is best, because a wind farm runs on three distinct layers and no one supplies all three well. The turbine OEMs — Vestas, Siemens Gamesa, GE Vernova, Nordex — are the only realistic source for the turbine-control layer; the genuine competition is above it, where operators choose between wind-specialist energy-management packages, general-purpose SCADA platforms such as Ignition or AVEVA, and managed platforms such as Merobix.
| Layer | What It Does | Who Provides It | Buying Note |
|---|---|---|---|
| Turbine control (OEM SCADA) | Runs and protects each machine: pitch, yaw, converter, safety chain | Turbine OEM (Vestas, Siemens Gamesa, GE Vernova, Nordex) | Comes with the turbines; negotiate data access, not the software |
| Power plant controller (PPC) | Closed-loop active/reactive power control at the grid connection per grid code | Specialist PPC vendors and OEMs; certified against the grid code | A certified control system — buy it as one, separately |
| Supervisory / monitoring layer | Aggregates turbines, substation, met masts; alarming, historian, reporting | General SCADA platforms (Ignition, AVEVA), wind-specialist EMS packages, managed platforms (Merobix) | The layer you actually shop for — this guide's subject |
Wind-specialist EMS packages bundle pre-built wind analytics — power-curve modules, availability calculators, forecast integration — and can be excellent for large IPPs with dedicated performance teams. The trade-offs are cost, integrator-led deployments, and another vendor relationship to maintain. General-purpose platforms like Ignition and AVEVA can absolutely be built into wind supervisory systems; plan for a system-integrator project and self-hosted servers (see our Merobix vs Ignition comparison for how the models differ).
Merobix plays the supervisory and monitoring role, and we will be precise about what that means. It is not a wind-specialist package: there are no turbine control functions, no PPC, and no pre-built wind analytics modules. What it brings is the layer described throughout this guide, delivered without an infrastructure project: the 20 protocol drivers to reach turbine controllers, OEM OPC servers, and substation gear; alarms on your phone in under 30 seconds; a historian and reporting engine for availability and curtailment records you own; and a choice of managed cloud (live in 3–5 days, 99.9% SLA, zero servers at the site) or on-premise on your servers or VMs, including fully air-gapped, with full data residency. The Enterprise plan adds hot standby redundancy, historian federation across sites, and integrations with the systems wind operators already run — SAP, Maximo, ServiceNow, PagerDuty, Kafka, Tableau, AWS IoT and Azure IoT. Plans are flat and custom-quoted; the matrix is at services & plans, and the broader case is on why Merobix.
For monitoring remote, dispersed, lightly staffed sites, cloud is the natural fit: no servers in a container at the base of a turbine, access from anywhere, and uptime that is the vendor's contractual problem rather than your technician's. On-premise remains the right call when grid-code obligations, NERC CIP scoping decisions, or company policy require the data path to stay on infrastructure you control — and in that case demand hot standby redundancy, because an unmanned site will not notice a dead server until the phone stops ringing. The turbine-control layer stays local to the site in either model. The full decision framework is in our cloud vs on-premise SCADA comparison and the redundancy mechanics in the high availability guide; Merobix ships the same platform both ways.
The one-turbine test: Before signing with any supervisory vendor, run a pilot against a single turbine or the park controller. Get the register map or OPC tag list from the OEM, have the vendor poll live data during a guided demo, trip a test alarm, and time how long it takes to reach a phone. An afternoon of pilot beats a quarter of proposals — and it surfaces the OEM data-access conversation while you still have negotiating leverage.
There is no single best answer — it depends on which layer you are buying. Turbine OEMs such as Vestas, Siemens Gamesa, GE Vernova, and Nordex supply the turbine-level SCADA that ships with the machines, and that layer is effectively non-optional. The real buying decision is the plant-level supervisory layer above it, where the strongest choice is a vendor-neutral platform that can read every OEM's turbines plus the substation and met masts through standard protocols. Merobix fits that role with 20 protocol drivers including Modbus TCP, OPC UA, DNP3, and IEC 60870-5-104, SMS and email alarms delivered in under 30 seconds, and a choice of managed cloud hosting or on-premise deployment.
Turbine SCADA is the OEM-supplied control system that runs each machine — pitch, yaw, converter control, and turbine-level protection — and it stays with the turbine vendor. Wind farm SCADA, also called plant-level or supervisory SCADA, sits above it, aggregating data from every turbine, the substation, met masts, and the grid connection point into one operational picture with alarming, trending, and reporting. Most operating wind farms need both: the OEM layer to run the machines and an independent supervisory layer the operator actually owns.
Yes, in most cases. The majority of turbine controllers and OEM SCADA servers expose data through standard industrial protocols — most commonly OPC UA or OPC DA on the OEM SCADA server, and Modbus TCP directly on many turbine and park controllers. A third-party platform with drivers for those protocols, such as Merobix, can poll that data without touching the OEM control logic. The practical caveats are contractual, not technical: check your turbine service agreement for data-access terms, and confirm with the OEM which tags are exposed and at what rate.
IEC 61400-25 is the international standard for communications in wind power plants — it defines a common information model for turbine data (rotor speed, pitch angle, production, status codes) so different vendors' systems can exchange it consistently. It matters as context: OEM adoption is uneven, and in practice much of the data leaving turbine controllers still travels over OPC UA, Modbus TCP, or IEC 60870-5-104 rather than a native 61400-25 interface. When buying a supervisory platform, the practical requirement is broad support for those workhorse protocols, with 61400-25 awareness as a plus rather than a gate.
For most operators the supervisory layer works well in the cloud: wind farms are remote, dispersed, and lightly staffed, which is exactly the profile cloud SCADA serves best — no site servers to maintain, access from anywhere, and managed uptime (Merobix cloud carries a 99.9% SLA and typically goes live in 3 to 5 days). On-premise remains the right call when grid codes, NERC CIP scoping decisions, or company policy require data to stay on infrastructure you control; Merobix deploys the same platform on customer servers or VMs, including fully air-gapped. The turbine control layer itself always stays local to the site regardless.
20 protocol drivers, alarms on your phone in under 30 seconds, cloud or on-premise — flat, custom-quoted plans with no per-tag or per-client fees.