Driven by the growth of the wind industry, they now collect billions of bits of data information for wind farm operators worldwide.
But with that comes new demands and challenges, and SCADA developers are in danger of becoming victims of their own success unless they meet these head on.
"The SCADA systems of yesterday were originally scoped to provide onsite information on a project-by-project basis, not allow for large portfolio reporting," explains David Barnes, chief operations officer of renewable energy firm Infigen Energy, US, which has an interest in 36 wind farms and 1.7GW of installed capacity around the world.
"The need for broader portfolio reporting, analysis, and real-time data exchange has changed the landscape dramatically."
This is driving the creation of systems that can provide all levels of data storage, transfer, editing and reporting.
The challenge facing today's SCADA manufacturers is how to refine their product so users can find the source of a problem with minimum fuss.
Twelve years ago SCADA systems were pretty basic, recording a restricted amount of data over a limited communications infrastructure — copper serial networks.
It was possible to send start/stop/reset commands to turbines from a central location. With a phone line onsite, users could remotely send turbine commands or retrieve data, albeit rather slowly, using a dial-up modem. That was it.
In those days, the application of SCADA was limited by two things: user requirements (dictated by the maturity of the market), and technology or cost. Computers were slow, memory limited, and networks were cumbersome and unreliable. Things soon changed.
Industry consultants started using SCADA data to determine how well a wind farm was operating, identifying problem areas and checking if the machines supplied by turbine manufacturers were meeting agreed performance levels.
Existing SCADA systems were perceived to be there primarily to meet the needs of the original equipment manufacturers, largely because the main project owner/operators at the time were often the manufacturers themselves.
Needs of other owner/operators were deemed of secondary importance until third-party SCADA systems began to emerge to meet their needs.
Some were built around standard SCADA toolboxes, others from the ground up with the specific needs of the industry in mind.
They met with some success and, with an increasing amount of project refinancing and buy-out activity, the demand for the due diligence-style analysis provided by consultants using SCADA data grew.
Manufacturer systems soon caught up with the third-party providers, and by the latter half of the past decade SCADA requirements had fundamentally changed.
"The requirements of the new SCADA systems are much more demanding and it is beneficial to the owner/operator to have instant access to all available data for decision making," says Barnes.
"There is also much more pressure to have this data available to a wider audience with much different needs, from management and operations to utility interface and control."
Today, SCADA systems record more data than ever, interact with more data sources, and are used by more people.
They record millions of bits of data signals sent out from wind farms and hundreds of alarm signals.
They may involve reporting, profiling, editing, condition monitoring, reactive power control, load reduction strategies, maintenance scheduling, forecasting, and more.
So the term "SCADA" is becoming a generic term for the growing collection of software and hardware that helps operate and manage a wind farm.
As Barnes points out: "Having a system that can embed all the different data feeds from the various equipment, or other data collection systems/devices, is increasingly critical to being able to make real-time decisions and provide more detailed reporting.
It is also critical that these new hybrid systems be easy to manipulate and virtually transparent, in order either to prove your reporting is correct and not incur large expenses or to modify as time goes forward."
The SCADA user interface is probably the primary way users interact with their assets. Even if a condition monitoring system (CMS) is fitted, checking oil or vibrations for anomalies that might indicate a fault, the SCADA interface can often access the CMS alert system, even if it is a different system, or manufacturer.
The problem, however, is if something goes wrong, such as the CMS report not being available or an energy forecast email not having been received, it can be seen as a SCADA problem.
The user will contact the SCADA support team rather than the CMS or forecaster support. For SCADA manufacturers, this is a problem borne of success; their systems now simply have to evolve even further to meet the new expectations placed on them.
Control the flow
The mass of data now available brings a fresh problem — data management. Too much information can be just as debilitating as too little and users now risk drowning in data, where before they were parched.
Today, SCADA's challenge is how to embed some "intelligence" so users can easily home in on the heart of a problem.
Turbine controllers make dozens of analogue signals and hundreds of alarm signals available for monitoring.
Look at the maths: 30 signals from 150 turbines over one year is 236 million ten-minute data points.
Across 15 wind farms that is 3.5 billion. For three years that is 10 billion.
Can that be forensically analysed? Well, not in any efficient manner. Even physically managing that amount of data is an IT nightmare.
Of course, even with such vast amounts of data, it is easy to create simple aggregation-style reports showing the turbines with poor efficiencies, or the components causing the most downtime.
But good reporting and analysis can do a lot more, such as constant monitoring of key performance indicators. Automatic warnings alert users when thresholds are exceeded so action can be taken.
This should not be done via daily or weekly reporting, which would generate more data and result in an overwhelmed asset manager and an underperforming site. Instead, systems should be using a second tier of alarm logic —reporting by exception.
Consider operational efficiency — a crucial, if subtle, measure. The longer poor efficiency goes unnoticed, the greater the cost. Many systems can be configured to calculate this every ten minutes, measure it every day, and only tell the user if a turbine drops behind the rest of the wind farm.
This does not tell you what the problem is (there is still a place for consultants) but it highlights a problem quickly, potentially saving a lot of of money.
Another big issue is centralising, normalising and analysing data across a portfolio.
Some will say this is not SCADA, but there are systems that offer a variety of implementations at a portfolio level, including full control of individual turbines and whole wind farms. They do everything a SCADA system does, and more.
SCADA systems are gradually becoming the data, processing and communications hub of wind assets.
The next generation — SCADA 2.0 if you like — will have to manage a different set of problems: huge amounts of data, with multiple formats, user types and communication channels.
The challenge will be to offer quick, flexible solutions that deliver the right information to the right people at the right time, thereby extracting the maximum value from the data they collect.
Barnes describes his wish list for next generation SCADA as: "Full enterprise data collection (historian, data warehousing, etc) with various real-time views tailored to the differing viewer.
This system needs to be able to pull together all possible data, be easy to work with and edit, and have the capability to provide custom reporting without a lot of effort or new code.
"It also needs to be built on a platform that can easily be upgraded as equipment becomes obsolete or improvements are developed," he adds.
The journey for SCADA is far from over, and I expect the next ten years will be just as interesting and challenging as the last.
Graham Gow is principle engineer, WindHelm Portfolio Manager, GL Garrad Hassan