Software testing on wind turbines involves far more than just software testing: around 164 subsystems, mechanical and electrical components as well as weather-dependent operating conditions have to be covered. Testing is carried out in layers: from hardware in the loop simulators and prototype test fields to field testing on real customer systems.
Key Takeaways
- Wind turbines consist of around 164 subsystems, all of which have to be implemented and integrated on the software side, which makes the testing effort comparable to that of a complex cyber-physical system such as a car.
- Weather conditions such as lightning strikes cannot be provoked in the laboratory, which is why field data from a large fleet of turbines is the only reliable basis for testing under real environmental conditions.
- Country-specific regulations enforce different software behavior: In Japan, a turbine must stop after every lightning strike, while in Germany this requirement does not apply.
- The complete control hardware of a turbine is replicated 1:1 at headquarters as a hardware in the loop system and runs automatically through test suites every night, because no simulator can replace safety-critical tests such as high-voltage tests.
- Increasing modularity, i.e. the goal of being able to upgrade individual components such as gearboxes or control units independently, is causing the number of variants and configurations to explode and overwhelming existing regression test strategies.
Testing wind turbines means securing a cyber-physical system under real weather conditions
In testing practice, a wind turbine is a cyber-physical system of similar complexity to a car. Mechanics, hardware and software interlock, and the test essentially follows the same principles as in other industries. What makes it special are a few sticking points that are almost impossible to control.
The biggest of these is the weather. Wind direction, wind strength, thunderstorms or overvoltage can neither be reliably simulated in the laboratory nor provoked on command. However, it is precisely these conditions that determine safety and electricity production. This is why the test uses a mixture of simulation, hardware in the loop and measurements on real turbines in the field.
Onshore testing takes priority over offshore. If something goes wrong at an offshore turbine, the downtime is high, the turbines are larger and the risk is correspondingly higher. Those who can, test onshore before going on the water.
How is the software of a wind turbine structured?
A wind turbine is built modularly, and this modularity extends from the mechanics to the software. Each submodule, such as the pitching system for the rotor blades, is considered a separate system and tested separately before being integrated into the overall system.
The control software itself is not broken down into separate programs. One control system controls all units of the turbine. It runs on duplicate control nodes, one at the bottom of the tower and one at the top of the nacelle, so that the modules communicate with each other directly. Internally, this software is divided into modules so that a scrum team can work together with the hardware and mechanics team on the requirements and implementation of a module.
Only the safety software runs separately from this. It has its own controller, but sits in the same control box. The turbine achieves a safety integrity level of SIL 2, not SIL 3 as in the rail industry, for example. The safety requirements are therefore high, but lower than in the rail sector.
Modularity reduces costs and multiplies complexity at the same time
Modularity is not an end in itself in the wind industry, but a prerequisite for reacting to weather conditions, customer requirements and regulations. If a completely new turbine had to be created for every requirement, this would simply not be feasible.
The diversity of variants and configurations is comparable to the automotive industry. Different turbine sizes are added: older, smaller turbines produce less, newer ones are larger and more powerful. For quality assurance and testing, this means a considerable amount of work simply due to the number of possible configurations.
The desired direction is towards even more modularity, such as performance steps in which only part of the turbine is improved instead of a completely new design. A new gearbox, an improvement in the tower or replaced control hardware can thus be upgraded individually. This step has not yet been completed; many projects are still completely new prototypes.
With modularity, however, comes a risk: the number of variants can explode. Regression testing and a certain coverage of existing variants already exist, but a more modularized world requires a different level of verification. Otherwise, every new combination brings with it new errors that can hardly be fully tested.
What is technically inside a wind turbine?
A wind turbine is much more than just a spinning rotor with a flashing light. It aligns itself with the wind direction so that the rotor is always facing the wind. The nacelle, the little house at the top of the tower, rotates continuously. The blades themselves can be adjusted according to wind strength and load, which also regulates electricity production.
The generator is located in the nacelle. There are various designs, such as direct drive or a mechanical gearbox. There is also the converter and the connections to the power plant, which feeds power into the grid for an entire wind farm.
Offshore turbines also have a large power backup system with many batteries. These turbines are difficult to maintain, and in Germany certain weather conditions prohibit access by helicopter at all. This means that an offshore turbine can be out of operation for long periods of time.
Then there are the sensors. A turbine not only measures wind, but also vibration, shock, temperature and much more. Smoke detection and fire suppression are also included. Around 164 subsystems are implemented in the current software, which clearly demonstrates the integration effort and error potential.
Newer offshore turbines are also connected to the internet, in some cases via Starlink. This brings additional complexity in terms of communication and monitoring.
How do you test what cannot be tested?
Conditions that cannot be created are tested using data from real turbines. A large fleet and contracts with partners provide access to operating data from almost all turbines. Errors and improvements can be derived from the real behavior and performance can be evaluated.
Regulations further exacerbate the problem because they differ from country to country. The flashing light must always be on in Germany, but not in Denmark. The lightning conductor system is subject to different requirements everywhere. In Japan, the turbine must stop in the event of a lightning strike, even if nothing has been damaged, but not in Germany.
Such requirements need special focus, and lightning strikes more frequently in Japan of all places. Local partners therefore provide a little more freedom to test the behavior on real turbines.
The evaluation of these data volumes has become a focus in its own right. A team of around 100 people works exclusively on data analytics: building data pipelines, automatically deploying algorithms, evaluating data and feeding findings back into development. Predictive maintenance and serviceability are directly linked to this. So far, only a fraction of the available data has been used.
Hardware in the loop is no substitute for testing on real hardware
The software is first verified on several levels in the simulator. A good hardware simulator reproduces the mechanics as well as weather conditions and outdoor sensors and is used by the software team on a daily basis. Because the hardware is there first in this industry and often determines the direction of the implementation, it is usually established before the software is seriously developed.
In addition to the pure simulator, there is also a hardware in the loop system. Here, the complete control hardware of the Nacelle is replicated one-to-one in the basement, at several locations. Automated tests are run at night, while the systems can be booked for your own tests during the day.
Some tests cannot be simulated. A high-voltage test, for example, must be passed on real hardware.
In the end someone needs to crash the Volvo. You don’t want to drive 100 cars into the wall, but in the end at least one car has to crash into the wall to pass the crash test. It’s similar with the high-voltage test: it can only be proven on real hardware.
Florian Wartenberg
The final step involves prototypes in the national test center in Denmark, for example in Østerild, where the major manufacturers have their turbines. Otherwise, the manufacturers hardly ever have their own turbines. All the turbines in the field belong to energy companies. Tests on their customer turbines are carried out on the basis of contracts in which the customers receive new software and optimizations more quickly in return, as well as compensation for possible failures.
Test automation runs normally, with a proprietary core
When it comes to test setup, the wind industry is closer to the standard of other industries than one might expect. The predominant language is C++, plus well-known frameworks such as Google Test. A normal CI/CD pipeline executes the tests and returns feedback.
The special feature is the main automation framework. It is developed internally, playstest together with the simulator and is based on XML scripting. Such proprietary, grown tools are difficult to replace as soon as there is a high dependency on automated tests.
The usual range of functional and non-functional testing is carried out, as well as performance, security and safety tests. Safety-critical tests such as overvoltage or high voltage belong in the hardware in the loop setup, because a simulator is not sufficient proof here.
Security is becoming a driver due to the Cyber Resilience Act
Security testing is currently having a major impact on work, driven by the Cyber Resilience Act. The next stage will not take effect until December 2027, but many customers are already demanding contractual compliance.
This is changing the security philosophy. In the past, it was enough to argue that you shielded yourself with a firewall and that everything internal was not critical. Today, defense in depth applies. This has resulted in considerable additional testing effort, both for our own protection and for contractual and regulatory compliance.
Software updates over the air are still in their infancy in the wind industry
Over-the-air updates are a relatively new topic in the wind industry, comparable to developments in the automotive industry. In the past, new software was only installed on cars in the workshop; today it comes automatically, just like on a cell phone.
Customers now expect the same with wind turbines: up-to-date software, as often as possible, over the air. If a service team had to go out for every update, it would be expensive, especially for offshore turbines. This results in new efforts to ensure that the entire update process runs as smoothly as possible and causes as few rollbacks and problems as possible.
This requirement meets a service life that is designed and sold for at least 30 years. Some turbines in the field have already been running for over 30 years. New turbines with heights of around 300 meters and outputs of around 20 megawatts shift the requirements once again, if only because of the strong vibrations that put a strain on the material.
Sales and development must work together to master the diversity of variants
The key task over the next few years will be to master the growing number of variants before it becomes uncontrollable. More modularity means more configuration options, and without suitable mechanisms, this diversity can no longer be verified in a meaningful way.
This requires better interaction between sales and development. If something is sold that has not been coordinated with R&D, configurations are created that no one has verified. The sales configurator has to precisely map what has been developed, sold and verified internally. Product teams across all industries are familiar with this problem: Marketing and sales are often ahead with features, and development must ensure that what has been promised can be implemented safely and tested.
