Tuesday, August 3, 2010

Fuzzy Logic Application in Software Engineering

I finally found just the right book for me on Fuzzy logic. It’s Fuzzy Logic With Engineering Applications 3rd Edition, by Timothy Ross, published by Wiley. Most of the titles I checked into fell into one of two categories: popular books with no detail, or highly theoretical mathematics books. Timothy Ross’s book, like the fuzzy logic description of the three bears’ porridge, was just right. There is enough theory to help one understand the concepts in some depth, yet with an emphasis on the concrete rather than the theoretical. And the math is kept at a level comfortable to undergraduate level engineering students. The coverage is broad as is the range of examples, which are drawn from (among other fields) mechanical, chemical, electrical, and civil engineering. Add to this the fact that I asked for – and got it – as a birthday present, and what could be better?

Reading it has prompted me to dabble in a bit of fuzzy logic programming in F#. But I’ve also been keeping my eyes open for potential applications of fuzzy logic, even if only as a thought experiment. Here’s one I came up with that relates to software engineering.

Complex, dynamic software systems often build up a certain amount of deferred work. For example: garbage collection in operating environments, indices in databases, temporary caches in rule-based systems or graphics software which must be integrated into long-term data, etc. It often makes sense to schedule these according to external criteria; for example, when a workstation is idle, at an off-peak time, or when a server is restarted.

If one had all the data required, some sort of optimized scheduling algorithm might be feasible. The trouble is, the interaction of the need and the external factors can be frustratingly inexact. The estimated time to complete a task may be approximate, off-peak periods can have unexpected demands, etc. On the software engineering side, calculating and maintaining exact estimates can present a burden which might ultimately cost more than the saved CPU time.

So it seems to me that this is a likely candidate for a fuzzy logic solution. In fact, I’m guessing there’s probably work, and perhaps even patents, which already pertain to this. For me it’s mainly a thought experiment (and likely to remain one) so I haven’t really done any research. But here’s how I might start with such a design.

1) Give modules a standard mechanism for requesting internal maintenance time from a supervisor module. This could be either an API call, or something more loosely coupled, like an asynchronous message. At minimum, it might contain two pieces of information: some measure of the time required to complete the maintenance, and some indication of urgency. These could be very simple, perhaps just a few fuzzy categories each:

Time: short, medium, long.
Urgency: low, medium, high, critical

(Along with this might be various kinds of bookkeeping data, such as a tag to identify this request, etc.)

2) Give the supervisor module some way of communicating back at the point where time is available for maintenance. This might be as simple as a few fuzzy categories representing the time a module should use (both for the supervisor’s use and to be sent back to the module), and a few representing the scheduling window (for internal use by the supervisor):

Time: short, medium, long.
Schedule: immediate, sooner, later, off-peak.

3) Use fuzzy logic rules to implement the scheduler. For example:

IF short AND critical THEN short AND immediate
IF long AND critical THEN long AND sooner
IF long AND medium THEN long AND later
IF long AND low THEN long AND off-peak
Etc.

By definition, the incoming data is already fuzzified. Defuzzification would entail using the rule output to schedule and prioritize the maintenance, either deterministically or using a second fuzzy system.

Anyway, that’s it: my thought experiment on fuzzy logic software scheduling. If anyone is aware of such a system actually in use, or has improvements to my experiment, I’d be happy to hear about it. And be sure to check out Timothy Ross’s book; it’s in its third edition, so the current or earlier editions should be available at many technical bookstores or college libraries. Or, if you’re already sure it’s what you want, do what I did and ask for it for your next birthday, lol.

-Neil

No comments: