SUMPY: A Fuzzy Software Agent - CiteSeerX

2 downloads 0 Views 94KB Size Report
The University of Memphis ... [email protected].memphis.edu. Abstract. SUMPY is a software agent ..... 1) Random walking (Wanderer). Wanderer senses ...
SUMPY: A Fuzzy Software Agent Hongjun Song Institute for Intelligent Systems The University of Memphis [email protected] www.msci.memphis.edu/~songh

Stan Franklin Institute for Intelligent Systems The University of Memphis [email protected] www.msci.memphis.edu/~franklin

Abstract SUMPY is a software agent “living” in and helping to maintain a UNIX file system for better disk space utilization by compressing and backing up. Built using subsumption architecture, SUMPY displays a “plug and play” property. A new UNIX maintenance task can be added to SUMPY’s repertoire without modification of existing layers. One of SUMPY’s layers sports a fuzzy control mechanism enabling it to achieve its goals in a realworld manner. Another restricts SUMPY’s activity to times of slow CPU use. An experiment in agent architecture and in the use of agents for such maintenance tasks, SUMPY promises to prove useful, and has added no significant problems to the test systems. Key words: autonomous agent, fuzzy controller, software agent, subsumption architecture.

1. Introduction

Aregahegn Negatu Dept. of Math Sciences The University of Memphis [email protected]

Fuzziness abounds in the real world [9]. Fuzzy knowledge and fuzzy reasoning are useful when making decisions with fuzzy information. Software agents can face the same problem of fuzziness. Hence, fuzzy processing could be a part of their control structure. Here we describe our research based on a software agent, named SUMPY, built with a subsumption control structure. SUMPY, running continuously in a UNIX environment, aids its administrator in maintaining its file system, thereby improving disk utilization. One of SUMPY’s layers has a fuzzy controller. Thus SUMPY is at least partially a fuzzy software agent. The next section gives a brief description of subsumption architecture and of a fuzzy controller. SUMPY’s subsumption architecture is described in section 3, while his fuzzy mechanism is discussed in section 4. Section 5 is concerned with SUMPY’s implementation. The last section describes SUMPY in action, and contained plans for the future.

Autonomous agents have shown considerable promise in robotics [1,2,3,12,13], software development [5], information mining in network environments [4,10], life science [11], and in other fields. Thus control structures for such autonomous agents raise important research issues. What are the useful architectures for what tasks? Many interesting control structures have been proposed and studied. Brook’s subsumption architecture is one such.

2. Some possible architectures

Mobile autonomous robots can move in their physical environment performing tasks humans find too difficult, too dangerous, or just too boring [7]. Autonomous software agents (or softbots) also “live” in an appropriate software environment, say in an operating system’s file structure, a database, or on a network. Autonomous agents have their sensors and actuators so that they can perceive information from their environment and produce the next action, so changing the environment. Though physical robots and softbots differ greatly in their implementation, they may share their control architecture, a subsumption architecture for one example.

Brooks introduced the subsumption architecture for building autonomous mobile robots [1,2,3]. The architecture enables a tight connection of perception to action [6].

Briefly descriptions of subsumption architecture and of fuzzy controllers are given here. More details can be found in [1,2,3] and [8].

2.1 Subsumption Architecture

A subsumption architect begins by decomposing the problem into a series of task-achieving behaviors (competencies) such as avoid objects, wander, explore, ... etc. Each competence is implemented in its own layer with its own access to sensors and actuators. Together they form a control system with the “plug and play” property. A new

layer (competence) can be added to an existing set without rebuilding (or rewriting) the earlier layers. After the first layer is built and debugged thoroughly, the next layer is built with independent access to sensors and actuators and, often, the ability to suppress the lower layer or to determine it’s input. This higher layer, sometimes with the aid of the lower layer, achieves this higher layer’s competence. The lower layer continues to run unaware of the layer above it, which sometime interferes with its data paths. The same process is repeated to add additional layers (competencies) (Figure 2.1).

Level 2 Level 1

Controlled

Process Input

Fuzzy inference Module

Fuzzy rule Base

Fuzzification Module

Fig. 2.2 A general fuzzy controller Measurements of input variables of a fuzzy controller must be properly combined with relevant fuzzy information rules to make inferences regarding the output variables. This is the purpose of the inference engine.

Level 3

Sensors

Output

Defuzzification Module

Actuators

Fig.2.1 Brooks’ Subsumption Architecture

A robot or softbot with subsumption architecture control structure can have multiple parallel goals, and multiple tightly connected sensing-to-action channels. Such structures also have the advantages of robustness and extensibility.

2.2 Fuzzy controllers Fuzzy controllers are capable of utilizing knowledge elicited from human operators to solve control problems for which precise mathematical models are difficult or even impossible to construct[8,9]. Such a fuzzy controller employs a knowledge base, expressed in terms of relevant fuzzy inference rules, and an appropriate inference engine to solve a given control problem. A general fuzzy controller (Figure 2.2) consists of four modules: a fuzzy rule base, a fuzzy inference engine, a fuzzification module, and a defuzzification module. A fuzzification function is introduced for each input variable to express the associated measurement uncertainty. The purpose of the fuzzification function is to interpret measurements of input variables, each expressed by a real number, as more realistic fuzzy approximations of the respective real numbers. The knowledge pertaining to the given control problem is formulated in terms of a set of fuzzy inference rules.

A suitable defuzzification method has to be selected to convert each conclusion obtained by the inference engine, which is expressed in terms of a fuzzy set, to a single real number. The resulting number, which defines the action taken by the fuzzy controller, is not arbitrary. It must, in some sense, summarize the elastic constraint imposed on possible values of the output variable by the fuzzy set.

3. SUMPY’s Architecture SUMPY conforms to Brooks’ subsumption architecture, and employs fuzzy control in one of its layers. SUMPY currently has four layers or competence modules ----- Wanderer, Compressor, Backup, and Sleepy (Figure 3.1). Each layer both senses and acts on the environment by issuing UNIX commands. The system is organized so that Sleepy suppresses all of its lower level modules and Backup suppresses only the compressor module, while both Backup and Compressor can inhibit Wanderer. SUMPY’s four layers produce the following behaviors: 1. Random walk around the file system; 2. Compress files as needed; 3. Backup files as needed; 4. Put SUMPY to sleep. SUMPY wanders around the file system, compressing or backing up as needed during times when the CPU load is light. SUMPY senses his environment by issuing UNIX commands and noting the response of the system. For example, SUMPY can find where it is at any given time by issuing a pwd command and listening to the response. This sort of purposeful perception is different from that of

Compression Module

Sleepy Backup Compressor

du dd ls

Wanderer ls

Sensors

System disk usage

df UNIX Environment

Actuators

Defuzzification Module

User disk usage File’s size

File’s age

Fuzzy inference Module

Fuzzy Rule Base

Fuzzification Module

Fig. 4.1 SUMPY’s fuzzy controller

UNIX environment Fig 3.1 SUMPY architecture

physical robots which continuously perceive their environment by physical sensors. Each layer issues its own sensory commands for its own purposes, but can use the sensing of other layers. Having selected its next action, a specific layer sends suitable UNIX commands as its actuators to affect the environment. For instance, Compressor might send compress file-name to compress the file file-name. Note that only one action can be executed at a time, other actions which are produced by some lower level modules would be inhibited. Communication between layers is limited so that only higher level layers can issue suppression (unsuppression) and /or inhibition (uninhibition) signals to lower level layers. One layer cannot look inside another and tell what is going on. Lower level layers are not aware of the existence of higher layers. If an inhibition signal is sent to one of the lower layers, it will still produce its next action, but the action is stopped by the inhibition signal. A suppress signal is sent to an input site of a lower level module, being fed through as the input to the layer. Thus, it suppresses the unusual input and produces a replacement until an unsuppression signal comes.

4. Fuzzy Mechanism This section shows how a fuzzy control mechanism can be added to an autonomous agent and discusses some of the issues involved in the design of such a fuzzy controller. The compressor module of SUMPY employs a built-in fuzzy controller (figure 4.1) in a system aimed at achieving better compression behavior. The fuzzy controller decides whether a certain file in a particular user directory should be compressed or not. This decision is influenced by a series of input values coming from a set of sensors.

4.1 Input and output of the fuzzy controller Four variables are defined in Compressor’s fuzzy controller: 1) System disk usage: us , the percentage of the system disk capacity that is occupied. 2) User disk usage: uu The ratio of this users occupied space to that occupied by all users. 3) File’s size: f s , the size of the file being examined. 4) File’s age: f l , the number of days from the file modification date till now. The range of each input variable is normalized to [0,1] for convenience of implementation. The fuzzy controller’s only output is a Boolean variable D that tells Compressor whether the tested file should be compressed or not.

4.2 Linguistic states and fuzzy sets For each of four input variables, five linguistic states are selected and expressed by appropriate fuzzy sets. The five linguistic states are: VS ----- Very Small SM ----- SMall ME ----- MEdium LA ----- LArge VL ----- Very Large For implementation convenience these are applied to all the variables, though “high” and “low” would be more linguistically appropriate for some. Figure 4.2 depicts these states as applied to variable

us , system disk usage. 4.3 Fuzzification function As noted above, each input variable arrives as a single real number. A fuzzification function turns this input into a fuzzy set. The fuzzification function f for each input variable xÎ{ us, uu, f s, f l } is defined as follows: (Its graph is shown in Figure 4.3.)

ì ï 20 ïï ( x f ( x ) = í 3 20 ï 13 ï ïî where xÎ{ us, fus V S 1

0,

0 £ x p ( x 0 - 015 . ); x 0 + 015 . ) , ( x 0 - 015 . ) £ x p x 0; x 0 £ x p x 0 + 015 . ;

( x - x 0) ,

x 0 + 015 . £ x £ 1;

0,

uu, f s, f l }, x0 Î[0,1]. SM

ME

LA

VL

When fuzzified inputs are supplied to the inference module, each of the forty-eight rules are invoked using this input. Each results in a fuzzy set outcome. The Max function applied to all of these outcomes yields the output of the inference module, yet another fuzzy set. Fig. 4.4 illustrates this process using only two rules. Note that the size of the fuzzy sets are determined by left-right position, not by area. The bottom row in the figure depicts the fuzzified input values. The top two rows show the input intersected with the antecedents of two fuzzy rules. The two rules involved in this example are: If

us 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 Fig 4.2 Fuzzy quantization of the range [0,1] for variable us

us = VL and uu = LA and f s = LA and f l = LA

then v = LA

If

us = LA and uu = VL and f s = ME and f l = LA

then v = ME

f(x) 1

0

x 0 -0.15

.

x 0 + 0.15 x0 Fig. 4.3 T h e fuzzification fun ction

.

x

1

4.4 Fuzzy rules 4

Forty-eight fuzzy rules (out of 5 = 625 possible rules) are given to the fuzzy controller in the form of If

us = A and uu = B and f s = C and fl =D

Then v = E where A,B,C,D,E are fuzzy sets that represent linguistic states. One example of such a rules is: If

us = VL and uu = VL and f s = SM and f l = SM

then v = SM This rule says that even if the system disk is almost full, and the user has occupied a lot of space, a very small, very new file will have only a small chance of being compressed. This is reasonable because compression of this kind of file doesn’t help much.

4.5 Approximate reasoning

In each of the two top rows, the minimum height of an intersection is projected to the right to create an outcome fuzzy set from the consequent of the rule. These outcomes are then Max’ed and the result sent to defuzzification module which will then tell SUMPY whether the tested file should be compressed or not.

4.6 Defuzzification There are many different defuzzification approaches. The center of area method is adopted in SUMPY to defuzzify the output of the fuzzy inference module. The defuzzified value D(v) is calculated by the formula (4-2) where v is a 20 element vector which discretely approximates the fuzzy set output of the fuzzy inference module above; each si is a real number; the set of twenty si divides the domain [0,1] of the fuzzy set into nineteen subintervals. From formula (4-2), D(v) can be interpreted as an expected value of variable v. A Boolean output is arrived at by comparing D(v) to a threshold to tell SUMPY whether the tested file should be compressed or not.

å v(s ) ´ s 20

D( v ) =

i

i

i =1

å= v( s ) 20

(4-2)

Backup suppresses Compressor and inhibits Wanderer, and then proceeds down the list of files in the directory backing up as needed. When finished, he unsuppresses and uninhibits them.

i

i 1

5. Implementation: A Fuzzy Agent Due to the subsumption architecture, each of SUMPY’s layers senses and acts and, thus, can be thought of as an agent itself. Hence we can treat SUMPY as a multi-agent system. Here we’ll describe the action of each of SUMPY’s four layers, thinking of each as an agent itself. 1) Random walking (Wanderer) Wanderer senses where it is in the file structure at any moment by issuing a pwd command. He looks around using ls and then decides where to go next. He moves himself to that directory using a cd directory-name command as an actuator. Wanderer has no preference for any directory over another; each move is chosen at random. If Wanderer bumps his own head on the root of the file system, he redecides where to go next. Hopefully, he doesn’t bump his head again. On the other hand, when Wanderer steps on a leaf of the file system and wants to go deeper, he will also bump his head, and will again redecide where to go next. Hence, Wanderer wanders around the file system forever without favoring any particular directory. 2) Compression (Compressor) Many files are stored for long periods of time without being touched. Such files beg to be compressed. However, the decision to compress a file or not can depend on several factors. The following four, as discussed in the previous section, are those considered by SUMPY designers: system disk usage; user disk usage; file size; time since last use. The complexity of these factors and their relations led us to adopt fuzzy control theory for Compressor. As Wanderer wanders into a given directory and issues a pwd or an ls, Compressor notes that he is in a new directory, inhibits further wandering, and looks at the files in the directory using a form of ls. Selecting a file, he then gathers input for the fuzzy controller by issuing commands such as df, du, and ls. The controller then returns a “compress” signal which Compressor executes by sending a command compress file-name, or a “don’t compress.” After following this procedure for all the files in the current directory, Compressor uninhibits Wanderer freeing him to go elsewhere. 3) Backup (Backup) When Wanderer moves to a new directory, Backup notes the result of Wanderer’s pwd, and compares it to his short list of recently serviced directories. If it’s not on the list,

4) Conserve CPU Time (Sleepy) We certainly don’t want SUMPY competing with users for scarce CPU time. This prompted the addition of a fourth layer, Sleepy, who checks the CPU load on a regular schedule and puts SUMPY to sleep when it’s over threshold. Checking CPU consists of a date command, a response, another date command, its response, and a subtraction to note the time taken. This is a crude measure of the load, but it works. Putting SUMPY to sleep consists of suppressing Wanderer, Compressor, and Backup. Sleepy continues to check the CPU usage on schedule. When the load lightens, he wakes the others up by unsuppressing them. The architecture described above has been implemented in Perl, and runs on a local network system (including two Next workstations and two Sun workstations sharing a common file system). There are over 200 users on the network who share a very limited user hard disk space. The system is always in a high load situation, reclaiming disk space a chronic and critical problem for the system administrator. This makes SUMPY an attractive alternative. But there’s the matter of trust. As a system administrator, would you trust SUMPY to wander freely in your file system compressing and backing up at will? You’d probably answer, “Only after a lot of careful testing in more controlled environments.” Tables 1 and 2 (over) show test results based on Wanderer’s 1,000 random “walks” and SUMPY’s 100 “traversals” around a test file system. Currently, SUMPY is being tested in ever decreasingly constrained environments. If he proves docile and reliable, he’ll eventually have the run of the entire file system and experiments will be performed to test his effectiveness.

6. Conclusion Building SUMPY on a subsumption architecture seems to have advantages: Multiple parallel goals: Individual layers can work on their individual goals concurrently. Multiple candidates can compete for control of the system. No early decision need be made on which goal to pursue. It’s the principle of least commitment. Table 1 visiting times

# of directories

0 1 2 3 4

6 18 19 20 14

5 6 7 8 9 10 12 13 16 18 22 23 30 32 36 42 51 195

16 15 4 6 4 2 1 2 1 1 1 2 1 1 1 1 1 1(root)

Multiple perception-action channels: Each layer can issue its own commands to sense and act on the environment in a parallel manner for its own purposes. Extensibility: SUMPY has the property of “plug and play,” which means that a new UNIX maintenance task can be coded separately, can be added at a suitable level to the architecture, and can do its job without modifications to existing layers. Robustness: One layer’s failure won’t effect others unless its suppression and/or inhibition mechanism is involved, which is an unlikely prospect. Other layers can continue to pursue their own goals. Versatility: Individual layers may be controlled by architectures particularly suited to their needs. For example, SUMPY’s Controller layer has a fuzzy information processing ability to handle the fuzzy environment in order to achieve its goals in a real-world way. SUMPY is an ongoing effort. Additional layers will be added, and Compressor’s fuzzy control mechanism will be modified as it matures, perhaps to take into account the status of the user. More intelligent behaviors, such as learning ability (needed if SUMPY begins to deal with users) is expected to be explored and, perhaps, added to SUMPY ----- an administrator’s software agent assistant.

References [1] Brooks, Rodney A., “A Robust Layered Control System for a Mobile Robot,” IEEE Journal of Robotics and Automation Vol. RA-2, No.1, March, 1986. [2] Brooks, Rodney A., (1991), “Intelligence without Representation”, Artificial Intelligence 47:139-160. [3] Brooks, Rodney A., “Coherent Behavior from Many Adaptive Processes”, in Dave Cliff et al., eds., Table 2 Directory name R/ R/P R/P/P R/P/S R/I R/C R/S

# of Files 34 24 1 33 0 8 0

Visiting times 36 3 1 1 1 2 3

# of Compress 7 0 0 0 0 0 0

# of Backup 32 6 1 32 0 7 0

R/S/C R/S/C/O R/S/C/C R/S/C/R R/H R/H/C R/H/I R/H/CGI R/H/D R/H/P R/J R/O R/L R/OBJ R/PUB R/PUB/F R/A R/D R/B R/T TOTAL

3 0 5 3 18 18 7 8 3 3 0 6 0 1 2 3 1 2 1 2 186

8 1 3 2 11 2 2 1 1 4 2 3 2 1 3 2 1 1 1 2 100

0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 2 10

3 0 5 3 18 18 7 8 3 3 0 6 0 0 2 3 1 2 1 2 163

Proceedings of the Third International Conference on Simulation of Adaptive Behavior (SAB-94). 1994. [4] Eichmann, D., “Ethical Web Agents,” Proceedings of the Second International Conference on the World Wide Web, Chicago, IL, October 19-21, 1994. [5] Etzioni, Oren etc., “OS Agents: Using AI Techniques in the Operating System Environment,” University of Washington, 1994. [6] Franklin, Stan, “Artificial Minds,” Cambridge, MA: MIT Press, 1995. [7] Hayes-Roth. B., “An Architecture for Adaptive Intelligent Systems”. Artificial Intelligence: Special Issue on Agents and Interactivity, 72:329-365, 1995. [8] Klir, George and Bo Yuan, “Fuzzy Sets and Fuzzy Logic,” Upper Saddle River, NJ: Prentice Hall Press,1995. [9] Kosko, Bart, “Fuzzy Thinking,” Hyperion Press, New York. 1993. [10] Maes, Pattie, “Modeling Adaptive Autonomous Agents”, Artificial Life, Vol. 1, No. 1/2, Cambridge, MA: MIT Press, 1994. [11] Ray, Thomas, “An Approach to the Synthesis of Life,” Artificial Life II, edited by C. G. Langton, etc., Addison-Wesley, 1991. [12] Sahota, Michael K., “Action Selection for Robots in Dynamic Environments through Inter-behavior Bidding,” in Dave Cliff et al., eds., Proceedings of the Third International Conference on Simulation of Adaptive Behavior (SAB-94), 1994. [13] Steels, Luc, “Emergent functionality in robotic agents through on-line evolution,” Artificial Life IV, pp. 8-14, Cambridge, MA: MIT Press, 1995.

Suggest Documents