Number 34 January 93 The Huntington Technical Brief By David Brubaker Ph.D. FUZZY SYSTEM DESIGN RULES OF THUMB ---------------------------------- INTRODUCTION For the most part, I tend to distrust rules-of-thumb. As with any abstraction, I am never certain how much detail critical to my particular application has been sacrificed for succinctness. Never-the-less, as I have worked through the feasibility phase of a current project, designing a simulation, and working with that simulation to provide a confidence on the part of my client that the full project is worth undertaking, I am again reminded that there are rules applicable to most fuzzy designs. This list is not intended to be all inclusive. RULES-OF-THUMB 0. Know your system, its requirements, and the available tools. Make tradeoff decisions that are supported both objectively and subjectively. This first rule (I intentionally labeled it zero), applies to the development of all systems. We know that most complex projects are like pancakes; the first version should be considered a throw-away. Its value is not itself, but that it has provided a means for the development team to "know" their system, the requirements, and the available tools, and to see which tradeoffs worked and which did not. 1. Maintain a smooth response curve about the operation point. Each fuzzy response curve describes a system output as a function of system inputs. A discontinuous response curve about the operating point will result in a choppy response to a smooth input. 2. Carefully identify and utilize the ranges of linguistic variables. A simplistic example will illustrate this. First, consider a system with a fuzzy variable "speed" and at the upper extreme the two fuzzy values "fast" and "very_fast". If the operation of the system is basically the same for both fuzzy values, an entire dimension of the system can be eliminated by eliminating "very_fast" and expanding the range of "fast" accordingly. 3. Linguistic input variables are used as conditions in the rules; treat them accordingly. Context of linguistic variables is important. The term fast in the above examples will have different meaning in different applications. 4. If possible, start with an exhaustive list of rules. That is, establish the rules so as to cover all possible input conditions. Impossible and implausible condition combinations can be identified and dealt with later. 5. Start rule definition by identifying unambiguous controller actions at specific operating points. Subsequent rules can then be defined by identifying desired controller operation at adjacent operating points. 6. Design should be considered an incremental or step-by-step process. The traditional incremental development process is called increment build. I feel more comfortable with a combination incremental build/incremental destroy, where not only are necessary components added to achieve required capability, but unnecessary components are either destroyed or replaced. 7. Don't be locked completely into a rule-based way of thinking. In reading the literature, we are (for the most part unintentionally) led to believe that a rule-based representation of knowledge is the only available architecture. It is not. We can be creative in our use of fuzzy terms in our designs. 8. Rule-based systems can be creatively structured. Even if a rule-based architecture is used, it is not necessary that the entire system be represented by a single, all-inclusive rule-base. A system may consist of several rule-bases, each active in response to different input conditions. 9. In realtime 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. System response, as determined by the rule-base, will be different based on the value of time_to_deadline. 10. Use and learn from system simulations. Of course, a great degree of confidence in the simulated representation of the environment in which the system will operate is required, as is a questioning of the entire simulation process, coupled with healthy skepticism. That is, don't blindly trust computers. Conclusion - This has been an initial list of "rules-of-thumb" to use in fuzzy system design. Some would seem obvious, others are perhaps a little more obscure. Some apply universally, others should be used with care. ---------------------------------------------------------------- The Huntington Group provides technical consulting services in complex, real-time, embedded processor, and fuzzy system design. The Huntington Technical Brief, of which this is a much edited version, is a marketing tool, published once a month on fuzzy topics of interest - a yearly subscription costs $24 and back issues are available at $2.00 per issue. A report, "Introduction to Fuzzy Logic Systems" is also available for $50. For more information, call David Brubaker at 415-325-7554. ---------------------------------------------------------------- Copyright 1992 by The Huntington Group 883 Santa Cruz Avenue, Suite 31 Menlo Park, CA 94025-4608 This information is provided by Aptronix FuzzyNet 408-428-1883 Data USR V.32bis