The best time to design a control system by trial-and-error is when the system will be simple, “just like the last one,” or when there is no time for a full development cycle. The obvious advantage to the approach is a relatively small investment needed for up-front planning. But after the planning comes round after round of “build” and “test.” And should the unexpected happen, the iterations can seem endless, dooming the project to a lack of progress or funding.

Development projects typically go out of control either from management underestimating the complexity of what's involved or when unexpected obstacles crop up. This is where the disciplined approach, with a carefully planned front-end, actually reduces deployment time.

Developing a control system depends on a good model of the process followed by, or in parallel with, a controller algorithm in graphically oriented, interpretive software, such as Matlab. The algorithm is then tested against the model and iterated upon as necessary before applying it to the physical process and committing to controller hardware.

System and controller

Designers must understand the system being controlled before they can develop a controller. To do so, they create a reliable model independent of a physical controller. A great deal of complexity may reside within the simple blocks that connect controller and system. For instance, a system may contain a collection of subsystems and their controllers.

A useful model needs physical system-specific data. Relying on theoretical data at this stage often leads to mischaracterizing the system and defeats the control-development process. A great contributor to cost and schedule overruns in any development lies in underestimating the complexity of the system being modeled. You've underestimated a system's complexity if you have:

1. Multiple interactive inputs or outputs. Take the water supply to a home, for example. The supply temperatures for hot and cold are independent, but pressure to the hot water supply often depends on the cold-water supply. Adjusting a shower for the right flow and temperature requires valve settings for the hot and cold supplies. But a sudden demand for cold water (flushing a toilet) can effect both hot and cold flows and temperatures until initial conditions return.

2. Non-stationary effects. These signal properties vary with time. An example may be how the sound changes as an airplane approaches and passes.

3. Unexpected boundary or load conditions

4. Time delays

5. Non-linearity

6. Noise and signal contamination

There are three basic thermal models. The first describes a system with one or more transfer functions describing a linear or non-linear relationship between input and output through discrete (lumped-parameter) components. For instance, a general state-variable representation of a system with input u(t), output y(t), and intermediate variables x(t) is as follows, where t is time.

x dot = Ax + Bu

y = Cx + Du

Solving this is relatively straight forward and results in a general form in the frequency domain:

Finite-element modeling provides a second method and may be the best choice for more distributed or continuous systems where the concern is thermal propagation. Finite-element systems can be reduced to state-space equations through tools available in math software such as Matlab. These equations may be used to evaluate control systems just as well as with transfer functions.

A state-flow diagram, a third model, makes decisions based on inputs, outputs, or both, and may include a history of previous input and outputs. State-flow systems are also ways to stitch together discrete control processes, so as one ends, the next begins. Some cases of this sort call for two modeling methods.

Test and measurement

After selecting a model or models, generate a basic model of the process you wish to control and experimentally verify it represents the physical world. The best way to verify the model is to take measurements at accessible key locations in the physical process and compare them to predicted results from the model at those same locations. Do this first at static conditions, then if all goes well, examine the behavior of both (model and physical modeling) during dynamic conditions.

Next, determine how the real system differs from the model, especially in special conditions or situations. Nearly all real systems exhibit some nonlinear or nonstationary behavior, and most have noise contamination. A few problem areas to watch for include:

Time delays. For a heating system, these are measured from the time a controller applies power to generate heat to the time it turns off. A system often can't stop heating when it determines there is too much heat. A properly working controller gets information in a sufficiently short period. Controlling a process with too much time delay is like missing a turn while driving because you didn't see a street sign in time. Knowing a system's time delays and where they come from is essential to control.

Nonlinear behavior is found in most systems. A small amount can often be ignored. But when nonlinear behavior makes up 10% or more deviation from linear, it needs serious consideration.

Continuous nonlinear behavior can show up as changes in material properties as temperature increases. Discontinuous behavior, on the other hand, can show up as a temperature-dependent contact or noncontact between two parts. For example, below a particular temperature there may be little heat transfer, while above it, heat flows freely. It is easier to characterize and compensate for continuous nonlinear behavior than discontinuous or eventful behavior.

Noise and signal distortion can be particularly troublesome. It is important to find the sources of noise and contamination before controlling a system. Noise can come from insensitive or over-sensitive sensors. It can also be from outside the system, entering from electrical, electromagnetic, mechanical, and thermal sources, including poor shielding and grounding.

Developing the system model calls for first gathering response data. This is necessary whether making sure a system responds as it was designed or simply trying to characterize a system. There are several preferred stimuli. The most common is the step function or changing the input temperature or power from one value to another, and observing what happens. In another, the impulse function, applies power instantaneously and removes it after a short period. For electrical and mechanical systems with wide response bandwidths, frequency-specific oscillatory inputs or random noise are often used because of their inherently higher signal-to-noise ratios. For thermal systems that normally respond slowly, these latter two methods usually take far too long to justify their advantages.

Perform step-response testing both at normal conditions and those close to the operating parameters at which it will perform. Be aware that nonlinearity can affect results, so it's a good idea to test with a variety of amplitudes and see how responses compare.

Pick the right model. For finite-element models, gather or estimate the system's physical properties and generate drawings so the system can be meshed and evaluated with equivalent stimuli and response methods. It is important to ensure that the effects introduced by measurement sensors to the physical system are represented in the model. This helps ensure the real and theoretical models are as close as they can be.

If the chosen model is a transfer function, developing it becomes less iterative, as long as there is not a lot of cross coupling or interaction between inputs or outputs.

For a linear-transfer-function model, a plot of the frequency-domain output versus input gives a magnitude and phase response that can be fitted to the required order analog or digital transfer function. Alternatively, the model may be kept within the time domain where it is somewhat easier to address non-linear responses by maintaining higher order response terms, such as those that are a function of the square of an input variable.

Model resolution refers to resolving the differences between model and real world. This is often iterative. Once the model behaves close to the real thing under normal conditions, the next step sees how well the correlation holds for extremes or what are sometimes called corner conditions of the operating envelope. For example, adding or removing an intermittent thermal source. This phase evaluates how the model handles aberrations. Although additional deviation is expected and tolerated, at no time should the model completely break down. If it does, an important consideration is missing and should be located.

How good does it have to be?

The short answer to the question: good but not perfect. A detailed design loop shows ample opportunity to iterate on the model should later stages show that the hardware behaves differently under control. In many cases, it is up to the judgment of the developer. All the contaminant effects, such as non-linearity and noise, must be evaluated for their strength so problems greatly influencing the system can be conquered and the insensitive ones ignored.

The effort described may seem to call for a great deal of time compared to trial-and-error methods. The risk is always in whether the system being controlled is simple enough for a quick-fix, off-the-shelf solution, or not. To evaluate this risk, test the system for complexity. That often leads to the rapid development of a control-system path as described. It has the advantage of letting engineers devote a lot or little time to any stage. And compared to trial-and-error, you learn more about the system with each step. In the end, when you are ready to commit to hardware, you have a greater chance of success and lesser likelihood of having to scrap the system and start over.