Time Delays in IO

There are certain time delays inherent to all systems that must read and write to IO ports. This paper attempts to classify those delays and describe a method to compensate for them utilizing state and parameter estimators and optimal control designers.

A typical reactive control loop goes something like this:

for (;;) {
    Read_Inputs();
    Process_Inputs_To_Decide_Outputs();
    Write_Outputs();
}

There are intrinsic delays in each of these functions. In the function Read_Inputs, one must first request for the hardware to read the values. The delay between the request for the read operation and the hardware actually reading the values is called t_rr. Those values must then be transmitted back to the program, this time delay is called t_ra. The total time for the Read_Inputs function is then t_r=t_rr+t_ra.

The function Process_Inputs_To_Decide_Outputs has a constant delay of t_p.

Write_Outputs is similar to Read_Inputs. In that there is a transmission time to make the request to hardware, and there is the time required for hardware to acknowledge that it has acted. This total time is t_w=t_wr+t_wa.

How to Compensate

In our control architecture, there are two fundamental units responsible for calculating the reactive control signal: the state and parameter estimator (SPE), and the optimal control designer (OCD).

Given the outputs of the system, and a perfect discrete-time non-linear model of the system, the SPE is capable of calculating value of the states and parameters of the system based upon the previously estimated states and parameters (in addition to some statistics that it keeps on those states and parameters).

Because it relies on previous knowledge, the SPE is most easily formulated using a discrete-time model of the system being estimated. Continuous-time models, however, are much easier to formulate and verify. Because of this, a time integrator is used to convert from the continuous-time model to the discrete-time model. This integrator is able to perform this conversion for any time step; its accuracy, however, depends greatly on the magnitude of this time step (smaller time steps produce more accurate results).

This “laziness” of storing a continuous model and then converting it to a discrete model has some unforeseen advantages when faced with the problem of IO delay compensation.

In a typical real-time environment, the maximum IO delays are calculated and the system is driven at a fixed time step based upon those delays. In a system where no hard limit can be placed upon the IO delays, or when those delays have a large variance, a variable time step system is often employed.

Let us consider this variable time step system and its relationship to the SPE. We will attempt to define a means by which we can provide the SPE with enough information that it can create an accurate view of the world even in the face of read delays.

Compensations for the SPE

The SPE is able to take the current outputs of the system and determine the current states and parameters of that system based solely of the last estimated states and parameters and some statistics that is has accumulated over time. It can do this assuming that the time between these outputs being provided to it and the time when the last set of outputs were provided to it is equal to the time step of the discrete system. That is, assuming that the time step of the discrete system is Δt, and that outputs were provided at times t_k−1 and t_k (in that chronological order), then this relationship must hold for the SPE to operate correctly:

Δt=t_k−t_k−1

In the face of variable delay IO, the expression t_k−t_k−1 is variable. This means that a fixed time step discrete-time model of the system is inapplicable. Fortunately, we never had one to begin with!

Our goal, then, is to use the integrator to convert our continuous-time model to a discrete model using a time-step that reflects the actual timing of the output measurements. In this way, the SPE can be given a more accurate view of the world—one in which it can best predict the states of that world.

Figure 1 Control Sequence and associated timing.

Figure 1 depicts the control sequence and the associated timings. It is a bit misleading because, in reality, the read and write time delays are greater than the processing delay.

Actual sampling of the world occurs at time t₀+t_rr; however, the SPE is not executed until t₀+t_rr+t_ra+t_pe. Keeping in mind that we are continuously running this control loop, the last time that the SPE was run is equal to t₋₁+t_−1rr+t_−1ra+t_−1pe where t₋₁ is equal to the starting time of the last control loop.

If we care to keep the SPE in sync with reality, then we want to make sure that we use an integration step equal to (t₀+t_rr)−(t₋₁+t_−1rr), this is the time difference between measurements of the outputs of the system. In the case that the two read delays are equal, this difference in time simplifies to t₀−t₋₁. While we cannot say that the read delays are ever equal to each other, it is safe to say that in the aggregate, there will exist a mean read delay t_rr. The instantaneous values of t_rr will fall either above or below this mean read delay in a uniform manner. Therefore, in the aggregate, we can use the simplification for the difference in output measurement times of t₀−t₋₁. This is convenient since measuring the time t_rr is a very difficult task (as it requires clock synchronization between the sensors and the controller).

We have now solved one piece of the IO delay compensation puzzle: tracking the current world state. The next part of the puzzle is to compensate our control signal for the write delay.

Compensations for the OCD

The OCD is responsible for creating a control law in order to meet some performance criteria. Given a continuous non-linear mathematical model of the system presented in a state-dependent form, and given the current state of the system, the OCD is able to calculate the control signal that should be provided to the system in order to meet the performance criteria.

This works wonderfully if there is no delay between reading from sensors and controlling actuators. However, if there is a delay, then there could be problems.

Imagine an actuator that is attempting to seek to a certain position. Its goal is to reach 30°. It is currently located at 0° and moving at a rate of 10°/s. If the total control loop delay is 0.1 s, then we will have 30 samples in order to slow the actuator down. If we want to drive the actuator at full speed until we reach 25°, then we will have only 0.5 s (5 samples) to slow it down. This should be adequate (assuming that the actuator is capable of coming to a stop within 0.5 s).

Now consider the possibility that a write delay may take up to 0.3 s to be transmitted to the actuator. At 24°, the control system will attempt to keep the actuator going at full speed because, as far as it knows, it will be able to slow it down again (at 25°) when the control loop is run again. However, consider the possibility that the write delay now increases to 0.3 s. This means that the control loop will not be able to execute until the actuator is already at 27°. At this point, the actuator is moving at the full 10°/s while it is only 2° away from its target. This transient spike in delay time has put the actuator in danger of overshooting its goal.

Here, we have to decide how to control the actuator. There are essentially two choices that can be made:

We output the control value that is appropriate for 27° under the assumption that the write delay will settle back down to its nominal value of 0.1 s.

We can assume that this delay is not transient and compensate for it by calculating the appropriate control signal for events 0.3 s in the future.

Which of these is the correct choice? Unfortunately, either one is the correct choice—it is simply impossible to predict the future. Either the extended write delays will go back down or they will continue, we have no way of knowing.

Let us now consider what happens if we choose option 1 over option 2. The optimal controller will calculate an aggressive but valid output signal that keeps the actuator moving in the direction of the goal. If the extended write delay vanishes for the next few seconds, all is fine and the actuator meets its goal. However, if the extended delay continues, then the actuator could overshoot its goal (depending on how aggressive the controller is at 27°).

Consider what would happen if we chose option 2. At 27°, the controller would calculate a control signal for 30°. This control signal is of course going to be to stop the actuator. If the extended delay vanishes, then the system has undershot its goal (and the actuator’s inertia must be re-established). If the delay continues, then the actuator will come to a proper stop.

As we can see, depending on whether the delay is transient or not, either option 1 or option 2 is valid.

One unifying feature of both the options, however, is the fact that the two rely upon some estimate of how long it will take for a new control signal to reach the actuator. Their only difference lies in how often this estimate is updated. Is the estimate for this control cycle equal to the delay of the last control cycle (option 2) or is the estimate equal to the average of the last 10 cycles (option 1)? Obviously, the estimated delay is some low-pass filter applied to the past measured delays. The difference between option 1 and option 2 lies in the aggressiveness of that filter.

We know that we want the controller to predict the future—specifically, we want it to predict the state of affairs at the moment that the new control value will actually be applied to the system. Using our timing notation, the time at which the control is applied is:

t₀+t_rr+t_ra+t_pe+t_pd+t_pdf+t_wr

The last time in that expression, t_wr is important. We know the system state at the time t₀+t_rr. If we can calculate the value of t_ra+t_pe+t_pd+t_pdf+t_wr, then we can calculate the time difference between the known state of the system and the state of the system when the control signal will actually be applied. Calculating t_pe+t_pd+t_pdf is as simple as establishing a timer in the control code.

We have much more difficulty calculating t_ra and t_wr, again, because doing so would require synchronizing a clock between the controller and the sensors. Instead, we will simply estimate the values. If one assumes that transducers act with a time constant much less than t_r and t_w, then we can assume that these delays represent the transit time of data between the transducer and the controller. If we further assume that the network has the same condition during the times of t_rr to t_ra and t_wr to t_wa, then we can estimate

t_ra=t_r/2

t_wr=t_w/2

These assumptions are very convenient though probably a bit from the truth. They are, fortunately, a better alternative to assuming that there are no delays at all.

Once we know how much time will have passed betweenve passed since we observed the world anduming there are no delays at all.the transducer and the controller. If we furthe observing the world and controlling it, we can use an integrator to calculate (extrapolate) the future state, design a control law for this state, and enact that law.

Putting it All Together

Now that we have an understanding of how the control algorithm should act, let us attempt to solidify that knowledge into code. We will assume the existence of a few classes to assist our controller.

void Perform_Control(Model mdl)
{
    SPE spe(mdl);
    OCD ocd(mdl);
    Integrator intOCD(mdl);
    Discrete_Model dismdl(mdl);
    State sEstimate(mdl), sFuture(mdl), sOutput(mdl);
    Real rControl;
    Timer timer;
    Time tNow, tLast, dtRead, dtProcess, dtWrite, dtFuture;

    while (true) {
        tNow = timer.Begin();
        sOutput = Sensors.Read();
        dtRead = timer.End();

        timer.Begin();
        dismdl.FromContinuous(tNow – tLast, sEstimate, mdl);
        tLast = tNow;
        sEstimate = spe.Estimate(sOutput, dismdl);
        dtFuture = dtRead/2 + dtProcess + dtWrite/2;
        sFuture = intOCD.Step(dtFuture, sEstimate, mdl);
        rControl = ocd.Design(sFuture);
        dtProcess = timer.End();

        timer.Begin();
        Actuators.Write(rControl);
        dtWrite = timer.End();
    }
}

Conclusion

In this paper, a simple methodology has been developed to create a reliable control system that is able to operate reliably in the face of variable delays between transducers and the control algorithms. A key factor in this methodology has been the use of a continuous-time non-linear model of the system that can be manipulated to account for the variable delays.