Why Time Delay Matters | Control Systems in Practice

Most, if not all of the dynamic systems you’ll encounter will have some amount of time delay inherent to it. And if you’re building a controller for that system, it’s going to have to account for that delay in some way. The delay might be so short that you can pretty much ignore it, or it might be long enough that it starts to degrade performance and even make the system unstable. So in this video, we’re going to cover time delays, where they comes from, and why they matter.  I’m Brian, and welcome to a MATLAB Tech Talk.

To begin, I want to quickly discuss some nomenclature because I’m going to be talking about two main types of delay, distorting and non-distorting delays, and I want to make sure we all have the same understanding as we go through this video. 

Let’s start with distorting delays. Signals are distorted when original shape is altered in some way.  In the case of delay, this happens when the time delay is different for the various frequencies that make up the signal.   For example, let’s say that a signal is made up of two distinct frequencies.  A rather low frequency at 1 rad/s that gets delayed by half of a second when it passes through some process. And a second higher frequency signal at 3 rad/s that is delayed by 1.5 seconds when it passes through the process.  Neither of these signal components are distorted, just delayed by different amounts.  However, when the combined signal passes through that process, it will have a different shape.  It’s been distorted.  

Rather than thinking about these delays in the time domain, since each frequency is delayed differently, it is helpful to think about them in the frequency domain.  How much each frequency is delayed through a process  is what we’re looking at in the phase portion of a Bode plot.  In this instance, we don’t usually talk about time delay, we talk about phase delay or phase lag for every frequency that makes up the signal.  What I’ve shown here is a process that has a higher phase delay for higher frequencies. We’ll talk a bit more about phase delay shortly, but for now I want to compare this to non-distorting delays.

Non-distorting time delays affect the entire signal equally, every frequency the same.  Therefore, the whole signal maintains the same shape and amplitude, but it’s just postponed it by some amount of time. Depending on the industry you’re in and the specifics of the system you’re talking about, you might refer to this as transport delay, or ideal delay, or latency, or unit delay.  But regardless of the name, the impact is the same: an action occurs and it takes some amount of time for the effects to take place.  There is a time interval between the stimulation and the response. 

Both of these types of delay exist in real, physical systems and they both can cause problems in your controller design.  This is because the controller has to use old information in order to  determine the current controller output or it has to predict into the future how its output will impact the system. This has the effect of lowering the sample time of your system and therefore, to counter it you have to lower the bandwidth, or speed, of the controller.  If you don’t lower the bandwidth, then the delay in the system could cause stability issues.  

You can see why by looking at the Bode plot of an arbitrary 2nd order system.  The crossover frequency is where the magnitude plot cross the 0 dB line.  And at that frequency you can see how much phase margin your system would have if you created a feedback loop around this 2nd order system.  In this case, we have some positive phase margin so our closed loop system would be stable.  

However, if we add more delay into our system, either with transport delay or delaying frequencies around the crossover frequency then the phase plot will move down in some way.  This erodes our phase margin and if we add too much delay could cause negative margin and an unstable system.  To counter that, we could lower the bandwidth of the controller by moving the crossover point to a lower frequency.  This would get our phase margin back.  But in doing so, we limited the speed of our system.  We slowed it down and made it less responsive.

We can understand how this happens with a simple thought exercise. Imagine driving a car that has a 5 second delay between moving the steering wheel and having the car respond.  If you’re driving on a long straight road, this might not have too much of an impact. However, when a turn comes up, then you may find yourself starting to turn the wheel and since nothing happens and the curve is still approaching you panic and turn the wheel even more.  By the time the car starts to respond you’ve turned the wheel much too far and even though you’ve brought the wheel back to a neutral position the car continues to turn sharply off the road. To counter that you start to turn the wheel desperately in the opposite direction to bring the car back on the road, but again with the delay you have the same problem and you end up wildly swerving back and forth. 

If delay in your system becomes a problem like this, then minimizing it at the source is almost always preferred over slowing down your system or trying to figure out some clever way for your controller to handle it. In other words, why not reduce that 5 second delay rather than require that the driver stay only on straight roads or drive really slowly. 

Once you know the source of the delay then you can trade the cost of trying to remove it versus just building around it.  In order to know how to remove the delays, we need to understand where they come from in a typical system. And to do that, we’ll talk about the main components in a feedback system: sensors, actuators, the controller, and the process itself. There are more delay sources than what I’m about to mention, but this will get you in the right mindset to think about the problem for your system.

To begin, let’s talk about unintentional delays.  These are delays that are a byproduct of the design and not something that was included on purpose. 

All real dynamic systems introduce phase delay. Or distort the signal by delaying some frequencies more than others. This is true whether it’s a mechanical or electrical system. At some level, moving mass or energy around is dependent on the frequency of the input and the material it’s moving through.  Even the stiffest mechanical components act like a spring when you start talking about input signals that approach the speed of sound through that material.

In addition to the phase delay inherent to the system, there are design components that might be added into the system for a necessary reason but that increase phase delay as a byproduct.  These are things like low pass filters to remove noise, anti-aliasing filters prior to digitizing an analog signal, and building integrators into your controller.   This means that all sensors, actuators, and processes have dynamics that create some amount of phase delay across the spectrum. And depending on your controller design, it can also add phase delay.

If this is the cause of your delay woes in your system, then it might be necessary to look into faster sensors and actuators that don’t have as much lag, or sensors that have less noise so you don’t have the phase lag penalty that comes along with low pass noise filters.

But again, phase delay isn’t the whole story, we also have to consider transport delays.

For example, imagine a control system that is trying to maintain a set temperature of an object by turning on and off a heater.  Ideally, when the controller senses that the temperature is too low, it turns on the heater and can observe immediately that the temperature is rising.  This, sadly is not the case because even in this simple system there are a number of sources of transport delays.

Let’s start between the actuator and the sensor. A time delay occurs when a sensor, like a temperature sensor, is isolated from the state it’s measuring.  There is a thermal path between the heater and the object and the sensor, therefore, won’t detect a change in temperature as soon as the heater turns on. The heat would take time to flow from the heater to the sensor. 

The temp sensor is measuring the analog temperature but somewhere along the line it has to sample it periodically to create a discrete measurement that can be used by a digital computer.  After a sample, the value is held constant until the next sample period.  This means that just before a new measurement, the system is using a value that is almost one sample time old. And if the sample rate of your sensor is too slow compared to the speed at which the measurement is changing this may be a significant source of transport delay. 

Now that we have this raw digital measurement, software processing also takes time.  In a lot of cases, the sample time of a digital system is determined based on how fast it can ingest measurements or other inputs, run all of the digital logic including the control logic, and then calculate the outputs. In some cases, however, the computer may pause processing if it can’t finish in one sample time and then continue during the next cycle. In this way, several sample periods may pass between receiving a measurement and processing that logic.

Another source of delay is intentional delays.  These are pauses that are designed into the system on purpose. One form of this is slack time, or a buffer that is added to the amount of time it is expected to take to complete a process.  For example, you may calculate that your sensor processing algorithm will take 30 ms to complete, therefore, you may give the process 50 ms, or 20 ms of slack time, to account for the possible random variations in processing time. Adding this 20 ms is probably preferred over occasionally having a process fail to complete within the deadline of a real time system.

Signals also take time to transmit between the sensors, computers, and actuators.  This might be the relatively low delay of electrons moving across a wire, but it could also be the longer latencies of network delay if your systems have to communicate across multiple distributed computers. 

Another intentional delay comes from the desire to synchronize or align certain signals.  This is helpful if you want your system to be deterministic or have predictable behavior. An example of this might be intentionally waiting until the next sample time for an actuator command to execute rather than executing it as soon as it’s available.   A command might not always be issued at the same time within a sample period due to fluctuations in processing time.  So rather than executing a command on an unknown time boundary, it may be preferred to wait until the start of the following sample time so you always know exactly when that command executes.

Even after the command is issued within the actuator, transport delays in the actuators means there is even more time before the system state actually starts changing, in our case the heat starts flowing.

All of these delays, transmission, synchronization, processing, energy and mass movements, sampling, slack time and more, when they are combined they create dead time between when a command is issued and when the controller processes the measured response. That’s the non-distorting transport delay part.  For our car example, we were claiming this process from steering wheel command to you recognizing the car is turning was 5 seconds and that may be too long to keep a fast driving car stable. Similarly, if the delay for this temperature controller is too long, we may find that this system goes unstable as well. So how can we find that out?

Well, let’s say you’re able to fit your real temperature management system to a first order plus dead time model, that’s the actuators, process, and sensors.  The dead time portion rolls up all of the non-distorting transport delays and the first order LTI model captures the distorting phase delays. This model is in series with the controller you design which has its own dynamics and transport delays and together they produce an open loop system model.  

At this point, you can use that model to analyze the impact all these delays would have on your closed loop system. And since there is the potential of longer delays in the system due to unforeseen causes, when we design close loop systems we maintain some amount of phase or time margin.  This is extra delay (either at a specific frequency or for the whole signal) that our system can absorb before it becomes unstable. 

For simple systems, we can use Bode plots to calculate phase margin and design a controller accordingly like I sort of hinted at earlier.  However, Bode plots don’t work for nonlinear system models or for linear system models with internal delay.  

Internal delay occurs with systems that have delay in an inner feedback loop.  Let’s look at this simple feedback system with delay in the forward path G(s). If you simplify the block diagram to create H(s) of the whole feedback system you see that the delay term is present in both the numerator and the denominator and you can’t factor it out to just a single dead time delay.  Now if we wrap an outer loop around it, H(s) is the open loop transfer function and this delay makes it difficult to analyze with the traditional control theory tools.

Now, in this particular case we could replace the transport delay with a high-order transfer function using the Pade Approximation technique.  In this way, our system would become a normal LTI transfer function and classical analysis techniques would work to find the phase margin or time margin for the system.  But I want to show you a way to estimate time margin for systems that are highly nonlinear.  Or another way of putting it, systems that can’t be approximated well by a linear model - even if you replace the delay terms with Pade Approximants. For these systems, we can rely on a model.

I’ve duplicated that system in Simulink where you can see there is 100 ms of delay in the inner loop. This particular system has a nice rise time and good steady state characteristics. And we can simulate this system, a simple way to measure the delay margin is to add a delay block into the model and just keep increasing the value until the system doesn’t have the performance you need.  Whatever delay you added is the margin in the system.  100 ms delay changes the response a little but it’s performance I can live with. Same with 300 ms delay.  However, at 400 ms of delay the behavior is worse than I would would want so I’ll say this system has 300 ms performance margin.  However, if I keep increasing the margin, I can find that right around 700 ms, the system becomes unstable.  So I have 650 ms or so stability margin.

If you have don’t have as much delay margin in your design as you would like, then you either design a slower controller, or start the process of investigating where this delay is coming from and attempting to remove it at the source.

If you’re not familiar with analyzing and designing time-delay system, MathWorks has a webinar that I’ve linked to in the description below.

If you don’t want to miss the next tech talk video, don’t forget to subscribe to this channel. Also, if you want to check out my channel, control system lectures, I cover more control theory topics there as well. Thanks for watching, I’ll see you next time.