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.

• Hull Design Type
• Sail Design Type
• Sail Material
• Hull Material
• Number of Sails

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

Hull Design Type-Sloop

• cost 70
• draft 30
• floatation 20
• durability 60

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.

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 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.

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.

Location

The SBD source is divided into two directories

1. my-src
2. negotiation

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