Remembering "There!" actually helped me in an early consulting contract. In those hungry times, I turned down no job I felt even close to being able to do, if the client would pay. ("Clean the bathroom? No problem! Where's the mop?") A nearby printing company had purchased two or three new printers. Contrary to specification, the new machines were running slower than the older ones they replaced. The manufacturer had told the company there was a wear-in period, and that, after a week or two, the machines would definitely be running at speed. The printing company, probably backlogged and definitely impatient, called me in to see if something more serious was involved.

Each printer used 440V. Following time-honored rules of thumb, I removed my ring and watch, checked for proper grounds, and kneeled on an nonconductive pad behind one of the printers. I checked the schematics, turned on my Tektronix 465 oscilloscope, and started probing.

Everything went well for the first half-hour, and, when their initial curiosity had worn off, both workers and management returned to their respective responsibilities. Then, after I probed one test point and needed to identify the next one from the manual, I glanced away from my hand and the probe. My hand drifted a bit, and the probe's ground ring touched a 440V connection. Sparks flew, popping sounds filled the room, the tip of my probe melted, the printer groaned, and I suddenly had everyone's attention. More as a reflex than remembering my sister's story, I exclaimed with force and conviction, "There!" Fears were immediately calmed, and everyone, except one shaken engineer, seemed satisfied that I knew what I was doing. As transparent a ploy as it seemed, "There!" actually worked!

I packed my tools and scope, told my point-of-contact that the manufacturer was correct—there was a wear-in period—and generously offered to delay my bill until the machines were operating at their specified speed. This took about a week, and my invoice was for $16.50—too little to cover the cost of a new probe. Ah, nostalgia!

In this issue, I shall present rules of thumb that are helpful when developing a fuzzy, or Zadehan, system. Perhaps "There!" doesn't really qualify as a rule of thumb, but "keep your eyes on what you're doing" definitely does, and ignoring that one is what got me into trouble.

For the most part, I tend to be skeptical of rules of thumb. I definitely don't accept them blindly and am frustrated when people do. As with any abstraction, I am never certain how much detail that is critical to my particular application has been sacrificed for succinctness. Nevertheless, as I work through project after fuzzy project, I rediscover certain rules that are applicable to a wide range of Zadehan designs.

The following list cannot be all-inclusive. I hope it will be the first of several lists (with your help—I invite you to submit your own rules of thumb).

0. Know your system and the environment in which it will operate. Support your trade-off decisions both objectively (with facts) and subjectively (with experience-based feelings).

This first rule applies to the development of all systems; that's why I labeled it zero. I don't intend to get overly philosophical; please, just bear with me. Over the past two decades, we have become more and more concerned with the "development process" in system design. We attempt to find better ways to design, using techniques that result not only in system design, but also in metrics indicating how well we did. With an ever-decreasing time to market, we strive to do it right the first time. This is the goal.

In reality, we also know that most complex projects are like pancakes; the first one or two should be thrown out. A first version's value is not itself but that it has provided a means of "getting the griddle hot." Its design and development allow the responsible team to know its system and its requirements, to know the development tools, and to see which trade-offs work and which do not. Once designers understand these things, they are ready to design the actual system. Time to market may have a significant impact on next quarter's bottom line, but the quality of the systems a company produces is one of several dominant indications of whether the company will still be around in 10 to 25 years.

Onward. And we shall, finally, get technical.

1. Maintain a smooth response curve about the operating point.

Fuzzy-rule-based design is the generating of a desired response curve (a system's output as a function of its inputs) from linguistically defined parameters that are interconnected by rules. Feedback applications, whether fuzzy or not, contain an operating point, typically at the center of the response function, toward which the system is driven. Once a system reaches its operating point, any attempt to move from that point causes the feedback mechanism to force the system back.

A discontinuous response curve about the operating point (for example, one with "stair steps") results in a choppy response to a normally smooth input. Systems executed by a digital processor always have some degree of stair steps, but, when the steps are small enough, these do not appreciably affect overall performance.

In general, be wary of the behavior of derivatives, both of inputs and of those associated with a system's inner workings. Use of input derivatives is often necessary, and generating steps with infinite-valued output slopes is often unavoidable, but you must always determine whether these derivatives will degrade system performance.

2. Carefully identify and use the ranges of linguistic variables.

A simple example illustrates this point. First, consider the fuzzy variable speed and the two fuzzy values, fast and very_fast, in speed's upper range. If the required system response is substantially the same for both of these fuzzy values (for example, "braking_action IS full"), you can eliminate an entire dimension of the rule base by removing very_fast and appropriately expanding the extent of fast.

On the other hand, a system can lose precision if there are too few fuzzy values near its operating point. For the same fuzzy variable speed, performance may be inadequate with a single fuzzy value, slow, in its lower region. Adding the value very_slow and, possibly, even very_very_slow, although increasing the dimensionality of the rule base, may be necessary to achieve required performance.

3. The fuzzy values of linguistic input variables are used as conditions in rules; treat them accordingly.

The context of linguistic input variables is important. The fuzzy value fast in the above example has different meanings in different applications. However, even in a given application where its definition constrains fast to a specific range, you must remember that the value is further affected by the choice of the other fuzzy input values and the roles they play in rule conditions.

4. If possible, start your design with an exhaustive set of rules.

Establish the initial set of rules to cover all possible input conditions, and deal with impossible and implausible condition combinations later. Also, postpone reducing the number of rules, which is typically done by optimizing the combinatorial logic that combines rule conditions. The ability to address and see the consequence of each individual combination of conditions is of great value when the system undergoes fine-tuning.

5. Start the rule definition process by identifying known required actions at specific operating points.

You then define subsequent rules by interpolating between these known points.

6. Make the design process incremental.

The traditional step-by-step development process is called incremental build. I feel more comfortable with a combination incremental build/incremental destroy process. You not only add necessary components to achieve required capability, but also delete or replace unnecessary components. In a rule base with rule conditions combined using AND logic, capability can be both added and deleted with no impact on other regions in the input space, with an appropriate adjustment of the overlap of the neighboring membership functions.

7. Don't be locked into a rule-based way of thinking.

You have heard this from me before. Most fuzzy literature leads you to believe that a rule-based representation of knowledge is the only available architecture. It is not. Although you may lose the support offered by currently available commercial tools, you can be quite creative in your use of fuzzy variables and values in designs.

8. Rule-based systems can be creatively structured.

The decision to use a Zadehan rule base does not require casting the entire system into a single, all-inclusive set of rules. You can easily design a Zadehan rule base to operate as a separate system component, communicating with other fuzzy or nonfuzzy components.

9. In real-time systems, don't be afraid to treat time as a fuzzy variable.

For example, if there is a required response time, a fuzzy variable may be time_to_deadline, with values long, medium, short, and very_short. The value of time_to_deadline directly affects the rule-base output.

Moreover, time_to_deadline may be either an input to the rule base, or a definition of the state in a state machine. In the latter case, state values are fuzzy variables, and each state points to a rule base that provides outputs to the degree the given state is active.

10. Use and learn from system simulations.

Lotfi Zadeh, fuzzy logic's father and the basis for the name "Zadehan," was once asked how to develop a degree of confidence with respect to the operation of a fuzzy system. His answer was to simulate the system to death. Of course, simulation is no substitute for verification of an actual operation, but, working with good models of the environment in which the fuzzy system will operate, simulation is a valuable and, often, necessary step.

As always, maintain a healthy skepticism toward any simulated process. Never trust results generated by software that hasn't yet earned your trust.

11. If you ever hear your surgeon exclaim, with force and conviction, "There!"... well, good luck.

And, refuse to pay your medical bill until you are back up to speed.