STRICT: A blackboard-based tool supporting the design of distributed PPC applications

Expert Systems With Applications. Vol. 7, pp. 131-146, 1994 0957-4174/94 $6.00 + .00 Printed in the USA. © 1993 Pergamon Pre~ Ltd.

STRICT: A Blackboard-Based Tool Supporting the Design of Distributed PPC Applications

STEFAN KIRN

In.rut flit Wirtsehafl.sinformatik, Wcstf~sche Wilhdms-Universit~t, D-4400 Miinster, Germany

JORG SCHNEIDER

Department of Production Management, FernUniversita't Hagen, D-5800 Hagen, Germany

AbstractDModern applications (CIM, CSCW, etc.) impose a rapidly increasing demand for very flexible, mostly distributed solutions. This, together with the challenge of Open Systems, assigns more and more importance to the architectural decisions during systems design. However, the capabilities of conventional types of distributed systems seem to be restricted to the lower levels of interprocess cooperation. So, the integration of collaborative software systems calls for intelligent distributed architectures. This paper presents the basic concepts of an experimental advisory system called STRICT (Selecting The Right architeCTure). In the long term the STRICT project aims at developing a tool supporting the selection of the "right" (Distributed AI-) architecture, that is, that architecture which fits the application's requirements best. In that sense the final STRICT system will be definitely more than just a simple advisory tool. It is to serve as an investigation and development environment providing smart facilities to experiment with (DAI-related) architectural knowledge.

1. INTRODUCTION

MORE AND MORE, modern applications (like CIM, CSCW, Office Information Systems, Design Environ- ments, etc.) ask for flexible, mostly distributed solutions based on a set of intelligently cooperating software agents. The design requirements that are imposed by such applications relate quite closely to Hewitt's Open Systems (Hewitt, 1985, 1986). This makes decisions on distributed systems architectures in the design phase more and more significant. However, conventional solutions are confined to the lower levels of interprocess cooperation only. Thus, the need arises to apply distributed AI (DAI) concepts to developing appropriate distributed systems architectures. Unfortunately, most of the concepts that have been provided by DAI so far remain to be well-investigated and well-evaluated. So, today it is still a very difficult task to decide on the "right," that is, the best-suited, DAI-based software architecture.

Requests for reprints should be sent to Stefan Kirn, Westflllische Wilhelms-Universit~t MOnster, Grevener Sir. 91, D-4400 Miinster, Germany.

131

In dealing with that question we are faced with several important aspects that must be clarified before- hand. What are the main characteristics of DAI-based software architectures (DAI architectures)? Can we identify generic DAI architectures7 If so, how can an appfication be mapped onto such a generic architecture, and how is it to be instantiated when aiming at refiable systems with an acceptable performance?

In this paper we present the basic concepts of the experimental advisory system STRICT (Selecting The Right architeCTure). The long-term purpose of the STRICT activities is threefold: (1) to develop a tool supporting the selection of the "fight" (DAI) architecture, that is, that software architecture that is most suited to the requirements arising from a specific application; (2) to improve the knowledge on DAI-hased software solutions in order to enhance their applica- bility to distributed systems design; and (3) to develop formal models of generic DAI architectures and of generic applications with the aim to employ them both in the selection of architectures.

The STRICT system shall provide smart investigation facilities for the subsequent project phases two and three. Being aware of the large number of open questions, we started with the experimental design of

132 St. Kirn and J. Schneider

distributed Production Planning and Control Systems (PPC). As PPCs comprise a rather well-known application domain today, they also provide for an experimental investigation methodology.

The paper is organized as follows. Section 2 provides a discussion of related work. Section 3 provides a complete walk through the process of PPC design. Section 4 presents the architecture of the STRICT design consultant. One of the important issues there is the case- based approach that has been applied to one of the STRICT knowledge sources. In particular, we consider case representation and indexing, memory organization by cluster analysis, and the integration of a case-based reasoner with a blackboard architecture. Section 5 summarizes results and open questions.

2. RELATED WORK

2.1. Distributed AI

This section gives a summary of recent work on how to classify DAI systems (Sridharan, 1987; Klett, 1989; Schupeta, 1992). We distinguish among the basic ele- ments that constitute any DAI system: the overall architecture, the agent model, the cooperation concepts, and the coordination mechanisms.

Using the term DAI architecture, we address the global structure and characteristics ofa (DAI) system, addressing its behavior as a whole. To keep separate things separate we clearly distinguish between the architecture of a system and the coordination mechanisms that are applied to it.

Supervisor Systems (SVSs) are characterized by a centralized control component that schedules all global activities (task allocation, cooperative problem solving, constructing the results). Because none of the agents possess any global knowledge, the supervisor acts as a master.

The main characteristic of Blackboard Systems (BBS) is the blackboard itself (being a centralized data structure, visible from all agents). All iterations of a cooperative problem-solving process must be docu- mented on that board. Any information on the blackboard may be considered as a task. Each agent capable of processing that task generates a bid to be written on the blackboard as well. Processing the set of information on the blackboard (bids, control information, in- termediate or final results) is accomplished by an intelligent scheduler. It allocates tasks, recognizes conflicts, and decides on how to continue the cooperation process.

In contrast to the two concepts above, there is no centralization at all in Contract Nets (CN). The agents in a contract net are completely autonomous. They do not share any resources and do not possess any global knowledge. Using a contract protocol, they cooperate

in a flexible, task-dependent way. Typically, interagent coordination is based on bilateral negotiations. Typically, so-called Not Explicitly Coordinated Systems (NECS) are build up by rather complex autonomous agents. If necessary, they exchange data via a centralized data base. NECS do not possess any explicit mechanisms (task decomposition and allocation, synthesis of results, etc.) to support cooperative problem solving further, So, compared to the architectures described above, their cooperative capabilities are limited.

Considering the different styles of cooperative problem solving, DAI mostly distinguishes between distributed problem solving (DPS) and muitiagent systems (MAS). In DPS the agents are faced with problems that are beyond their individual capabilities, so that they must cooperate to achieve their goals. In MAS, the agents share an environment in which they act collec- tively to identify and resolve conflicts mutually utilizing each others' workings. Consequently, MAS research focuses on coordination (Smith & Davis, 1981; Ro- senschein & Genesereth, 1985; Ferber, 1989), while DPS research primarily investigates problems like task decomposition/allocation and solution synthesis (Bond & Gasser, 1988).

As different problem types may ask for different types of solution strategies, there is some evidence that this holds for cooperative problem solving as well. However, there is no systematic discussion of cooperation styles (or cooperation types) in DAI. Therefore, we list only some of them in order to outline the concept and to give some idea of the complexity involved. First, we distinguish between distributed, multiagent, and federative problem solving (Bond & Gasser, 1988; Sheth & Larson, 1990; Kirn, 1991), teamwork (Cohen & Levesque, 1991), problem solving by committee (Clearwater, Huberman, & Hogg, 199 l), etc. Second, we mention concepts like task sharing, result sharing, and knowledge sharing (Smith & Davis, 1981). Other kinds of distinctions may be guided by the interagent relationships (horizontal, vertical, master-slave, etc.).

Coordination is one of the most important topics in DAI research. Out of the numerous proposals two of them play a major role: Negotiation and Planning. Re- cently, there have been attempts to integrate these two. For this purpose, sophisticated collaboration capabilities are to be added into complex intelligent systems (Kirn, 1991; Werkman, 199 l).

Negotiations (Smith, 1979; Davis & Smith, 1983) provide MAS with a powerful technique to coordinate agents toward a common global goal. Conry, Meyer, and Lesser introduced multistage negotiations to overcome the problem of incomplete knowledge (Conry, Meyer, & Lesser, 1986). They allow agents to bargain on problems with a restricted global significance. They guarantee the overall system to converge toward a global consistent solution. Kuwabara and Lesser ap-

STRICT 133

plied a multistage negotiation protocol to resource allocation conflicts in a distributed network (Kuwabara & Lesser, 1989). ]_fiasfi, l_Aasri, and Lesser introduced cybernetic facilities (l_Aasri, l_Aasri, & Lesser, 1991). Their agents generate goals to be communicated and allocated to achieve a globally consistent solution. Goals not being allocated are reorganized to start a new cycle of goal formulation, communication, allocation, and achievement. This idea seems to be a very promising one. However, they did not discuss how agents can decide on which one of them may process a goal and how they can assess the achievement of a goal after having processed it. Also, they cut all questions related to dynamic goal reorganization.

Closely related to negotiation, a lot of research deals with planning (see Bond & Gasser, 1988). The basic idea is that agents coordinate their behavior by exchanging their local plans before they move into action. Usually, authors distinguish between multiagent planning (MP) and distributed planning (DP). While MP requires one agent to have all knowledge to generate the global plan, DP requires all agents to act together on one single global plan. To overcome some of the shortcomings of both approaches, Durfee and Lesser proposed the concept of partial global plans (PGPs) to specify coordinated actions effectively for groups of agents (Durfee & Lesser, 1987). In this approach, coordination is a part of each problem solver's activities and is interleaved directly with local problem solving.

There are still many other approaches to the coordination problem. Some of them are related directly to the underlying DAI architecture (blackboard-based coordination, shared data base). Others can be expected to become useful for different types of architectures (e.g., the focal points approach, Rosenschein & Kraus, 1991, or the concept of arbitrators, Werkman, 1991).

Another important field of discussion is comprised of agent models. They span from rather simple agents that are not intelligent at all (e.g., sensors) up to so- called social agents that live in artificial worlds and are expected to include (besides their domain knowledge) something called "social intelligence." Sometimes, such types of agents are used to simulate the behavior of human groups and even societies. Finally, we have to consider links between the overall architecture, the style of cooperative problem solving to be performed, the coordination mechanism to be applied, and the agent model to be used.

2.2. Case-Based Reasoning

Case-based reasoning (CBR) makes use of past experiences to solve a new problem. In general it works as follows: The similarity of the new problem to a specific known problem (case) is recognized; then the solution

of the case is adapted to the new one. The process of identifying a case that is similar to the problem at hand involves two subproblems: 1. definition of indexing mechanisms for efficient re-

trieval 2. measuring or assessing the similarity between the

new problem and a retrieved case (a more funda- mental problem that occurs because CBR works with a lot of different dimensions that often cannot be described exactly) In CYRUS (Kolodner, 1983a, 1983b), indexing is

combined with the assessment of similarity. It extracts indices to identify appropriate cases for the problem at hand. CYRUS provides the user with the first case that is accessed when evaluating the index structure. However, one problem within CYRUS is that large case bases lead to rapidly increasing numbers of indices, thus making search very expensive.

MEDIATOR improves the concept of case indexing further by using past problem solving failures (Simpson, 1985). All possible indexing paths are followed up. If more than one case is retrieved, a particular procedure ranks them, thus selecting the most similar case to the new problem.

HYPO retrieves not only the "best" case, but all cases that seem to be similar (Ashley, 1987). Cases are indexed by their relevant dimensions. The most similar cases according to these dimensions are identified and retrieved.

Unlike HYPO, CHEF is a case-based planner that can learn (Hammond, 1989). Modifications of the knowledge base are carried out to avoid already known failures in future. CHEF has contributed some valuable ideas to the development of the STRICT case base knowledge source, as well.

One of the goals of the STRICT activity is to learn about CBR. Thus, the case base will change dynami- cally. In such a context the following additional aspects are of interest: 1. learning about indexing 2. learning about identifying attributes that are rele-

vant for the concept of similarity 3. learning about building typical cases/generalizations It is suitable for these learning purposes that the STRICT-system retrieves not only the "best case," but all cases that may be "similar."

3. DESIGNING PRODUCTION PLANNING AND CONTROL SYSTEMS

3.1. (Distributed) Production Planning and Control Systems

Production can be defined as transforming input materials into outputs. For economical production it is


important that this process is planned and controlled with respect to specific goals by an information processing system (PPC). The most relevant decision problems occurring in this context are the planning of the product mix, requirements analysis, lot-sizing, and scheduling. Simultaneous planning of these problems is required to get optimal results. Because this kind of problem solving is rather complex in most cases, PPCs perform similarly to distributed (hierarchical) planners. This means that they usually decompose the overall problem into separate, strictly ordered (independent) subtasks. For each of them the agents generate a partial (local) plan that will be negotiated then in order to construct a globally consistent solution. To date, different PPC concepts have been considered in the literature (Hahn & Lal3mann, 1989).

Not all possibilities of a plan on a lower level can be anticipated at the higher levels. Thus, the previous planning stages must modify their plans when their assumptions cause inconsistencies at the subsequent levels. This requires that the lower level planners be able to communicate plan inconsistencies with the higher level planners. Therefore, top-down problem- solving must be coupled with bottom-up reaction. In consequence, in PPCs, planning means an iterative process of initial planning, identifying conflicts between partial plans, recovering feasibility, and new consis- tency checking. So, tasks cannot be accomplished any longer in a fixed order. Instead of this, a coordination mechanism is needed that selects the partial planners according to the actual state of problem solving. What follows is that PPCs are inherently distributed and, thus, call for distributed problem-solving techniques. New production technologies (flexible manufacturing systems) and real-time scheduling requirements in- crease the demand for distributed systems further. Some work has been done already in developing distributed solutions (Fox & Smith, 1984; Fox, 1986; Kurbel, Mertens, & Scheer, 1989), but the results are still far away from practical use. However, they give us a strong indication that the paradigm of distributed problem solving must be considered as a suitable approach to future PPCs.

3.2. Requirements Specification: Issues and Problems

Supporting the design of PPC systems needs an underlying PPC model that helps the user to specify his or her concrete demands. Essentials on the theoretical foundations of production planning and control systems have been provided by Fandel, Dyckhoff, and Reese, (1988), while Van der Linden and Griinwald (1980), Schmitt, Klastorin, and Shtub (1985), and Griinwald, Striekwold, & Weeda (1989) have done stimulating research on classifying production planning

and control systems. The following list gives an overview on those attributes that we will use to represent PPC systems.

Any user (PPC customer or PPC designer) will be asked for these aspects in the STRICT communication process:

1. volume of production (number of products or production groups)

2. number of production stages needed for completion

3. number of alternative machines per stage 4. number of different operations per machine 5. routing restrictions 6. market dynamics 7. uncertainty and irregularity of the demand 8. specification of products (from standard products

via variants to specified products) 9. product-complexity (from raw materials to com-

plete systems) 10. diversity of products 11. number of criteria to be optimized 12. number of planning methods (algorithms to solve

a specific planning task) 13. quality estimation of the algorithms (derived by

practical experience, simulations, or scientific analysis)

14. variety of order in which the algorithms will be called

These aspects define conditions that limit the appli- cability of any PPC system. 15. specification of the planning and control tasks (for

any module of a PPC systemm): a. criteria to be optimized b. algorithms to solve the partial problems c. coordination mechanism to integrate the partial

solutions Item (15) represents the goals of the design process.

Users can specify their planning requirements by telling STRICT the requested algorithms. STRICT also provides its users with facilities to adopt the problem-solving process according to their current preferences. For example, a user who wants only to install the module release of production orders can tell this to STRICT by weighting the importance of all other modules with zero. While PPC users are more interested in practical aspects of their PPC systems (e.g., in data management), the issue here is on the designer's view, especially the question of which of the production control concepts should be used for implementation.

To date, only little work has been done in developing adequate descriptions of PPCs. Nevertheless, some

Usually the modules of a PPC system divide into: master production scheduling, material requirements planning, capacity requirements planning, release of production orders, detailed scheduling, production data acquisition.

STRICT 135

parts of PPC systems are well-formalized already. For example, scheduling problems can be described by using the following "generic description":

2. It must be a deep model in that it provides user- adaptable communication abilities.

GENERIC_TYPE scheduling

BEGIN

n

m class cond goal

END;

{number of jobs to be scheduled} {number of machines to be considered}; {type or class of the problem}; {specific constraints like precedence structures or data-restrictions}; {goal that has to be optimized};

So it can be determined what kind of scheduling-algorithm shall be applied. For example, Johnson's algorithm delivers optimal results for the following types of scheduling problems:

The latter means that the knowledge source supports the user dialog with STRICT by changing its dialogue

SCHEDULING_CLASS johnson

BEGIN n

m - - 2 class = flow shop cond goal = minimizing makespan

END;

Working out a similar practicable description of whole PPC systems is necessary for a reasonable implementation of the PPC model knowledge source.

{number of jobs}; { number of machines}; {type or class of the problem }; {constraints} {goal to be optimized};

3.3. PPC Models and User Dialogue

Called up by a user, STRICT first activates the PPC model Knowledge Source to request a detailed description of the intended application (goals, conditions to be satisfied, etc.). Using case-based terminology, the conditions to be satisfied define the specific context of each particular application.

The PPC model Knowledge Source is a conventional expert system with hybrid knowledge representation facilities (rules, object-oriented, constraints). The purpose to develop an application model is twofold: First, it supports the system-user dialog by defining the application's characteristics. Second, i t provides for modeling context knowledge on the user's application definition that is used during the inference process.

The PPC model requests the description of the PPC system the user wants to design. This description has to base on a model that satisfies the following two conditions: I. It must be an implementable generic representation

of PPC (formal aspect).

behavior dependent on the answers of the user (hy- pothesizing that answers of high quality reflect high- level knowledge).

Based on a deep knowledge representation, the PPC model knowledge source works as follows: 1. It asks the user for specific values of attributes. 2. It aggregates the attributes, thus providing five mea-

sures that relate to DAI architectural issues (production complexity, production flexibility, methodological complexity, methodological flexibility, and methodological quality). Let us consider an example of how answer-directed

questioning can take place. First STRICT asks for the number of products; if this number is small (for example: 1), then questions about number of production stages and machines per stage are omitted because the underlying aggregated attribute "Production complexity" becomes "small," too. If the answer given on the first question is a large number, STRICT asks for the number of production stages. Depending on the answer to this question, there are (at least) two possibilities: only few stages (e.g., 1 again) leads immediately to "'small" production complexity, while a lot of stages requires further questions about the number of alternative machines per stage, etc. In this way, the user


dialogue is guided by meta-rules that are a part of the underlying PPC model.

To summarize, the PPC model knowledge source supports the definition of the application-specific requirements, and it abstracts them to

indexp~, := (id) (goals)* (conditions)*,

which is returned to the blackboard, thus activating the PPC case-base knowledge source.

3.4. Case-Based Design

STRICT uses a case-based approach to the task of designing PPCs. Designing from cases means remem- bering successes so that they can be reused, remem- bering failures so that they can be avoided, and re- membering repairs so that they can be reapplied (Hammond, 1989). From the case-based approach we expect to avoid the problems that arise from conventional knowledge representation formalisms. The most important advantages of such an approach are that case-based systems run fast (selecting solutions instead of generating them), and they augment themselves by learning from successes and failures. Finally, they provide users with a rather natural way to solve problems. As the case-based approach brings up most of the power of STRICT, we discuss the most relevant issues (case representation, indexing, memory organization, learning, reasoning) in more detail in section 4.3.

Using indexpr, i that has been constructed from the user's requirements specification, the PPC Case Base retrieves a similar case from its case base to modify it in order to derive a solution for the problem at hand. From this (new) case it then derives those pieces of knowledge that are considered to be important when deciding on the architectural approach to a new PPC. Again via the blackboard these attributes are transferred to the DAI Toolbox KS. This knowledge is used to improve its local problem-solving performance.

3.5. Constructing the "Right" (Distributed AI) System

The final step of the design process has to suggest which one of the Distributed AI architectures shall be applied to the distributed PPC's design. As our current DAI knowledge is still sparse, this suggestion needs to be evaluated in order to approach two aims: I. to improve the knowledge about DAI-based solu-

tions to the design of distributed systems (i.e., to learn about their advantages/disadvantages compared with conventional solutions)

2. to improve the reliability and validity of the STRICT design suggestions in future STRICT divides into four generic DAI system types:

Supervisor Systems, Blackboard Systems, Contract Nets, and Not Explicitly Coordinated Systems. Based

on recent work there are a lot of criteria available that may help when describing instances of any of these DAI system types.

Proceeding from the discussion of related work, we assume that any DAI system is built up from four basic components: overall architecture, agent model, cooperation style, and coordination mechanism. The following paragraphs introduce how we currently classify these system components. This discussion provides two insights: I. Most of the knowledge that is currently required to

decide on the "appropriate" type of component can be gained easily directly from the user or by in- specting the PPC case base.

2. The attempt to classify these four system components (and, subsequently, to relate them together) imposes a lot of new questions that (to the best of our knowledge) are not yet addressed in depth in the literature. Primary architectural issues of DAI systems refer to

the systems' reliability, decentralization of control, flexibility (ease of modifying the system), selectivity (probability to select the most suitable agents), degree o f coupling, and system model (number of cooperating agents). The STRICT agent model is made up by the agents' autonomy, the degree of cooperation (relation: cooperative to stand-alone problem solving activities), the agents' granularity and dynamics (fixed- vs. auto- didactic), the resources they have at their disposal (restricted vs. ample), their global knowledge, and the complexity o f interactions.

Different kinds of problems may require different cooperation strategies. However, we still lack a well- defined taxonomy of cooperation concepts. So we mention only a few of them to give readers a first understanding. Prominent distinctions are: (1) distributed, multiagent, and federative problem solving; (2) teamwork and problem solving by committee; (3) task sharing, result sharing, knowledge sharing; (4) interagent relationships (horizontal, vertical, master-slave). Pri- mary issues are: global coherence; a priori planning of the collaboration, (global) type of problem-solving strategies (hierarchical, decomposable, parallel), and how to determine the optimal solution.

Within STRICT these attributes of DAI systems are used to suggest a solution to a design task at hand. This requires only that we describe the new application in DAI system terms (see Fig. 1) and that we specify the expected behavior of the new system. In this way we can try first to find a DAI-based solution. Second, we compare its expected behavior with the system requirements that were specified earlier. Third, a prototypical implementation can be used to verify the design suggestion of STRICT that, at the same time, directly improves the knowledge about DAI concepts. This is how the STRICT system currently applies its DAI knowledge to derive a design suggestion. However,

STRICT 137

minor low average higher high

SVS . ~ . CN, NECS

system model NECS

flexibility SVS

degree of coupling

decentralization of control

selectivity

agents autonomy

agents granularity

agents global knowledge

global coherence

a priori planning of collaborations

finding the optimal solution

NECS, CN . _ : ~

s

CN

f " ~ CN, NECS

SVS

CN, NECS

centrality of coordination

NECS SVS

S .... "" I - CN, NECS

7Y svs, o CN, SVS NECS

NECS

NECS, CN SVS

~ . ~ . . . ~ . ' £ ~ " ~ " NECS, CN SVS

NECS, CN ~ SVS

high minor low average higher

FIGURE 1. How to select DAI architectures from an appUcation profile.

this style of problem solving is only a first attempt. Much research is still needed to detail our knowledge on DAl-based software solutions and, thus, to improve the results of the STRICT system as well.

When dealing with the selection of an "appropriate DAI architecture," one question immediately arises: How is "appropriate" to be measured? Obviously, most of the criteria presented above include qualitative knowledge; only few of them (e.g., reliability, system model) can be defined on the basis of a metric. Fur- thermore, for different types of applications (e.g., PPC, CSCW, OIS, CAD/VLSI design, etc.) there may be differences in the interpretation of some of the attributes (e.g., agent's granularity). In consequence, using these pieces of architectural knowledge assumes the avail- ability of an application model. Within STRICT the PPC model knowledge source is due to provide this kind of knowledge.

4. IMPLEMENTATION: THE STRICT DESIGN CONSULTANT

4.1. The STRICT Overall Architecture

According to the aim of the project, the STRICT design consultant itself has been designed as a Distributed AI

system. In this way, STRICT helps us to understand the potential advantages (and also the shortcomings) of DAI concepts better when applying them to the design of distributed industrial applications. The requirements analysis indicated that the most suitable overall architecture should fulfill the following characteristics: easy to extend, medium selectivity, centralized control, minor agents autonomy, high coherence, centrality of coordination, complex agents. Due to the classification work of Klett we decided to apply a blackboard-based system architecture (Klett, 1989). As we intend to use the implementation of the STRICT system itself as an opportunity to learn about the behavior of DAI systems in general, we started with a rather simple blackboard architecture (see Fig. 2).

The main modules of the STRICT system are the Human Computer Interface, the Blackboard, three currently developed Knowledge Sources (KSs 1-3), the Scheduler, and the Control Knowledge Base. KSAR stands for "Knowledge Source Activation Record." For each of the knowledge sources, the KSARs knowledge base provides detailed information on how a knowledge source is to be activated. In most cases, designing software systems for a particular client requires the client's wishes, personal experiences, etc. be taken into account.


Human Computer Interface

BLACKBOARD

KS 1: PPC Model

KS ~ PPC Case-Base

KS3: DAI Architectures Toolbox

FIGURE 2. The STRICT overall architecture.

This, in turn, may yield additional design requirements that we call the (user-related) context of design problem solving. Each of the KSs maintains those portions of that kind of context knowledge that refers to the contents of its own knowledge base. Thus, to provide the scheduler with context knowledge requires only that the relevant pieces of context knowledge be included in the KSARs. The PPC Model (KS1) provides the common knowledge on PPCs (any other application model may easily be added). The PPC Case-base (KS2) contains sets of skeleton and prototypical PPC cases and takes a case-based style of reasoning to derive solutions. The DAIArchitectures Toolbox (KS3) contains knowledge about the characteristics (e.g., behavior) of DAI architectures. Instead of covering the whole range of centralized and distributed software architectures we currently focus on the development of the DAIAr- chitectures Toolbox. The knowledge sources 4 and 5 are to be included at later stages of the project.

4.2. The PPC Model Knowledge Source

PPC systems in general have the same generic func- fionality (at a sufficient high abstraction level). We concentrate on master production planning, material requirements planning, release of production orders, and detailed scheduling. Accepting this modularization, the problem of finding an overall description is reduced on finding descriptions for each module and a description of how the modules are working together. Follow- ing Friichtenicht (1987), we have to determine components and connections. In other words, we have to assign the substantial aspects of each module and the data flow between the modules. Because the most important aspect of a module is its functionality (embod- ied in the concrete algorithms that are implemented) we can choose the following description of modules: input/output/criteria/method (input-data, output-data, possible algorithms).

Application of this description on the four men- tioned modules yields: • Master production scheduling (MPS)

Input: client orders, demand of past periods, capacity constraints, production coefficients, product prices, production cost, restrictions on the variables

Output: quantifies of products Criteria: profit maximization Methods: forecasting (for example, exponential

smoothing), optimization (for example, linear or integer programming)

• Material requirements planning (MRP) Input: planned quantities of products, stock of

products and materials, bill-of-material information, inventory cost

Output: production orders (lot-sizes) Criteria: minimizing cost per unit Methods: ABC/RSU-analysis, methods to solve

the bill-of-material problem (Gozinto- graph, matrices), lot-sizing (Harris/ Andler-formula, dynamic programming, special heuristics).

• Release of production orders Input: production orders, planned completion

times, costs of delay Output: released jobs, rejected jobs Criteria: optimal partifioning of jobs Methods: capacity-oriented-job-release (BORA),

special heuristics (based on external or internal priorities)

• Detailed scheduling Input: released jobs, job-information (planned

completion times, routing restrictions, operafion-times), capacity restricfions

Output: detailed schedule of operations (Gantt- chart)

Criteria: minimizing makespan or maximizing capacity utilization

STRICT 139

Methods: exact algorithms (Johnson, Akers, Branch-and-Bound), heuristic methods, simulation, rule-based scheduling (used in expert systems like OPIS)

Obviously, incon.qL, a~encies may arise that must be detected and resolved. Thus, any coordination concept requires that knowledge about input/output patterns, task level inference structures (of PPCs), and consis- tency requirements that are imposed on the results be included. Based on a typical example of an industrial production situation, Figure 3 gives an indication of how profiles of conditions can be constructed. The procedure refers to the ranking of DAI concepts (see Fig. 1), and it is to be used when searching for an adequate DAI-based PPC design (see section 4.4.).

4.3. The PPC Case Base Knowledge Source

4.3.1. Overview and architecture. Figure 4 depicts the basics of the PPC case-base problem-solving process. Suppose a set of goals and conditions have been specified by a user. The predictor analyzes them to detect any positive or negative interactions (i.e., goal conflicts

leading to faulty solutions) that are already part of its experience (failure prediction knowledge base). If the list of goals indicates that any failures are to be expected, references to these failures are added, thus completing the problem index. As cases are indexed by the goals they fulfill and by the failures they avoid, the retriever now can search for the very case with the best match. However, there is no guarantee that the case with the best match is the most appropriate one. Therefore, (by interaction with the human expert) the evaluator checks the appropriateness of each case before transferring it to the modifier. The modifier adapts the case to the user-specific requirements.

If all works well, the modification leads to a new (derived) case__modif. The storer then stores that new case in the PPC case base. If the evaluation of a PPC case detects any error, this case is transmitted to the repairer, which, by interaction with the user, tries to repair that failure. Doing this, it may generate a new repair strategy to enhance its future repair capabilities. An even more important function of the repairer is to identify the causes that led to that failure. This explanation, together with a description of the failure, makes the assigner index failures by conflicting combinations

number of products

number of stages

number of machines

number of operations

number of routing restrictions

market dynamics

market irregularity

prod~t specification

product complexity

product diversity

number of optimization criteria

number of methods

quality of methods

variety of algorithm order

minor m low a average higher high

mmm --- m m -mm

m m a mmL ffimmm m mmmm

m mmm m ............... m

minor low average I higher high

FIGURE 3. Example of a typical production situations.


cogoals / nditions )

retrieval case ~ modifier

repairer

P l ~ cases

FIGURE 4. Case-based reasoning process.

storer ]

J

of goals and conditions, thus enabling the predictor to do its work.

4.3.2. Representation of PPC cases. Each PPC is a very complex individual object. For each PPC there are different kinds of descriptions available (software specifications, context descriptions, reports, user guides, images, statistics, etc.). Within STRICT we divide between prototypical cases and skeleton cases. Prototyp- ical eases provide full information of already solved cases that are stored in the case base. Prototypical PPC cases are represented by the following data structure:

PPC_case := (id)(goals)*(avoided_failures)*

(conditions)*(user_context)(success)

(specification)(add__info)

add_info := (user__gnides)(statistics)

(reportsXfree_-info)

Skeleton cases are abstractions of prototypical cases. The use of skeleton cases supports memory organization and case retrieval. Skeleton cases are generated by cluster analysis working on projections of the prototypical cases.

caseskeleton := cluster_analysis

(projection (soalsXavoideaA'ailures)(conditions)[Caseprototypieal])

Each prototypical case provides a huge amount of data and knowledge. So, to assist in evaluating and browsing prototypical cases the user is supported by hypertext- like facilities.

4.3.3. Indexing. Any case-based system must make extensive use of its memory. Rather than developing

for individual design goals and requirements (long in- ferences!) and then synthesizing the subresults, a case- based designer must search in its memory for design specifications that satisfy many of its goals at once. Designing from experiences requires the system to have a clear understanding and method for organizing and storing it. The memory structures and learning mechanisms needed must have the ability to incorporate past failures and successes, thus enhancing the problem-solving capabilities of the system with time. In STRICT, PPC cases are indexed by the goals they help to achieve, and by the failures they are expected to avoid. Goals are formalized in terms of goal definition, types of scaling, and a measure to what degree the case contributes to the achievement of that goal. A similar formalization holds for the representation of failures to be avoided (see section 4.3.1.). The complete index now looks as follows:

index

• = (goal-id, scaling, degree__fulfilled, reLweight)*,

(failure-id, scaling, degree_avoided, reLweight)*

The similarity-relationship may be dependent on the application-specific context. That makes it necessary to model similarity independent of the cases. We approached this by storing the goals and failures in a separate file. Instead of representing them directly in the index, we use pointers to reference them at runtime. This separation introduces the possibility to rearrange the similarity relation at runtime.

From the viewpoint of reasoning, the distinction between skeleton and prototypical cases is an important one. The complete process of case retrieval looks as follows: 1. Using the index of the problem, the retriever first

tries to select an appropriate skeleton case from the

STRICT 141

case base. Subsequently, evaluation (i.e., verification and validation) takes place to guarantee that the selected skeleton ease is really the appropriate one.

2. Now the reference case is selected from the set of prototypical cases that are related to the skeleton case. Again, evaluation procedures have to check whether the selected reference case is really an appropriate one to solve the problem on hand.

4.3.4. Memory organization. This section focuses on the problem of grouping together similar cases and se- leering the most appropriate ones. A well-known method to answer the first question is cluster analysis. Cluster analysis is based upon some measure of the similarity of objects. Any measure that reflects similarity can provide the basis for a clustering program.

Thus a critical point of cluster analysis is to determine the measuring of similarity, that is, to fix the dimensions of objects and to position objects with respect to these dimensions. As we have specified, the relevant attributes of PPC systems and a scaling on each attribute (see section 4.2.), the problem can be expressed as finding an appropriate computation of object distances. Within the STRICT system, distance measures are defined as the Euclidean distance between the weighted differences of all variables. 2 This is expressed by the formula

d~.~ := (wi( Aai)) 2, (l)

where d~e:

ai: overall distance measure number of the ranking of the attributes (minor

--* 1; . . . ; high --* 5) Aaj: distance measure to be applied on attribute i,

and computed by t a i , ~ - a i , ~ [ w~: weight of attribute i n: number of attributes Given a criterion by which clusters should be se-

lected, one of several algorithms can be used. There are two approaches in particular: hierarchical and nonhierarchical. Hierarchical clustering starts with all objects in one cluster and divides them step by step until all objects are in their own single cluster. In contrast to this top-down approach, the bottom-up approach starts with each object in its own cluster and systematically combines objects until all objects are in the same cluster. In both cases the result is a systematic hierarchical arrangement of clusters. Note that two objects that are clustered together remain clustered. Non-

2 Another way of measuring the similarity would be the use of role-based fuzzy mathematics to imitate human evaluations and "cognitive distances." Part of our work is due to the evaluation of that approach.

hierarchical clustering programs differ in that they will permit objects to leave one cluster and join another. Their general method is a hill-climbing algorithm.

The advantage of hierarchical clustering is that the output has a logical structure and that the results are easy to read and to interpret. Its disadvantage is that it is relatively unstable. This disadvantage, however, does not matter because we apply a flexible clustering method (hierarchical clustering, see appendix) that produces user-dependent results. A user who does not have any exact ideas about his own estimations is al- lowed to resort to different default hierarchies.

As a result, the center of each cluster defines the skeleton case of the cluster. Now it must be decided how new objects can be compared with these skeletons and respectively placed into the groups. The user specification is compared against the skeleton cases that represent sets of prototypical cases. If the user agrees with the skeleton case being suggested, STRICT selects that prototypical case which provides the minimum distance to the center of the cluster (skeleton case). If, again, the user agrees with the suggestion (i.e., the prototypical case seems to be similar to the user's problem) the selected case is expected to give clues on how to solve the problem at hand.

The placement of a new case is done by assigning the new case to the group represented by the nearest skeleton case (find the best match) or by constructing a new hierarchy of clusters.

4.4. The DAI Toolbox Knowledge Source

The DAI Toolbox Knowledge Source determines how DAI concepts may contribute to the PPC design. Its problem solving is organized in four interacting layers: (1) GENERIC DAI ARCHITECTURE, (2) TASK LEVEL INFERENCE STRUCTURE (how PPC is to be performed on the application's level), (3) COORDINATION MECHANISM, and (4) AGENT MODEL. Decisions of subsequent layers must be consistent with all previous layers. In case of conflicts, backtracking takes place (see Fig. 5).

The first layer of problem solving (GENERIC DAI ARCHITECTURE) is included to map the application's characteristics onto DAI-related attributes, thus extracting the DAI-profile of the application, and to decide on the most appropriate generic DAI architecture. Figure 6 depicts the inference structure of layer 1. In a first step, the application's characteristics are aggregated. Since the aggregates are to be mapped onto DAI-architecture characteristics their possible values are identical with those used to describe DAI systems (i.e., small, moderate, medium, large, immense). Sec- ond, the aggregates are mapped onto five DAI-related attributes that define the applications DAI profile: system model, flexibility (overall system), degree of coupling, decentralization of control, and selectivity.


application._~ generic DAI- I ~.~

r quest --I l-"

h.~[task level infe- ~'-[ rence sWacture [ "~ [

w I mechanism

a • J agent model v I

FIGURE 5. The four-layer model of the DAI toolbox problem solving algorithm.

~ dcsign advice

Third, the application's DAI profile is compared against the profiles of the four generic DAI architectures (see section 3.5). A cluster analysis is used to decide which one of the generic DAI architectures is expected

to be the most appropriate one for the application at hand. Its input are the DAI profile of the application and the DAI-architectures (SVS, BBS, CN, NECS). Its output is given by a value (distance measure) for each

REQUIREMENTS A T r R I B U T E DAI-RELATED SPECIFICATION AGGREGATES ATTRIBUTES

number of products / production groups

complexity of

GENERIC DAI- ARCHITECTURE

variety of order in which algorithms are called

methodological flexibility ~ sd~tivity

FIGURE 6. How to determine the "appropriate" overall DAI architecture (layer 1).

~ver~.ty of l \ \

number of production ~ stages needed for completion production system model

restrictions ~ n u m b e r of machines

per stage

number of different

I I ~ ~ ~ l l ~ ~ operations specification per machine ~ [[ of products Supervisor

S y s t e m

market dynamics ,, production flexibility -- [ Blackboaxd flexibility •

market irregularity ~ System

methodological degree of [ Centrist i

quality estimation of each ~ ~ I[ Net algorithm " quality coupling /

number of planning methods ~ ~ ~ Not Explicitly to solve a planning task methodological decentralization Cooni. Sygt~ng

complexity number of criteria to be F ~

optimizezl ~,. . / ~ . ,~ .

STRICT 143

DAI-architecture that indicates its suitability for the application under consideration.

Layer 2 of the DAI toolbox problem solving starts with an explanation of how the particular type of DAI architecture (say, a contract net) performs problem solving (e.g., task decomposition, task allocation, synthesis of subresults). It is now up to the user to evaluate whether the task level inference structure of the application at hand can be transformed into the problem- solving concept of the system type that has been suggested. Up to now, there is no system support available for this task. Instead, it is completely up to the user to validate the result of layer 1. The result of its evaluation is either accept_suggestion or reject_suggestion (which restarts the process of problem solving at layer 1).

Layer 3 decides on the design of the coordination mechanism that shall be implemented. Currently, the following features are under consideration: 1. coordination concept: planning or negotiation (to-

gether with the different derivatives according to the current state of the art)

2. data models for tasks, task descriptors, and capa- bility descriptors

3. scope of global knowledge that is required to support the coordination mechanism

4. algorithms to deal with nonmonotonic knowledge and vagueness

5. criteria to be used in resolving conflicts (e.g., to decide among several competent bidders) Finally, layer 4 suggests the design of the agent

model (e.g., knowledge source of a blackboard system, or cooperative agent in contract nets, etc.). This part of problem solving supposes that the agent model de- pends mainly upon the DAI architecture to be used (layer 1), and the coordination mechanism to be applied (layer 3). The latter provides for most of the in- terfaces within a single agent and between the agent and its outer world, too. As an example, Fig. 7 depicts an agent model that can be used within contract nets.

At the end the main result that is provided by the

DAI toolbox KS consists of a design suggestion together with a kernel system for a DAI-based distributed PPC. This PPC kernel consists of the basic software components (together with the data structures and inter- faces) of the overall DAI architecture that has been suggested. It also includes the coordination mechanism and the agent model that have been suggested during the session. These components need to be completed (e.g., by exchanging dummy procedures with PPC modules) and adapted to the user's particular software and hardware environment.

4.5. Integrating a Case-Based Reasoning System into a Blackbom~-Based Architecture

In standard blackboard systems, the knowledge sources axe more or less dependent on the overall system. They bid for a task currently noted on the blackboard, but it is the scheduler who decides to which of the bidders the task shall be assigned. The contents of the knowledge sources and their problem-solving capabilities are used by the blackboard system only. In general, the knowledge sources do not interact with the (blackboard) external world. Also, they do not change their behavior (functionality, semantics) permanently with time. However, when integrating a ease-based knowledge source into a blackboard-based problem solver, we rapidly learned that all these assumptions do not hold any longer.

Instead, a case-based reasoner needs a huge amount of interactions with the user. These interactions cannot be controlled by the scheduler of the blackboard at all. Learning facilities may trigger problem-solving processes that are completely independent from any control by the blackboard-system, too. Similar observations hold when we consider the issue of system maintenance of a PPC case base. Further, the PPC ease base has been implemented on the basis of a conventional re- lational data base system (ORACLE on SUN worksta- tions). This provides for developing tools for an efficient

Competence Knowledge Subsystem

End-User

I Dialogue Management Subsystem

~ User Interface

Domain Knowledge Subsystem

(local)

I I I Coordination M an a~.em~en.!...Sub sic s t e m I~

/ ................. ISO / OSI Application Layer ........................................

FIGURE 7. An agent mockd that can be usecl in contract nets.


system maintenance, but it also offers case access (READ/WRITE) to non-STRICT users. As a consequence, a case-based knowledge source requires much more au tonomy than conventional blackboard knowledge sources are provided with. A second important issue is on the dynamics of case-based systems. As the PPC case base knowledge source itself is a distributed, not fully synchronized, system (see Fig. 4), there is no means to control that the case base suspends reasoning when having returned the answer to the blackboard. In other words, after having generated the requested answer, the knowledge source may repair the underlying case (thus updating its own knowledge base) or it may provide ease access to other users as well. Such activities occur completely independent of the ongoing STRICT internal problem solving. There is no control yet o f the interactions that may arise between STRICT internal and STRICT external processes.

This makes it extremely difficult to analyze the interactions among the underlying coordination strategies (case access control by the ORACLE DBMS and long- duration reasoning of the STRICT system) when letting two different knowledge sources cooperate on a similar (and even identical) case. Up to now, these dynamics are not yet fully understood.

5. SUMMARY

In this paper we introduce the experimental design advisory system STRICT. The long-term aim of the STRICT activities is to capture the basic principles that stand behind the development of a software-based design consultant. In general, design tasks work on very complex objects, thus providing severe problems in knowledge representation and reasoning. Instead of using a conventional knowledge representation for- malism we expect that the case-based paradigm is much more appropriate to deal with these issues. Focusing on the development of a case-based PPC knowledge source, the discussion indicates that this would be quite true. However, case-based reasoning is a very young field of research. So there still remain important methodological and technical questions open (e.g., similarity-based matching, concurrent user access to the case base, and efficient data base support, to mention just a few). Further, and more related to STRICT, the integration of case-based systems in distributed environ- ments provides additional problems. Section 4.5 gave a first impression on that subject but did not provide a complete picture already. Also, we feel a need to augment the case-based system by rules and object-oriented features. Here also, a lot of questions are still open. According to the basic motivation of the project we use STRICT to deepen our insights in these con- cerns, tOO.

On the other hand, we strongly believe DAI concepts have the power to contribute much to the development of intelligently distributed (and cooperative) applica-

tions. However, as our current DAI knowledge is not yet detailed enough to provide for an engineering style of software design, we had to start further research ef- forts already.

To conclude, the STRICT activities have been planned for the development of an experimental design advisory system, and, at this stage, we recognize that they have motivated (and enforced) our experimenting in the very stimulating field of cooperative hybrid knowledge-based systems that is integrated in advanced (and distributed) software architectures!

Aclmowledgements--The authors gratefully acknowledge the re- viewers' comments on an earlier version of the paper. Their susges- tions helped a lot to improve the presentation of the paper further.

REFERENCES

Ashley, K.D. (1987). Modeling legal argument: Reasoning with cases and hypotheticals. Unpublished Ph.D. thesis. University of Mas- sachusetts, Amherst.

Bond, A., & Gasser, L. (Eds.). (1988). Readings in distributed artificial intelligence. San Mateo, CA: Morgan Kaufmann.

Clearwater, S.H., Huberman, B.A., & Hogg, T. (1991). Problem solving by committee. Tech. Rep. Dynamics of Computation Group, Xerox Palo Alto Research Center.

Cohen, P., & Levesque, H.J. (1991). Teamwork. (Technote 504). SRI International. Stanford, CA: Stanfordn Research Institute.

Conry, S.E., Meyer, R.A., & Lesser, V.R. (1986). Multistage negotiation in distributed planning. COINTS Teeh. Rep. No. 86-67, Amherst, MA. (Also in Bond & Gasser, 1988, pp. 367.)

Davis, R., & Smith, R.G. (1983). Negotiation as a metaphor for dis- tributcd problem solving. AL 20, 63.

Durfee, E.H., & Lesser, V.R. (1987). Using partial global plans to coordinate distributed problem solvers. Proceedings of the Joint International Conference on AI (p. 875).

Fandel, G., Dyckhoff, H., & Reese, J. (eds.). (1988). Essays on production theory and planning. Berlin: Springer.

Ferber, J. (1989). Eco problem solving: How to solve a problem by interactions. Proceedings of the 9th Distributed AI- Workshop (p. 113). Rosario, TX.

Fox, M.S., & Smith, S.F. (1984). ISIS--A knowledge-based system for factory scheduling. Expert Systems, 1, 25.

Fox, M.S. (1986). The implementation of opportunistic scheduling. In L.O. Hertzberger, & F.C.A. Groen (Eds.), Intelligent autonomous systems--An international conference (p. 231). Amsterdam: North Holland.

Frtichtenicht, H.W. (1987). Tiefe modelle als basis technischer ex- pertensysteme--Deep modelling as a basis of technical expert systems. In W. Brauer, & W.M. Wahlster (Eds.), Wissensbasierte Systeme, 2 (p. 335). Miinchen: International GI-Kongrel3.

Griinwald, H., Striekwold, P.E.T., & Weeda, P.J. (1989). A framework of quantitative comparison of production control concepts. In- ternational Journal of Production Research, 27, 281.

Hahn, D., & Lal3mann, G. (1989). Produktionswirtschaft--Control- ling industrieller produktion. Band. 2. Heidelberg: Physica.

Hammond, K.J. ( ! 989). Case-based planning--Viewing planning as a memory task. Perspectives in AI, Vol. 1. Boston: Academic Press.

Hewitt, C.E. (1985). The challenge of open systems. BYTE, 10, 223. Hewitt, C.E. (1986). Offices are open systems. ACM Transactions on

Office Information Systems, 4, 271. Kirn, St. ( 1991 ). Cooperative ability of intelligent agents in federative

knowledge based systems. Ph.D. thesis, FernUniversita't Hagen. Hagen. (In German).

Klett, G. (1989). Cooperating expert systems with contract net-ar-

STRICT 145

chitecture and their use in chemical applications. Ph.D. thesis. FernUniversitlit Hagen (in German).

Kolodner, J.L. (1983a). Maintaining organization in a dynamic longterm memory. Cognitive Science, 7, 243.

Kolodner, J.L. (1983b). Reconstructive memory: A computer model. Cognitive Science, 7, 281.

Kurbel, K., Mertens, P., Scheer, A.-W. (Eds.). (1989). Interaktive betriebswirtschaflliche informafions und steuerungssysteme. New York: Walter de Gruyter. (In German).

Kuwabara, K., & Lesser, V.R. (1990). Extended protocol for multistage negotiation. Proceedings of the 9th International Workshop on Distributed AI. Bandera, TX.

IAasri, B., IAasri, H., & Lesser, V.R. (1991). An analysis of negotiations and its role for coordinating cooperative distributed problem solvers. Proceedings of the 11th Conf. on 2nd Generation Expert Systems (pp. 81-94). Avignon, France.

Rosenschein, J.S., & Genesereth, M.R. (1985). Deals among rational agents. Proceedings of the Joint International Conference on AI (p. 91).

Rosenschein, J.S., & Kraus, S. (1991). The role of representation in interaction: Discovering focal points among alternative solutiong Pre-Proceedings of the 3rd European Workshop on Modeling Au- tonomous Agents and Multi-Agent Worlds (MAAMAW-91). Kaiserslautern, Germany.

Schmitt, T.G., Klastorin, T., & Shrub, A. (1985). Production classification system: Concepts, models, strategies. International Journal of Production Research, 23, 563.

Schupeta, A. (1992). Main topics of DAI: A review (Research Rep. No. RR-92-06). Kaiserslautern/Saarbrticken, Germany: German Center of AI (DFKI).

Sheth, A.P., & I.arson, J.A. (1990).'Federated database systems for managing distributed, heterogeneous and autonomous database~ Bellcore, Tech. Rep. No. TM-STS-016302. Piscataway NJ. Also published in A CM Computing Surveys, (1990) 9.

Simpson, R.L. (1985). A computer-based model of case-based reasoning in problem solving: An investigation in the domain of dispute mediation. Ph.D. thesis. School of Information and Computer Science, Georgia Institute of Technology.

Smith, R.G. (1979). A framework for distributed problem solving: Proceedings of the Joint International Conference on AI (p. 836).

Smith, R., & Davis, R. (1981). Frameworks for cooperation in distributed problem solving. IEEE Transactions on Systems, Man and Cybernetics, SMC-I 1]1, 61.

Sridharan, N.S. (1987). 1986 workshop on distributed AI. AI Mag- azine, Fall, 75.

Van der Linden, P.M.J., & Griinwald, H. (1980). On the choice of a production and control system. International Journal of Pro- duction Research, 18, 273.

Werkman, K. (1991). Using negotiation and coordination in multiple agent systems. Proceedings of the 1st International Workshop on Intelligent & Cooperative Information Systems, (pp. 219-238). Sydney, Australia: Australian National University Press.

A P P E N D I X :

vat i, j,/c. integer;

BEGIN

n := number_of_PPCcases; k: = n; i : = 1;

built_.startpartition(set_o f__cases);

END;

REPEAT k := k-1; i: = i + 1; build_partition(set._of__clustcrs); FOR j : = 1 t o k d o

BEGIN map set(j) --~ cluster(i,j); compute.._center(cluster(i,k))

END; UNTIL i = n

H I E R A R C H I C A L C L U S T E R A N A L Y S I S

{i: counts the hierarchical level of clusters i = 1 } {defines the leave node level of the cluster hierarchy} {makes each case its own cluster and its own center} {resulting in a set ofelements:cluster(l , j) ; 1 < j < n}

{/c. counts the number of new clusters to be built}

{groups clusters into k sets}

Documents

STRICT: A blackboard-based tool supporting the design of distributed PPC applications