On leaky integration in digital control system simulations

[Abbott]

[From Bruce Abbott (2016.11.11.1030 EST)]

In the July 1979 issue of Byte magazine, Bill Powers continued his series (introduced in the June issue) on control systems, which included a set of demonstrations written in BASIC. The July installment presented the code that simulates a standard PCT-style control system. Much of the code is devoted to I/O, which involved keyboard input of parameter and variable values and the display of results on a system capable only of displaying ASCII characters. This is now outdated, but I found the code that runs the actual simulation interesting enough to deserve a brief mention here.

The interesting part for me was Bill’s use of a leaky integrator. Typically the demos we use today include a leaky integrator in the output function, where it is used to prevent an artifact that arises when simulating a continuous system with variables that change one step at a time with each iteration of the control loop. (It is also used, with proper adjustment of the slowing factor, to match the simulation results to a participant’s performance, as in the TrackAnalyze simulation.) The leaky integrator in the output prevents the output from changing its full computed amount in one step. For example, the current value of the error signal might call for an output that fully corrects the error in the same step in which the error arose, as if the correction could happen instantaneously. Allowing the digital simulation to do this leads to unrealistic behavior since real physical systems require at least some minimum amount of time to react to changes. Adding a leaky integrator to the output corrects this problem. Instead of allowing the output to change instantly to the value that would fully correct the error in zero time, the leaky integrator allows only a portion of that full correction to develop on each iteration of the loop. For example, if the slowing factor were 0.5, then the output would change only half-way toward its final value on each iteration. Each succeeding iteration would cut the remaining difference in half, thus producing a negative exponential approach toward the final value.

So what is interesting about Bill’s use of a leaky integrator in his Byte simulation? It’s that he included one in both the output function and the input function. By changing the slowing factors of each, one could see the effect of having either the input, the output, both, or neither making use of leaky integration during the simulation. Setting a slowing factor to 1.0 eliminates leaky integration: the output changes its full value in the same iteration of the loop in which the error changed. Set both slowing factors to 1.0 and the simulation fails. Set the slowing factors of either or both to some fraction produces stable behavior that simulates the continuous system.

I like this and thought it worth pointing out, because it would be easy to conclude, incorrectly, from our typical PCT demos that the leaky integrator must appear in the output function. In fact it can go anywhere in the loop – even in the environment function if integration naturally takes place there. For the simulation to work properly, there only needs to be one integration in the loop, and it doesn’t have to be leaky – as is the case in integral control systems. There can be more than one; however each integration will contribute additional lag in the system, and too much lag leads to instability.

Bruce

[MartinT]

[From Bruce Abbott (2016.11.11.1030 EST)]

In the July 1979 issue of Byte
magazine, Bill Powers continued his series (introduced in the
June issue) on control systems, which included a set of
demonstrations written in BASIC. The July installment
presented the code that simulates a standard PCT-style control
system. Much of the code is devoted to I/O, which involved
keyboard input of parameter and variable values and the
display of results on a system capable only of displaying
ASCII characters. This is now outdated, but I found the code
that runs the actual simulation interesting enough to deserve
a brief mention here.

      The interesting part for me was Bill’s use

of a leaky integrator. Typically the demos we use today
include a leaky integrator in the output function, where it is
used to prevent an artifact that arises when simulating a
continuous system with variables that change one step at a
time with each iteration of the control loop. (It is also
used, with proper adjustment of the slowing factor, to match
the simulation results to a participant’s performance, as in
the TrackAnalyze simulation.) The leaky integrator in the
output prevents the output from changing its full computed
amount in one step. For example, the current value of the
error signal might call for an output that fully corrects the
error in the same step in which the error arose, as if
the correction could happen instantaneously. Allowing the
digital simulation to do this leads to unrealistic behavior
since real physical systems require at least some minimum
amount of time to react to changes. Adding a leaky integrator
to the output corrects this problem. Instead of allowing the
output to change instantly to the value that would fully
correct the error in zero time, the leaky integrator allows
only a portion of that full correction to develop on each
iteration of the loop. For example, if the slowing factor
were 0.5, then the output would change only half-way toward
its final value on each iteration. Each succeeding iteration
would cut the remaining difference in half, thus producing a
negative exponential approach toward the final value.

      So what is interesting about Bill’s use of

a leaky integrator in his Byte simulation? It’s that
he included one in both the output function and
the input function. By changing the slowing factors of each,
one could see the effect of having either the input, the
output, both, or neither making use of leaky integration
during the simulation. Setting a slowing factor to 1.0
eliminates leaky integration: the output changes its full
value in the same iteration of the loop in which the error
changed. Set both slowing factors to 1.0 and the simulation
fails. Set the slowing factors of either or both to some
fraction produces stable behavior that simulates the
continuous system.

      I like this and thought it worth pointing

out, because it would be easy to conclude, incorrectly, from
our typical PCT demos that the leaky integrator must appear in
the output function. In fact it can go anywhere in the loop –
even in the environment function if integration naturally
takes place there. For the simulation to work properly, there
only needs to be one integration in the loop, and it doesn’t
have to be leaky – as is the case in integral control
systems. There can be more than one; however each integration
will contribute additional lag in the system, and too much lag
leads to instability.

Bruce

[Abbott]

[From Bruce Abbott (2016.11.11.1500 EST)}

Martin Taylor 2016.11.11.10.36 –

[From Bruce Abbott (2016.11.11.1030 EST)]

In the July 1979 issue of Byte magazine, Bill Powers continued his series (introduced in the June issue) on control systems, which included a set of demonstrations written in BASIC. The July installment presented the code that simulates a standard PCT-style control system. Much of the code is devoted to I/O, which involved keyboard input of parameter and variable values and the display of results on a system capable only of displaying ASCII characters. This is now outdated, but I found the code that runs the actual simulation interesting enough to deserve a brief mention here.

The interesting part for me was Bill’s use of a leaky integrator. Typically the demos we use today include a leaky integrator in the output function, where it is used to prevent an artifact that arises when simulating a continuous system with variables that change one step at a time with each iteration of the control loop. (It is also used, with proper adjustment of the slowing factor, to match the simulation results to a participant’s performance, as in the TrackAnalyze simulation.) The leaky integrator in the output prevents the output from changing its full computed amount in one step. For example, the current value of the error signal might call for an output that fully corrects the error in the same step in which the error arose, as if the correction could happen instantaneously. Allowing the digital simulation to do this leads to unrealistic behavior since real physical systems require at least some minimum amount of time to react to changes. Adding a leaky integrator to the output corrects this problem. Instead of allowing the output to change instantly to the value that would fully correct the error in zero time, the leaky integrator allows only a portion of that full correction to develop on each iteration of the loop. For example, if the slowing factor were 0.5, then the output would change only half-way toward its final value on each iteration. Each succeeding iteration would cut the remaining difference in half, thus producing a negative exponential approach toward the final value.

So what is interesting about Bill’s use of a leaky integrator in his Byte simulation? It’s that he included one in both the output function and the input function. By changing the slowing factors of each, one could see the effect of having either the input, the output, both, or neither making use of leaky integration during the simulation. Setting a slowing factor to 1.0 eliminates leaky integration: the output changes its full value in the same iteration of the loop in which the error changed. Set both slowing factors to 1.0 and the simulation fails. Set the slowing factors of either or both to some fraction produces stable behavior that simulates the continuous system.

I like this and thought it worth pointing out, because it would be easy to conclude, incorrectly, from our typical PCT demos that the leaky integrator must appear in the output function. In fact it can go anywhere in the loop – even in the environment function if integration naturally takes place there. For the simulation to work properly, there only needs to be one integration in the loop, and it doesn’t have to be leaky – as is the case in integral control systems. There can be more than one; however each integration will contribute additional lag in the system, and too much lag leads to instability.

Bruce

MT: Bruce states Bill’s reason for what he called the “slowing factor”, as being to prevent the specific kind of simulation loop instability that occurs without some smearing of the effect of an abrupt change that is an inevitable artifact of a digital simulation of a continuous process. But there is a stronger reason that has nothing to do with the problem of simulation.

MT: A pure integrator simply adds up all its inputs from the time it was first switched on to produce the resulting output. In a sampled system this means that a sample taken ten years ago is as important as the most recent one, which isn’t really what you want. The most recent input to the Output Function is a consequence of the most recent value of the perception, and you would expect that to be the most important. What happened to the perceptual value last year doesn’t matter now in a loop with a loop transport lag measured in milliseconds to minutes. The leak diminishes the effect of each successive sample as it recedes into the past.

MT: The leak as “slowing factor” is important in avoiding an artifact of digital simulation, just as Bruce reminds us. But to treat it only as a means of faking out the simulation process is, to me, to short-change its value in the continuous process being simulated. That’s why I personally always refer to it as a “leak rate” rather than as a “slowing factor”. A “leak rate” is a property of the loop, rather than a property of the simulation.

MT: By the way, but also important, a pure integrator produces a -90 degree phase shift at all frequencies. A transport of lag L seconds produces a phase shift -Lf cycles or -360*Lf degrees for a signal of frequency f. If you sum these phase shifts, at some frequency for which Lf = 1/4 you get a total of -180 degrees phase shift. Standard control loops invert the signal at the comparator to make the loop gain negative. But if there’s a ±180 degree phase shift at some frequency, that inversion makes the loop gain positive, and if it is over 1.0, that frequency is amplified without limit (or until it reaches some physical limit in a real system). Adding a leak to the integrator reduces the phase shift so that it approaches zero at low enough frequencies. This “loudspeaker-squeal” problem won’t occur at those frequencies no matter how high the loop gain. This has nothing to do with simulation. It happens in the real system being simulated.

BA: Thanks, Martin! Useful information!

Bruce