When simulating controller designs, the plant model used is often developed using the K.I.S.S. approach – Keep It Simple Stupid. A model should capture relevant phenomenon with as low level of detail as possible. The general idea is to verify controller behaviour against the plant model and to do the final tuning against an actual prototype. One of the reasons for using this approach is of course that in many cases the development time and costs of a very detailed and complexed model is not motivated, when considering the effects of minor dynamics on the overall results. Another may be that the software used when creating the controller is not designed to handle certain complex modelling. Let’s have a look at how to handle this lack of complexity!
Take Simulink as an example. While excellent for controller design, it is not intended for multibody system simulations when including flex in components, for CFD analysis etc. On the other hand, MBS specific software is often not intended for controller design, providing only basic functionality. Wouldn’t it be nice to do all controller design in Simulink, do all MBS modelling in a designated software, and simulated the controller against the MBS plant model? Enter co-simulation.
Co-simulation is a widely used expression for combining different software in one simulation. For most of our cases, Simulink would be running the controller model, while the MBS software would be running the plant model. The co-simulation interface ascertains that each model is iterated in synchronization and that inputs/outputs to each model is updated correctly, thus allowing the models to communicate. The models need only a quick adaption to the interface, defining what signals to send/receive from the other software.
As an application example, let’s use a pilot project developed by Combine Lund in collaboration with Altair, who develops the HyperWorks suite (containing MotionSolve in particular) for MBS modelling. In this pilot, the model is that of a wind turbine in the event of a power failure causing a grid loss.
If grid loss occurs, the turbine will experience a sudden drop in generator torque. Left uncontrolled, this would cause an uncontrolled increase in rotor velocity, possibly resulting in a severe crash. As a countermeasure, a mechanical brake force is applied while also pitching the blades, in an effort to stop the turbine. This emergency stop behaviour can be seen in the figure below.
Now, considering the blades of the turbine as rigid, applying maximum brake force immediately may seem reasonable – the turbine stops as fast as possible. However, when defining the blades as flexible bodies, it can be seen that the blade deflections caused by rotor torque oscillations exert high stress and shear forces on the blades and may cause unnecessary wear and possible breakage.
A better control strategy would thus be to control the rotor speed to standstill while keeping the deflections of the blade to a minimum. Replacing the constant brake force with a proportional controller, using rotor speed as process variable, better performance can be obtained. In the picture below, 3 different gains for the P controller has been evaluated, resulting in very different brake characteristics. While the controller P3 has the longest brake time, oscillations have decrease significantly and this controller can thus be considered as the most appropriate control. Of course, a P controller is a very simple control strategy but the benefit with using Simulink for controller design is that the strategy could very easily be replaced with a more complex one, for example a state feedback controller.
Co-simulation is a powerful tool to simulate systems containing several modelling domains. In the case of the wind turbine, a better control strategy can significantly decrease stresses in the blades. This allows the mechanical engineer to optimize the design of the blades, which reduces material costs, energy consumption etc. At the same time, the control systems engineer can test the controller against a plant model that captures more dynamics than what is normally possible, a plant model that is often already developed by the mechanical engineer and needs only a quick adaption to the interface. Isn’t that a win-win situation?