Data Acquisition (DAQ) and Control from Microstar Laboratories

From PID to Fuzzy Control: Taking The Plunge Cautiously

The Problem


(View more Control information or download preliminary software modules.)

Back in the middle '90s, Bob Pease ran columns in "Electronic Design" magazine, deriding fuzzy controllers [1]. What bothered him most was unfounded (and sometimes plain wrong) marketing hype, and the fact that inferior but more complex fuzzy controllers were displacing well-suited PID controllers because clueless managers thought it would be good for business.

We intend to show that, given any well-tuned PID controller, it is always possible to configure a fuzzy logic controller that is no more complex, but never less effective. (There you go, a carefully worded claim that is at least as misleading as the hype that you will find in the trade mags, as we will soon show.) If a PID controller's performance is not quite acceptable, perhaps this can serve as a first step toward performance improvements.

What's the Fuzz?

Fuzzy logic is of course one giant misnomer. There is nothing fuzzy at all about the logic, which is defined in mathematical terms that are precise, repeatable, and programmable. The fuzziness comes from uncertainty about the domain being represented.

To apply a fuzzy logic system, you need ideas that you want to represent, otherwise you are using the wrong tool. For the case of a regulating controller, certain performance concerns should be addressed.

1. If the output goes away from the desired setpoint, drive it back toward the setpoint.

In fuzzy logic, an output can be high to some degree, low to some degree, both at the same time. For representing this mathematically, we can select reasonable bounding levels at which it is 100% certain that the output is too high, or 100% certain that the output is too low. Any values between can be considered a mix. When the system settles at the desired setpoint, this implies that the input level is neither too low nor too high, or equivalently, it is an equal mix of each. The region ranging from too low to too high would be centered about the setpoint level, so we can use the difference between the desired setpoint level and the actual output level as the input signal. Between the two extremes and the central balance, some kind of continuous curve defines the compromise between too high and too low. To keep things simple, we can use a linear curve. Thus, the basic control input can be represented by the following input mapping.

Level variables

Given measured deviations from the desired output level, the curves provide fuzzy membership levels for classifying the input values in terms of the two complementary fuzzy input range variables.

We can consider input levels in other ways. If observed deviations persist over time, this might change the strategy.

2. If the output remains persistently displaced from the desired setpoint, drive it toward the setpoint.

We need a way to represent mathematically what persistently high and persistently low mean. One way to do this is to sum the sequence of deviations from the setpoint, as observed, and compare the sum to reasonable range limits. This running error accumulation is also mapped to fuzzy membership levels in a manner similar to the deviation inputs.

Accumulation variables

Change is good, but rapid change is not so good when the output level is already close to where it is supposed to be. We can note that change tends to become small near the peaks of excursions anyway. Where it tends to be largest is where it tends to be most harmful.

3. If the output is changing too fast, oppose the change.

We can estimate the rate of change by observing how much the feedback observations change from sample to sample. We can then characterize change in terms of fuzzy membership levels between too fast forward and too fast reverse.

Change variables

If you have noticed that a lot of inspiration has been drawn from classic PID control to this point, good! A fuzzy controller can't respond to information that it doesn't have. If it has fundamentally less information than a PID controller it will be fundamentally less capable.

Where's the Logic In That?

So far, all we have done is define some terminology, some fuzzy variables, but nothing about the relationships. That is where the fuzzy logic comes in. If the input variables and the quantities derived from them have deviated from desired levels, we want control rules that drive the levels back. Each heuristic is represented in two parts.

  If INPUT is TOO LOW, drive output HIGH.
  If INPUT is TOO HIGH, drive output LOW.
  If SPEED is TOO FAST FORWARD, drive output LOW.
  If SPEED is TOO FAST REVERSE, drive output HIGH.

Each inference rule contributes evidence supporting the action of OUTPUT HIGH or of OUTPUT LOW. The final action must be a combination. We will ignore the popular min-max operators and use an additive combination because we are combining signals, not logical possibility.

  support for output level LOW OUTPUT =
     membership of INPUT in TOO HIGH  +
     membership of SPEED in TOO FAST FORWARD ;

  support for output level HIGH OUTPUT =
     membership of INPUT in TOO LOW  +
     membership of ACCUMULATION in PERSISTENTLY LOW  +
     membership of SPEED in TOO FAST REVERSE ;

There are some problems with this:

  • A problem of interpretation. When we sum membership values between 0.0 ("does not apply at all") and 1.0 ("is totally applicable") we can obtain a number that exceeds 1.0. This number no longer has an interpretation as fuzzy membership. We must deal with normalization issues. One approach is bounding the support levels [2].
  • The results of the inference remain mutually contradictory. We have advice to use LOW OUTPUT and to use HIGH OUTPUT simultaneously. There must be conflict resolution to determine what physical output level to generate. This conflict resolution is also known as defuzzification. The conflict can be resolved by selecting a compromise value in proportion to the membership sums for LOW OUTPUT and HIGH OUTPUT. This defuzzification process is very similar to the process used to map input levels to fuzzy memberships, but applied in the reverse direction.

    Output variables
  • Combining the membership levels of different fuzzy variables is like combining accumulations of apples with differences of oranges. The success of a control strategy depends a lot on how the final mixing is done. We make it adjustable by providing somewhat arbitrary weighting factors, analogous to the gain parameters in a PID controller. The adjusted support evaluations become
      support for output level LOW OUTPUT =
         W1 * membership of input in TOO HIGH  +
         W2 * membership of accumulation in PERSISTENTLY HIGH  +
         W3 * membership of speed in FAST FORWARD ;
      support for output level HIGH OUTPUT =
         W1 * membership of input in TOO LOW  +
         W2 * membership of accumulation in PERSISTENTLY LOW  +
         W3 * membership of speed in FAST REVERSE ;

Now we can compute the control law and generate actual output. To summarize, we will:

  1. determine the membership levels of the fuzzy input variables,
  2. apply the inference rules to determine their levels of support for each output variable,
  3. sum the weighted levels of support for the output variables,
  4. defuzzify to establish a physical output level.

To those readers already familiar with fuzzy controllers, there should be no surprises here.

What a Long Strange Trip It's Been

The mathematical choices of representation have finally yielded a fully-defined control system. It is time to implement it and put it to the test. If you wish, you can view the fuzzy control code and classic PID code in separate browser windows. The example code is organized for simplicity of presentation rather than runtime efficiency, and it will compile as C or C++. (Most applications needing fuzzy logic should consider a fuzzy rule evaluator engine; see reference [3] for example). One very easy way to get the code up and running quickly is to patch it into a DAPL system processing command module, but the same results can be obtained in any other context. After tuning parameters for best performance, here are output results in response to the same input sequence:

PID:   ...  20884  20755  20524  20468  20449   ...
FUZZY: ...  20884  20755  20524  20468  20449   ...

As you can see, there is no difference. Consequently, the simple fuzzy logic controller just designed is not inferior to its corresponding PID controller. The parameters of the fuzzy controller are directly related to the PID gain parameters, hence this same result can be obtained in every case.

The simple fuzzy logic controller is based on three heuristic fuzzy rules adjusted by weighting factors, while the PID controller is based on three heuristic formulas adjusted by gain factors. The fuzzy controller is no more mathematically complex.

It therefore has been demonstrated that this fuzzy logic controller is neither less effective nor more complex than its PID counterpart.  QED.

WHAT?! Is This Some Kind of Joke?

Well, yes it is, in a way. It is the same joke as the argument: "Which is better, a fuzzy logic controller or a PID controller?" As we have just seen, a PID controller is just one possible special case of a fuzzy logic controller [4], in much the same way that classical logic is just one possible special case of fuzzy logic.

This has not been a waste of your time. It is well known that PID controllers do not always work well, even though they are quite satisfactory most of the time. While a PID controller allows no flexibility of structure, a fuzzy logic controller can be whatever it needs to be (or something quite different from what it needs to be — which explains its reputation). You can start with the fuzzy PID controller, with a fuzzy logic rule set and initial parameter choices that match an established PID configuration. Add rules to cover situations that the PID controller does not address well, and adjust parameters to see what benefits derive, with just as much new complication as you need but no more. With classic PID, you are stuck.

Fuzzy control opens up a door — or a Pandora's box — of possibilities. Among these:

  1. If a clueless boss insists that you use fuzzy logic control when it isn't helpful, you can do so without sacrificing any PID performance.
  2. Input ranges can be subdivided and given different treatment. This can compensate for inherent nonlinearity in input signals, or provide different response to larger or smaller transient disturbances.
  3. Control rules sensitive to absolute input levels can be included. (If systems were truly linear, the input level would not matter, but show me a truly linear system.) When operating over a wide range, gain scheduling of this sort can sometimes improve economic performance or avoid stability problems.
  4. Control rules can be added to cover important interactions among variables.
  5. Output ranges can be subdivided and given different treatment. This can sometimes help compensate for actuator nonlinearity.
  6. Control rules can be added to respond to special-case safety or limit conditions.

But once again, each extension introduces new complexity, including more ways to go wrong. If nothing else, a new set of parameters must be tuned. Generic tuning rules for PID controllers might be 50% hoodoo and 50% ineffective, but there are no tuning rules for fuzzy logic controllers.


"My system performs fine with classic PID. Why should I consider fuzzy logic?" You shouldn't, unless of course you recently went into management. Control systems should be used to solve problems, not create them. Bob Pease would tell you as much.

But let's say that your system performance isn't fine, though you have a pretty good idea of what can be done to address the problem. The question is, how do you get from insight to installation? You could of course hire a consultant to design (build, document, install, support) a controller that includes all of the usual features, plus the specialized twists you want to try. Cheap? Guess again. Amortized over 5000 or more units, expense doesn't matter and that's probably a great way to go. But what if your production line needs just a few units? You might consider a DAP-based control system. The digitizing, processing, and basic control framework are already there. Using the Developer's Toolkit for DAPL, you can patch in your specialized code to replace "compute PID control law." Then compile, download, and run it on the spot. When you find the variation that is effective, you have an industrial- grade implementation that is ready to go into production.

And finally, don't panic just because you see that unfortunate term "fuzzy" attributed to a control system. If it is useful to think in terms of "rules" when defining a control solution, fuzzy approaches are an option to consider.

Footnotes and References:

  1. "What's All This Fuzzy Logic Stuff, Anyhow? (Part 2)", Bob Pease, from the Electronic Design "Pease Porridge" column, reprint hosted by the National Semiconductor site.
  2. Nothing new or original here. Among the "t-conorm" fuzzy inference operators surveyed in "A Review of Fuzzy Sets Aggregation Connectives", D. Dubois and H. Prade, Information Sciences v36 1985, pp 85-121, we can find the saturating operator S(a,b) = (a+b) ^ 1 .
  3. An example: "Fuzzy Logic in C", Greg Viot, Dr. Dobb's Journal, Feb. 1993, briefly surveys fuzzy logic and control from a "fuzzy purist" point of view, with source code.
  4. Though the similarities of various fuzzy PID schemes to classic PID are widely known, it is not generally well understood that classic PID is matched exactly using specially-selected fuzzy representations and methods. In the report "Tuning Of Fuzzy PID Controllers", Technical University of Denmark, report 98-H 871, September 30, 1998, Jan Jantzen used an exact initial matching of classic PID with incremental introduction of nonlinearity as a strategy for fuzzy PID tuning.


Return to the Control page.