Speed Controllers for E-motor and IC-engine Simulations

by Georg Kratochwill and Daniel Biro

Speed Controllers for E-motor and IC-engine Simulations

by Georg Kratochwill and Daniel Biro

Motivation

A speed controller controls – that is no surprise – the speed. In context of AVL EXCITE? M of course we think of rotational speed when we say speed. Therefore, our speed controller does its job by issuing a torque. But how does it decide which torque to prescribe to the controlled system, say a shaft? And, anyway, why do we even need a speed controller in EXCITE M, if we can simply adjust the rotational speed of a shaft by a predefined motion? These and some additional questions on speed controllers will be answered in the following lines, explaining how speed controllers can be used effectively to facilitate certain simulation tasks.

First things first: what?is?a speed controller and how does it work? The speed controller, we think of here, works in a closed loop, has two inputs and one output: one input is the reference speed, that is the speed a system should have, with other words, the?desired?speed. Its other input is the?measured?(or "real") speed, that is the speed the system actually has and is fed back by sensors (this is what closes the loop). Most of the time there will be a gap between desire and reality, that is an?error?, which is simply the difference between the desired and the actual speed. Based on this error an output is calculated, which is the input torque for the controlled system. In the simplest case this calculation is a mere multiplication of the error by a "proportional gain", therefore the name?P-controller?. Assume for example a simple P-controller with a gain of 0.1 Nm/(rad/s): in case the desired speed is 10 rad/s and the actual speed is only 5 rad/s, the speed controller will apply (10 - 5)*0.1 = 0.5 Nm on the controlled system that leads to an acceleration to finally reach the desired speed. If, on the other hand, the actual speed is too high, the P-controller would issue a braking torque. It is simple as that: a difference and a multiplication, describes the core functionality of the speed controller. The good thing is, it does not get much more complicated. The only thing missing is an element of calm. Since the P-controller is driven by the actual error only, it tends to be a little erratic sometimes, which can be smoothed out if it is accompanied by an?I-controller?. The "I" here stands for "integral", and this part of the controller acts, as the name suggests, on the?integral of the error. By this it is not only the actual error the controller is acting on, but there is also a sort of "memory" involved in the control action, which prevents overly "aggressive" countermeasures to the error, that could lead to instability. Together, the P- and the I-controller form a perfect team: the?PI-controller, which is the industries standard for speed control. Sometimes, PI-controllers are equipped with even another feature, the?D-controller?. This one bases its control action on the derivative of the error, and the overall topology is then called PID-controller. However, in case of the speed controller this part is usually not in place, since the signal it acts on – an acceleration – is a quite noisy one. Therefore, it potentially causes more harm than good.

Where can we use a speed control in our simulations and why should we do this? If the operation of a drivetrain at certain speed is of interest, of course it is possible to directly prescribe the speed of the system as a fixed boundary condition. In this case the dynamics of the system is forced to influence the torque only. Another approach is to prescribe a constant torque to the system. In this case, opposite to the first one, the dynamics can take place on the level of speed only. Most of the time, if for instance friction torques are not known exactly, it will be quite difficult to achieve a constant, not drifting speed, with this approach. Both of these two "extreme" methods (prescribing either speed or torque as a hard constraint) can be of course of value. Here a speed controller offers a third, more flexible option, that is potentially closer to real world conditions: both, the speed and the torque constraints are "soft" here. That means the dynamics will split up to both. Of course the way of this splitting up depends on the chosen gains: the proportional (P) and the integral (I) gain. A more strict control design with large gains will minimize the error in speed. Bringing this to the extreme, this results in a flat line in terms of speed, just like in the case of a predefined motion mentioned above. Consequently, the strict controller will push the dynamics of the system to the realm of torque. If, on the other hand, the gains are small, the dynamic influence is minimized and a constant torque will be provided as borderline case. The system dynamics, e.g. ripples in a stationary operation, will be visible in the speed signal only.

Finding the correct gains for the simulation task at hand might not always be an easy task. Besides the dynamic influence just mentioned, also the necessary simulation time (which should be minimized by fast system responses) and also stability issues have to be kept in mind: if the controller is too strict or too lazy it will lose track of the controlled system not being able to control it anymore. This tuning process is supported by default gains that are estimated based on a minimal knowledge of the controlled system and a basic description of the requested control characteristics. The rough model of the plant is given by its effective moment of inertia and rotational damping. The requested control characteristics is defined in terms of rise time and percentage overshoot. The rise time controls how fast the reaction is if there is a jump in speed. The lower the rise time, the more aggressively the controller will try to achieve its goal. The percentage overshoot on the other hand accounts for the damping of the control action by prescribing, how much the speed can overshoot the desired reference value. ?

General Concepts and Functionalities

The speed controller component of EXCITE M is implemented as a specialized Compiled Function with a special input dialog for a simple configuration of the various settings.

To address different use cases generically, there are three different basic types of speed controllers available. A continuous controller, a time discrete controller and an angle discrete controller. The continuous controller reacts, as its name suggests, continuously on the changing input signals and provides an updated output signal at each time step. With this instant reaction on changes of the dynamic system, the controller is able to regulate the system quite fast. However, it sometimes could happen that the controller tries to regulate certain dynamics of the system which should be preserved, like speed fluctuations due to engine cycles of an IC-engine. For these applications the discrete controllers are available. They provide as additional parameter a certain sampling period, over which the input signal is averaged to filter the mentioned fluctuations of the speed. An update of the output signal is then applied at the end of each sampling period. Due to this larger waiting period the new output signal could become larger. Therefore, to avoid too large influence in the system, an additional output smoothing option is available. With this option activated, the new output signal is not directly applied on the system in the next time step. Instead, a cubic spline is used to interpolate between the old and the new value over the next sampling period, giving a smooth transition from one control value to the next.

To avoid too high resulting moments on the body where the controller output is applied, a torque limit can be defined. If the limit is reached, the controller output is cut at that limit. An anti-windup functionality is implemented to prevent further summation of the integral error, which gives the controller the ability to react faster and reduce the output signal when the speed drops back below the target.

There are two different types of output signals available for the speed controller. On one hand the actual torque, which should be directly applied on a certain body and on the other hand a torque ratio, where the torque is normalized by the given torque limit and additionally limited by zero from below. The torque ratio can then be used as input to a torque table (we will see this in the second example below).

The controller gains as well as the initial state of the controller are automatically calculated by the given parameters described in the chapter before. However, in some cases these precalculated values could be inaccurate. For such cases it is also possible to manually enter improved values.

The implementation of the controller as Compiled Function component gives a good connectivity of the controller within the signal network of EXCITE M. Input signals of the controller can come from any component which provides a signal output, like Sensors, Table Functions, Compiled Functions or external interfaces. The same is valid for the controller output signal, which can be directly applied on a body with a Load Applicator or be post processed by some other component.

So much for the theory, let’s see how a speed controller can be integrated into an EXCITE M model. As described above, there are several options where the input signals for the controller can come from and where the output goes to. So, let’s take a look at the example shown in?Figure 1.

?

The?speed controller?input for the desired?target speed?is coming from a simple Table Function, which can define speed over time for some transient application. An example of such a transient speed profile, defined via the Table Function, is shown in?Figure 2. The?torque limit?is coming from a Compiled Function. Again, the limit can be provided depending on simulation time or some other data available in the Compiled Function. But it can also be a simple constant value, which can be parametrized as shown in?Figure 3, if we want to run multiple cases with different torque limits. The final input signal for the??actual speed?is coming from a Sensor component. The output of the controller, which is in this case the torque itself, is sent to a?Load Applicator?component, which then applies the torque on the desired body.

?

General Use Cases and Setup

The main use case for the speed controller is to control the speed of some component in the drive line of an e-motor or IC-engine. This can be done by controlling the moment output directly on the input side at the motor or by applying some counter torque on the output side of the system.

If the speed control should happen on the input side, the actual model setup depends on the type of engine (e-motor, IC-engine). The e-motors speed controller provides the desired torque for the current controller. In case of an IC-engine application, the speed controller provides the throttle demand for the cylinder pressure map. Especially for this application the angle discrete controller is useful because updates in the cylinder pressure can only happen at certain points (i.e. angular positions) during the engine cycle.

Independent of the engine type speed control on the output side can be done with the speed controller. Here the speed controller can be used to provide the whole counter torque on the output side of the drive line. This allows a less intrusive control compared to previous solutions, where a constant predefined motion was applied on the output side to achieve a simulation at a certain speed. To improve the performance of the controller, a constant break torque, derived from the input torque, the transmission ratio, and the moment of inertia of the system can be applied on the output side. This reduces the effort of the controller only to regulate the unknown friction torque of the system.

After these general descriptions of the speed controller, let us have a look at two actual examples to see how the controller is working.

Example 1: E-motor - Speed Control on Output Side

Model Setup

For this application we look at the speed controller configuration, which we already saw in the general chapter before, applied in an e-motor example (Figure 4). In addition to the speed controller acting on the output side – in this case the output shaft of the drive line – a constant break torque is applied. The target speed is also given as shown in?Figure 2.

?

Results

Figure 5?depicts the resulting torque on the output shaft, which is a combination of the constant break torque and the controller signal. We can clearly see some oscillations in the signal because the continuous controller is reacting on speed fluctuations coming from the motor in each time step. On the other hand, this fast reaction will lead to a better control of the whole system.

?

Looking further at the speed of the output shaft (Figure 6), we can see that the speed follows the desired profile quite well. But does the controller influence the dynamic system, especially in the quasi-stationary parts after around 3.0 seconds? Zooming in on the results at this stationary part of the profile shows that the oscillations coming from the e-motor are still visible as desired. Going a step further and performing an FFT on this part of the signal leaves us assured that the frequency content is not significantly manipulated by the controller. In?Figure 7??we can see that the amplitudes at the relevant frequencies are nearly the same between the speed controlled example and a reference calculation of a stationary example with a constant moment on the output side.

?

?

Example 2: IC-Engine - Speed Control On Input Side

Model Setup

As already mentioned before, the speed control on input side of an IC-engine, is done by regulating the cylinder pressure for each individual cylinder of the engine. In the figure below we can see a model containing 4 cylinders with the?speed controller?on the left hand side, again with?table and sensor input. But this time the output is applied as ratio in [0, 1] to the?cylinder load items?in the center of the figure. We can also see the additional?Static Break Torque?component, which applies the counter torque on the output side of the system.

?

Results

The simulation results for this model are shown in?Figure 9?and?Figure 10. We see that the speed of the output shaft follows the desired profile of the target speed. However the reaction of the system is much slower than for the e-motor example before, because a change in the control signal can only take full effect in the next ignition of each cylinder in the engine cycle. We can help the controller to faster regulate the system by also adjusting the break torque on the output side accordingly.

?

?

?

A Powerful Tool for Stabilizing the Dynamic System

The EXCITE M speed controller component is a powerful tool for stabilizing the dynamic system at constant speed operating points or for simulating various transient speed profiles. Fully integrated in the signal network of EXCITE M the speed controller can be applied in a wide range of applications providing a good alternative to the predefined motion approach for speed control.

As much as we love to nerd out about simulation and read lengthy articles about it, we have to cut it short at this point.

We want to thankGeorg Kratochwill and Daniel Biro for the insights and the impressive work that is performed day to day behind the scenes.

Real-world activities and their real-time limitations bring this Simulation Saturday to an end, but stay tuned for another one soon!

Cheers, Thomas and Michael

What’s next:

You tell us!

? Which simulation topic are you particularly interested?

? What features would you love to see?

? What do you love or hate most about the tool(s) you use?

We love to hear all of it in the comments and encourage you to:

? learn more on our product sites: AVL Advanced Simulation Technologies Tools

? try it: Rescale

? simulate for free via AVL University Partnership Program as a student and academic researcher.

? get in contact via [email protected] and [email protected]