WPI Computer Science Department

Computer Science Department
------------------------------------------

WPI SiFA Project - Sailboat Design


------------------------------------------

What I hoped to accomplish

My intentions were to make a contribution to the development of the SINE system being developed by Bert Dunskus by producing a Sail Boat Design system that was implemented using the SINE source code.

------------------------------------------

What I got out of the Sail Boat design project?

The sail boat design project (SBD) was a chance for me to be to introduced to one field of AI in Design research. It has been invaluable to me to be involved in this project and to learn something of the problems which are being worked on, the nature of the systems which are being produced and the tools used to produce these systems.

In this project, I have been reviewing, looking over the shoulder, and using code from some of the research work of Bert Dunskus. Bert has been putting together a system of Single Function Agents (SiFA's) with the unique characteristic that these agents have negotiation knowledge and facilities built in. These facilities, organized in his SINE architecture, are intended to give the agents more robust and less fragile design capabilities.

------------------------------------------

The domain of the sifa design project

The design task which I chose for the SINE system was the design of a "sailboat". The sail boat I was aiming to design, would a boat in which a single value from a range of values would be chosen for a number of parameters. These parameters have included:
  • Hull Design Type
  • Sail Design Type
  • Sail Material
  • Hull Material
  • Number of Sails
Each one of these parameters have the following categories of values:
Hull Design Type
  • SURFBOARD
  • SLOOP
  • FRIGATE
Sail Design Type
  • JIB
  • MAINSAIL
  • SPINNAKER
Sail Material
  • CANVAS
  • MYLAR
  • KEVLAR
Boat Material
  • BALSA
  • FIBERGLASS
  • STEEL
Number of Sails
  • SINGLE MASTED
  • DOUBLE MASTED
  • TRIPLE MASTED
Each of the parameter values have a slew of associated properties/facets, i.e.:
Hull Design Type-Sloop
  • cost 70
  • draft 30
  • floatation 20
  • durability 60
With the values of the facets being for the most part simply a relative value on a range from 1 to 100. The values of these facets are to be used to perform algorithmic estimations, evaluations and selections.

These parameters and their values have been chosen for their simplicity. I hoped that by choosing an easy design problem, I would be able to avoid difficulties that I might have with the design domain and focus more on the domain of the problem solving/ negotiating capabilities of the SINE agents( at least as a start).

I have tried to get the system designing while adding the minimum additional rules over the domain independent rules which are part of the SINE architecture. Rules that I have implemented up to this moment have been algorithmic rules. i.e. estimating t he speed of the boat given the parameter values for the number of sails, the sail type, and the hull design type.

Obviously I chose not to design an optimum sailboat but to design a sailboat that one would design, if given the above parameters, their values, their facets and some common sense. I believe that this is the more appropriate domain for the SINE system, for the capabilities of SINE architecture should be significant in its ability to handling more common sense designs tasks. Eventually, it would will be interesting to see how the sailboat design project continues to perform as more parameter values and more parameters are added to the design domain.

------------------------------------------

Current State of the Implementation

Currently I have a large number of agent objects. When one considers producing an agent for each of the cross product of the three aspects of an agent (point-of-view, function, target) in the sail boat domain, there are a large number of agents to be produced.

Targets

  1. Sail Boat
  2. Hull Design Type
  3. Sail Design Type
  4. Hull Material
  5. Sail Material
  6. Num Sails

Functions

  1. Selector
  2. Estimator
  3. Suggestor
  4. Critic
  5. Evaluator

Points of View

  1. Cost
  2. Speed
  3. Durability
  4. Cargo
Of the 100 possible agents, I have created instances of 60 agents.

Of those rules that a will need (mostly the algorithmic estimations and evaluations), I have a fraction of the rules needed for the full implementation of the sail boat design. I have used the domain independent rules to negotiate conflicts between agents. Presently my attention is focused on understanding the semantics of the domain independent conflict negotiation message being passed between agents.

------------------------------------------

Conflicts that I have planned for implementation

Some of the interesting conflicts between agents include:

Any of the conflicts where the cost versus performance is an issue:

Any of the conflicts where sub optimal values are chosen for two or more design parameters which together offer an improvement over the optimal decision chosen for either one of the individual design parameters.

Any conflict where one value can be traded for another:

------------------------------------------

Impressions of the SIFA system

While not having gotten a working design system completed, I am unable to give a comprehensive appraisal of the SINE design capabilities.

The domain independent conflict resolution operates on a set of expected objects, preferences, constraints and parameters. I think it is a good idea to map out my knowledge in terms of these three objects. I have the impression that if I make sure that instances of these object exist in the appropriate facets of each of the domain dependent agents, I can count on the domain independent rules to solve conflicts between agents in the absence of domain dependent knowledge. It is only the estimators, evaluators and the advisors that deal with domain dependent knowledge.

It also seems necessary to in most cases express the knowledge in relative terms. Rather than state an explicit correlation between scenario and decision, it is better to state the knowledge in terms of relative preferences, relative estimations and relative evaluations. It is only when a particular design instance is created that scenario specific constraints will be created to a small extent by the user and to a larger extent by the SINE negotiation process. As I look back on some of the knowledge when I had originally sketched for some of these agents, I realized that to much of the knowledge is in the form of rules(rules based knowledge) and not enough of it is in the form of objects(data based knowledge).

One very nice aspect of the SINE architecture is that while I might have a large number of agents, I will not need to add a large number of rules. Due to the object oriented SINE system design by Bert, many of the agents conflict resolutions facilities has been coded in domain dependent modules and inherited through subclassing.

------------------------------------------

Time Spent on getting familiar with the SINE architecture

I have spent an average of 6 hours a week reviewing and learning about Clips and the SINE system over the past two months. As I did not know anything about the Clips syntax and environment when I first began this project I have spent roughly 40% of my time dealing with syntax and debugging issues.

I have spent 30% of this time going through the code and trying to follow the logical and procedural flow. Programming in clips, especially using the object oriented extensions in clips 6.0, while increasing the programming flexibility and power has made it more difficult to comprehend the functionality of the code. Due to the nature of the inference engine as well as the intricacies of the object oriented inheritance hierarchy, it is difficult to follow the logical flow. This also may be compounded by the distributed nature of the knowledge in the SINE system. For end users of the SINE architecture, I can see a need for slightly higher level interface to the SINE architecture. I'm sure after several design projects have been completed, that this interface will become more apparent.

The final 30% of time I have spend on this project has been in reviewing papers, slides and asking questions of Bert.

------------------------------------------

Miscellaneous Questions

  1. Is there a SIFA agent which would be a "comparer'? I.E. I think that one important design process, is comparing two designs and choosing the one that is better than another.
  2. Does the need for agents which considers two or more targets ever exist? I.E. A Boat Speed/Durability Evaluator which would evalute the design based on the combined target of Speed/Durability or would this be handled by making a new target say the ratio of cost to speed(price/performance) and using the agent in the negotiation.
  3. A concern that I have but is not founded in experience would be difficultly in debugging a knowledge base of this sort. For those design tasks like the one I have chosen it may not be a problem to debug the system. In cases where the design parameters are more epistatic, it could be more quite difficult.

------------------------------------------

SBD Project Source Code

Location
The SBD source is divided into two directories
  1. my-src
  2. negotiation
The my-src directory contains source all the source code that I have written

The negotiation directory contains the source code the Bert has written and which I have modified slightly to run in the Clips PC version.

To load the SBD Project source run the batch file sifa sb-init.bat in the my-src sub-directory.

This page created by Phil Tomlinson


[Feedback] [Search Our Web] [Help & Index]

[Return to the WPI Homepage] [Return to the CS Homepage]

dcb@cs.wpi.edu / Wed Sep 11 21:22:10 EDT 1996