Fuzzy Logic Implementation On Embedded Microcomputers and Control Systems
Fuzzy Logic Implementation On Embedded Microcomputers and Control Systems
Published by
Copyright 1993 Byte Craft Limited. Licensed Material. All rights reserved. The Fuzz-C programs and manual are protected by copyrights. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise without the prior written permission of Byte Craft Limited.
Printed in Canada
April, 2001
Table of Contents
Forward
A fuzzy logic tutorial
Clear thinking on fuzzy linguistics Fuzzy logic implementation on embedded microcomputers Software Reliability and Fuzzy Logic Appendix
1
1
1 1 2 2
Clear thinking on fuzzy linguistics Fuzzy logic implementation on embedded microcomputers Software reliability and fuzzy logic Bibliography
Reading List Journals on Fuzzy Logic
Article References
5 11 21 29
29 34
34
35 37
Forward
This booklet exists as a result of the rush of people who asked for copies of the overhead slides I used in a talk on Fuzzy Logic For Control Systems at the 1993 Embedded Systems Show in Santa Clara.
Fuzzy Logic in embedded microcomputers and control systems Software Reliability and Fuzzy Logic
Originally part of the implementation paper, this chapter presents what is actually a separate subject. The inherent reliability and self scaling aspects of fuzzy logic are becoming important and may in fact be the over riding reason for the use of fuzzy logic.
Appendix
The appendix contains, in addition to copies of the slides, the actual code for a fuzzy PID controller as well as the block diagram of the PID controller used in my Santa Clara talk entitled Fuzzy Logic For Control Systems.
I have had a front row seat, watching a computing public finding uses for an almost 30 year-old new technology. Personally, I struggled with finding an application to clearly define what all the magic was about, until I switched the question around and looked at how an ever increasing list of fuzzy logic success stories might be implemented. I then looked at the language theory to see why linguistic variables were important in describing and solving problems on computers. Linguistic variables are central to fuzzy logic manipulations. Linguistic variables hold values that are uniformly distributed between 0 and 1, depending on the relevance of a context-dependent linguistic term. For example; we can say the room is hot and the furnace is hot, and the linguistic variable hot has different meanings depending on whether we refer to the room or the inside of the furnace. The assigned value of 0 to a linguistic variable means that the linguistic term is not true and the assigned value of 1 indicates the term is true. The "linguistic variables" used in everyday speech convey relative information about our environment or an object under observation and can convey a surprising amount of information. The relationship between crisp numbers and linguistic variables is now generally well understood. The linguistic variable HOT in the following graph has a value between 0 and 1 over the crisp range 60-80 (where 0 is not hot at all and 1 is undeniably hot). For each crisp number in a variable space (say room), a number of linguistic terms may apply. Linguistic variables in a computer require a formal way of describing a linguistic variable in the crisp terms the computer can deal with. The following graph shows the relationship between measured room temperature and the linguistic term hot. In the space between hot and not hot, the temperature is, to some degree, a bit of both. Byte Craft Limited 5
60
100
0 102030405060708090100 Temperature
Most fuzzy logic support software has a form resembling the following declaration of a linguistic variable. In this case, a crisp variable room is associated with a linguistic variable hot, defined using four break points from the graph.
LINGUISTIC room TYPE unsigned int MIN 0 MAX 100 { MEMBER HOT { 60, 80, 100, 100 } }
We often use linguistic references enhanced with crisp definitions. Cooking instructions are linguistic in nature: "Empty contents into a saucepan; add 4 1/2 cups (1 L) cold water." This quote from the instructions on a Minestrone soup mix packet shows just how common linguistic references are in our descriptive language. These instructions are in both the crisp and fuzzy domains.
We can extend basic air conditioner control to behave differently depending on the different types of day. The math developed to support linguistic variable manipulation conveniently implements an easy method to switch smoothly from one possible solution to another. This means that, unlike a conventional control system that easily implements a single well behaved control of a system, the fuzzy logic design can have many solutions (or rules) which apply to a single problem and the combined solutions can be appropriately weighted to a controlling action. Computersespecially those in embedded applicationscan be programmed to perform calculations in the fuzzy domain rather than the crisp domain. Fuzzy logic manipulations take advantage of the fact that linguistic variables are only resolved to crisp values at the resolution of the problem, a kind of self scaling feature that is objective-driven rather than data-driven. To keep a room comfortable, the temperature and humidity need to be kept only within the fuzzy comfort zone. Any calculations that have greater accuracy than the desired result are redundant, and require more computing power than is needed. Fuzzy logic is not the only way to achieve reductions in computing requirements but it is the best of the methods suggested so far to achieve this goal.
Fuzzy logic operators provide a formal method of manipulating linguistic variables. It is a reasonable comment to describe fuzzy logic as just another programming paradigm. Fuzzy logic critics are correct in stating that they can do with conventional code everything that fuzzy logic can do. For that matter, so can machine code, but I am not going to argue the point. Central to fuzzy logic manipulations are linguistic variables. Linguistic variables are non-precise variables that often convey a surprising amount of information. We can say, for example, that it is warm outside or that it is cool outside. In the first case we may be going outside for a walk and we want to know if we should wear a jacket so we ask the question, what is it like outside?, and the answer is it is warm outside. Experience has shown that a jacket is unnecessary if it is warm and it is mid-day; but, warm and early evening might mean that taking a jacket along might be wise as the day will change from warm to cool. The linguistic variables so common in everyday speech convey information about our environment or an object under observation. In common usage, linguistic variables often overlap. We can have a day in Boston that is, hot and muggy, indicating high humidity and hot temperatures. Again, I have described one linguistic variable in linguistic variable terms. The description hot and muggy is quite complex. Hot is simple enough as the following description shows. Linguistic variables in a computer require a formal way of describing a linguistic variable in crisp terms the computer can deal with. The following graph shows the relationship between measured temperature and the linguistic term hot. Although each of us may have slightly differing ideas about the exact temperature that hot actually indicates, the form is consistent. Byte Craft Limited 11
1 Degree of Membership 0
NOT HOT
HOT
0 10 20 30 40 50 60 70 80 90 100 Temperature
Linguistic Variable HOT
We can describe temperature in a non-graphical way with the following declaration. This declaration describes both the crisp variable Temperature as an unsigned int and a linguistic member HOT as a trapezoid with specific parameters.
LINGUISTIC Temperature TYPE unsigned int MIN 0 MAX 100 { MEMBER HOT { 60, 80, 100, 100 } }
12
13
000D 56 7); 000E 000F 0011 0012 0013 0015 0017 001A 001D 001F 0021 AE 93 10 AE 94 9C BC AD 9D 94 8E
< 1 > < < < < < < < < < < < 5 2 3 5 2 3 3 4 3 2 5 > > > > > > > > > > >
0022 98 0024 8E
else { return(255); }
14
< 3 > < < < < < < < 2 3 2 2 5 2 4 > > > > > > >
0116 A6 FF 0118 81
else { return(255); }
Central to the manipulation of fuzzy variables are fuzzy logic operators that parallel their boolean logic counterparts; f_and, f_or and f_not. We can define these operators as three macros to most embedded system C compilers as follows.
#define #define #define #define #define f_one 0xff f_zero 0x00 f_or(a,b) ((a) > (b) ? (a) : (b)) f_and(a,b) ((a) < (b) ? (a) : (b)) f_not(a) (f_one+f_zero-a)
The linguistic variable HOT is straight forward in meaning; as the temperature rises, our perceived degree of HOTness also rises, until and at some point we simply say it is hot. Our description of the linguistic variable MUGGY is, however, more complex. Typically, we think of the condition MUGGY as a combination of HOT and HUMID. Byte Craft Limited 15
Different variables can have the same linguistic member names. Like members of a structure or enumerated type in most programming languages, they do not have to be unique. It is important to note that many of the linguistic conclusions are a result of the general form of the above equation. We have linguistic definitions of the variable day. The variable day can have a number of linguistic terms associated with it. { MUGGY, HUMID, HOT, COLD, CLAMMY}. This list may be extensive. What is interesting, is that day, although a linguistic variable, doesn't have a crisp number associated with it. For example we can say that the day is HOT or that the day is MUGGY, but saying that the day = 29 is meaningless; day is a void variable. All day's members are based on fuzzy logic equations. The following is a complete description of day.
LINGUISTIC day TYPE void { MEMBER MUGGY { FUZZY ( Temperature IS HOT AND Humidity IS HUMID ) } MEMBER HOT { FUZZY Temperature IS HOT } MEMBER HUMID { FUZZY Humidity IS HUMID } MEMBER COLD { FUZZY Temperature IS COLD } MEMBER CLAMMY { FUZZY ( Temperature IS COLD AND Humidity IS HUMID ) } }
To calculate the Degree of Membership (DOM) of MUGGY in day, we need to calculate the DOM of HOT in Temperature and HUMID in Humidity, and then combine them with the fuzzy AND operator. The following code fragment shows implementation of day is MUGGY. For each of the linguistic members of day a similar equation needs to be generated. 16 Byte Craft Limited
17
100 90 80 70 60 50 40 30 20 10 Temperature ( HOT ) 405060708090100 Humidity (HUMID) Fuzzy Zero Fuzzy One DOM (Temperature_HOT) DOM (Humidy_HUMID) MIN ( DOM (Temperature_HOT), DOM (Humidity_HUMID) )
Temperature/Humidity Graph
18
19
Let us look at the lessons we can learn by applying high reliability principles to software development. This approach tends to draw less specific conclusions, but can form the basis for subjective evaluations of competing software designs, and can provide an effective tool for software engineering. Simple systems are components combined in series and parallel terms. Complex systems result from the combination of simple systems. Real systems are rarely as simple as a few components with easily identified relationships. Most reliability calculations, especially in software, are at best good estimates based on individual component information and some hard data measured from the system. The math behind all system reliability calculations is based on combining individual components (in software individual instructions or functions) using two basic formulas.
21
R1 R1 * R2 Rs = R1 + R2 R2 Rs
The reliability Rs is indistinguishable from the reliability of the two components R1 and R2. The units used in each of the reliabilities is time, usually measured in hours. In a practical system, reliabilities are the combination of series and parallel terms. Although software cannot place actual times on MTBF calculations, we can learn a lot about our system if we look at the relative reliability of software structured in different ways.
22
Rp = R1 + R2 R1 R2 Rp
Take a program and give it a dimensionless reliability of unity. Now divide the program into two parts such that each part performs a separate operation. This is often possible, because few programs contain code for a single operation. Re-configure the program to function as two independent tasks. You can then measure the reliability of the resulting two-task system. Each of these tasks will be half as long as the original, meaning that if our original assumption that the task reliability is a function of the code length is correct, each task will probably fail half as often as the original program.
23
= 4 =
24
There are many systems that satisfy these conditions. Here's a practical example involving a high-end product with an unacceptable number of failures. We reorganized the task scheduler from round robin to non-preemptive with many independent tasks. We made each task's execution independent rather than depending on other tasks in the loop. The customer reported failures went essentially to zero, and less than one percent of the code in the system was re-written! For a moment, assume reliability is essentially the same for all instructions. Assume also the reliability of a single task is essentially a function of the size of the task. In an isolated task this is true, however, in the real world a task takes on arguments and returns results. This adds an assumption that a task can cope with all of the possible arguments presented. What if the arguments presented to the task could in some way cause the task to fail? Then the arguments themselves would be a part of the reliability of the task. This would indicate that the reliability of a task is a function of the number of arguments presented to it. It also means that anything that is capable of altering the value of the arguments presented to a task is now a part of the series terms in an individual task's reliability.
25
Task 1
Task 2
As time passes, it is found the second task is useful for other things, and is called by a third task. The third task requires a minor change that we feel the first task is unlikely to notice. Now, as fate would have it, the first task calls the revised second task and the returned result causes the previously functioning first task to fail. This suggests that a task's reliability requires it's interaction with other tasks be conducted through a well defined interface. In fact, a task should not communicate directly with other tasks at all, but through some abstract protocol. This would mean that a task could then be isolated from its environment; as long as it responds to requests from the protocol it could be implemented in any manner without affecting other tasks making requests of it through the protocol.
26
Task 1
Task 2
Sound familiar? In implementing fuzzy logic systems the fuzzy logic rules operate independently from each other to the degree that the rules in a block can usually be executed in any order, and the result will still be the same. Each rule is small and may be implemented in a few instructions. Fuzzy logic rules call membership functions through a welldefined interface providing isolation and further parallelism. After a fuzzy logic rule is evaluated it calls CONSEQUENCE functions through a well-defined interface. As in our earlier example of dividing a problem to achieve improved reliability the fuzzy logic solution naturally breaks a problem into its component parts. There are other ways to visualize the reliability of the system. The focus of the fuzzy logic rules is on a very different level of detail than is the focus of the membership functions. This reduces a problem's solution to its component parts. Compilers may reassemble the code for effective execution on some target, but at the programmer level the problem is a number of simple tasks. Byte Craft Limited 27
28
Bibliography
There are a number of names that consistently appear in the fuzzy logic literature. In your search for reading material, the following authors have much to offer both in their technical content and their presentation. This list is not exhaustive, but it is a reasonable place to start a literature search in most good libraries.
David I. Brubaker, The Huntington Group Madan M. Gupta, University of Saskatchewan, Saskatoon. Bart Kosko, University of Southern California, Los Angeles. Jim Sibigtroth, Motorola Semiconductor, Austin, Texas. Lotfi Zadeh, University of California at Berkeley. Hans-Jurgen Zimmermann.
Reading List
Bandemer, Hans, ed., "Some applications of fuzzy set theory in data analysis", 1. Aufl., Leipzig : VEB Deutscher Verlag fur Grundstoffindustrie, c1988, ISBN 3-34-200985-3 (pbk.), (Summaries in English, German and Russian). Bezdek, James C. and Pal, Sankar K., "Fuzzy models for pattern recognition : methods that search for structures in data", New York : IEEE Press, 1992, ISBN 0-78-030422-5. Billot, Antoine, "Economic theory of fuzzy equilibria : an axiomatic analysis", Berlin : Springer-Verlag, c1992, ISBN 3-54-054982-X (Berlin), ISBN 0-38-754982-X (New York). Dubois, Diddier and Prade, Henri, "Possibility Theory, An Approach to Computerized Processing of Uncertainty".
29
30
31
33
Article References
"Fuzzy sets as a basis for a theory of possibility.", Lofti Zadeh, Fuzzy Sets and Sytems I, 3-28 "Designing with Tolerance.", Walter Banks, Embedded Systems Programming June 1990 "Software Reliability", H.Kopetz, Springer_Verlag 1979 "Software Reliability", John D. Musa, Anthony Iannino, Kazuhira Okumoto McGraw-Hill 1990 "Reliability Principles and Practices", S.R. Calabro, McGraw Hill Brubaker, David I., "Fuzzy-logic Basics: Intuitive Rules Replace Complex Math", EDN Asia, August, 1992, pp. 59-63. Khan, Emdad and Venkatupuram, Prahlad, "Fuzzy Logic Design Algorithms Using Neural Net Based Learning", Embedded Systems Conference, September, 1992 Santa Clara, CA. Sibigtroth, James M., "Creating Fuzzy Micros", December, 1991, Emedded Systems Programming, pp. 20-31. Sibigtroth, James M., "Fuzzy Logics", April, 1992, AI Expert. Williams, Tom, "Fuzzy Logic Is Anything But Fuzzy", April, 1992, Computer Design, pp. 113-127.
34
Walter Banks is the president of Byte Craft Limited, a company specializing in code creation tools for embedded systems. One of these products, Fuzz-C Preprocessor for Fuzzy Logic, adds linguistic variables and fuzzy logic operators to programs written in C . Fuzz-C is implemented as a preprocessor, making it compatible with most C compilers. Gordon Hayward is an associate professor in the School of Engineering at the University of Guelph. His research is primarily in the field of instrument design, and his current projects include the design of sensors to monitor environmental contaminants and the use of piezoelectric crystals as chemical sensors. In many applications, the required information can not be measured precisely (flavour is a good example), hence his interest in fuzzy logic.
35
Appendix
This appendix contains a selection of pages employed as overhead slides used in my talk on Fuzzy Logic For Control Systems, at the 1993 Embedded Systems Show in Santa Clara. In addition to copies of the slides, I've included the actual code for a fuzzy PID controller as well as the block diagram of the PID controller used in Santa Clara.
Example of PID Controller:
Int OldError,SumError; int process(void); LINGUISTIC Error TYPE int MIN -90 MAX 90 { MEMBER LNegative { -90, -90, -20, 0 } MEMBER normal { -20, 0, 20 } MEMBER close { -3, 0, 3 } MEMBER LPositive { 0, 20, 90, 90 } } LINGUISTIC DeltaError TYPE int MIN -90 MAX 90 { MEMBER Negative { -90, -90, -10, 0 } MEMBER Positive { 0, 10, 90, 90 } } LINGUISTIC SumError TYPE int MIN -90 { MEMBER LNeg { -90, -90, -5, 0 } MEMBER LPos { 0, 5, 90, 90 } } CONSEQUENCE { MEMBER MEMBER MEMBER MEMBER } ManVar TYPE int LNegative SNegative SPositive LPositive { { { { -18 -6 6 18 } } } } MIN -20 MAX 90
MAX 20 DEFUZZ cg
FUZZY pid { IF Error IS LNegative THEN ManVar IS LPositive IF Error IS LPositive THEN ManVar IS LNegative IF Error IS normal AND DeltaError IS Positive
37
38
*/ char Error_LNegative (int __CRISP) { { if (__CRISP <= -20) return(255); else { if (__CRISP <= 0) return(( - __CRISP * 12) + 7); else return(0); } } } /* MEMBER normal { -20, 0, 20 /* 1-| . | . . | . . | . . 0-| ............. .............. ----------------------------------90 -45 0 45 90
} */
*/ char Error_normal (int __CRISP) { if (__CRISP < -20) return(0); else { if (__CRISP <= 0) return(((__CRISP + 20) * 12) + 7); else { { if (__CRISP <= 20) return((( + 20 - __CRISP) * 12) + 7); else return(0); } } } } /* MEMBER close { -3, 0, 3 } */ /* 1-| | . .
39
*/ /* LINGUISTIC DeltaError TYPE int MIN -90 MAX 90 */ /* { */ int DeltaError ; /* MEMBER Negative { -90, -90, -10, 0 } */ /*
40
*/ char DeltaError_Negative (int __CRISP) { { if (__CRISP <= -10) return(255); else { if (__CRISP <= 0) return(( - __CRISP * 25) + 2); else return(0); } } } /* MEMBER Positive { 0, 10, 90, /* 1-| ................ | . . | . . | . . 0-| ................. . ----------------------------------90 -45 0 45 90
90 } */
*/ char DeltaError_Positive (int __CRISP) { if (__CRISP < 0) return(0); else { if (__CRISP <= 10) return((__CRISP * 25) + 2); else { return(255); } } } /* } */ /* Fuzzy Sets for DeltaError 1-| | | | 0-| ............... ................ . . . . . . . . . . . ................................. ----------------------------------90 -45 0 45 90
*/ /* LINGUISTIC SumError TYPE int MIN -90 MAX 90 */ /* { */ int SumError ; /* MEMBER LNeg { -90, -90, -5, 0 } */ /* 1-| ................ | . .
41
90 } */
1-| ................. | . . | . . | . . 0-| ................. . ----------------------------------90 -45 0 45 90 */ char SumError_LPos (int __CRISP) { if (__CRISP < 0) return(0); else { if (__CRISP <= 5) return(__CRISP * 51); else { return(255); } } } /* } */ /* Fuzzy Sets for SumError 1-| | | | 0-| ................................. . .. . . . . . . . ................................. ----------------------------------90 -45 0 45 90
*/ /* CONSEQUENCE ManVar TYPE int MIN -20 /* { */ int ManVar ; long fa_@ConsName, fc_@ConsName; /* MEMBER LNegative { -18 } */ /* 1-| | | . . .
MAX 20 DEFUZZ cg */
42
43
44