creation of an intelligent process planning system within the relational dbms software environment

215

Applications

Creation of an Intelligent Process Planning System within the Relational DBMS Software Environment

Ming Wang Department of Economics and Management Science, University of Keele, Keele, Staffordshire ST5 5BG, United Kingdom

H. Walker Department of Manufacturing and Engineering Systems, Brunel University, Uxbridge, Middlesex, United Kingdom

The relational Data Base Management System (DBMS) software constitutes the foundation of a Computer Integrated Manufacturing (CIM) information system, because of its flexibility and the ease with which data can be manipulated. In this paper process planning knowledge is formalized using the relational approach, and the features of the process planning rules are identified. A framework for the creation of an intelligent process planning system within the relational data base management system software environment, together with a case study, is presented.

Keywords: Data Base Management System (DBMS), Process planning knowledge, Relational representation, Data structure, Generic data model, Conceptual model, Physical model, Process planning rules, Match, Optimization.

Ming Wang is a Lecturer at the Uni- versity of Keele, UK. His principal interest is in the applications of information technology in manufacturing industry and business environment. Sponsored by Dowty Group, Dr. Wang studied at Brunel Univer- sity UK, and graduated with first class honours degree in Production Tech-

in 1984. Then he went to work for Dowty Mining Equipment Ltd, firstly as an engineering assistant in the de-

sign office and then as a manufacturing analyst in the production department, while he did his PhD research in the area of CIM information systems. He completed his PhD study in 1988. Dr. Wang is a member of the Institution of Production Engineers (MIProd) and a Charactered Engineer (CEng).

Elsevier Computers in Industry 13 (1989) 215-228

0166-3615/89/$3.50 © 1989 Elsevier Science Publishers B.V.

1. I n t r o d u c t i o n

A process plan represents an association between a part and a set of manufacturing resources. The creation of process plans is a central feature of a manufacturing system, and therefore the effective computerisation of process planning is a critical part of creating a CIM system. CIM aims to bring together the varied processes within manufacturing which are at present operating in isolation. In order to support such integration, an effective and efficient means of data storage and manipulation must be provided. Process planning, and the integration of process planning with design and other related functions, represent essential components within CIM, and demonstrate the importance to the system of valid, reliable data. Thus the manufacturing information system is a central and vital part of a CIM system. If one considers process planning in depth, it can be seen that the process of generating a process plan involves transforming the design data, which is in the form of symbolics, geometry and numerics, into a sequence of operations which use some combination of the available manufacturing re-

Helen Walker is at present undertak- ing research towards a PhD at Brunel University. Her current research focuses on the use of relational techniques in the design and development of a Manufacturing Database, and the

" provision of decision support software for Computer Aided Process Planning and Design for Manufacture. She obtained a BEng degree in Engineering Production from the University of Wales Institute of Science and Tech- nology in 1985, and subsequently

worked in the aerospace industry as an industrial engineer. She is a graduate member of the IProdE, and an Associate member of the Women's Engineering Society.

216 Applications Computers' m lndu~lry

The Part definition

Identify shape primitives

+ >I For each shape primitive:

I

J Select process primitive

I Select machines required

+ I Optimize potential process

I Select tools for chosen process

i Select tooling for chosen process

I Next shape primitive

J Sequence operations according to technological and other constraints

I Output process plan

J The information for process planning:

I <------~ Component I

j <-----~ Machine ]

I

1<-~ Tooling '[

J

The process plan

Fig. 1. The decisions involved in process planning.

sources. Figure 1 gives an outline of the flow of information and the decisions involved in process planning. In the past, many attempts have been made to create computer aided process planning (CAPP) systems [4,16,21,25]. More recently, ef- forts have been made to apply artificial intelligence techniques to the task of process planning, and several process planning expert systems have been developed [2,20,26].

In order to support the task of process planning, two major types of CAPP system have emerged. Variant systems produce a process plan by referring to previous plans for similar parts, whilst generative systems consider the individual characteristics of the part, and build up a plan from first principles. It can be argued that the variant methodology is much closer to the manual process, as process planners often draw on past experience with similar components to provide the basis for a new process plan. Variant systems also

allow a higher degree of human interaction than generative systems, which by some definitions [12] imply total automation of the planning process. Thus it would seem that the variant approach fits better into a system involving both humans and computers. However, variant systems are difficult to create where there is a diverse range of prod- ucts, and thus it would seem sensible to attempI to integrate the two approaches according: to the requirements of the individual environment. For example, if a company manufactures a variety of components, all of which require heat treatment and plating, then a basic outline plan could be produced by variant means, and then a detailed examination of component characteristics made to detail the individual operations, using generative techniques. Thus a hybrid variant/generative approach may be necessary in a large number of cases, to suit the individual manufacturing environment.

Computers in Industry M. Wang, H. Walker / Intelligent Process Planning System 217

Once the planning methodology has been de- cided upon, then the method of storing and manipulating the CAPP data has to be selected. As already mentioned, much interest has recently been shown in Expert Systems and Artificial Intel- ligence (AI) type knowledge representation. How- ever, in a real-time system, this may have certain drawbacks. A Prolog database, although concep- tually simple, can take up to 7 hours to solve a relatively simple process planning problem [14], due to inefficiencies in data retrieval and manipulation. Thus it seems prudent to use relational database technology for system implementation, as this provides efficiency and flexibility in information processing.

Problems with inefficient data storage have lead to CAPP systems being described as "until recently.., crude and/or inflexible" [15]. This is because, to be of real use, a CAPP system must be able to support complex and sophisticated management and production techniques, and yet not demand great computer systems knowledge on the part of the engineers involved. The combination of apparent simplicity from the planning viewpoint with the ability to support process planning com- plexity can be best achieved by providing a system where all configuration factors and all production data are stored in a database, separated from programmes for supporting process planning logic. Therefore a process plan "should be built up as collections of references to elements in a centrally accessed standard data area" [15]. At the same time, the system would provide ways for the company to modify the database with respect to any change in the manufacturing infrastructure without involving great computer systems knowledge.

One possible solution to this problem is to develop a CAPP system within a relational data base management system (DBMS) software environment. The latest relational DBMS's are flexible and easy to use. They enable one to develop a well-defined, distributed or centralized database which contains all the information on the essential aspects of a company's manufacturing activities, both at initial installation and at any time there- after. A relational DBMS also enables one to modify the database relatively easy by using pseudo-Engiish commands (such as the Structured Query Language) [6,19]. However despite its high efficiency in data manipulation and retrieval, much

needs to be done in order to tailor a relational DBMS to process planning requirements. This paper is concerned with the creation of a process planning system within the relational DBMS environment. It formalizes the process planning knowledge in terms of the relational data model and identifies features of certain data manipulation operations which are necessary to support the process planning activity, but not supported by a relational language. Then a framework for developing an intelligent process planning system within the relational DBMS environment is proposed. The final section of the paper describes a case study showing the practical application of relational database technology in process planning, based on the PICK operating system.

2. The Process Planning Knowledge

It is widely acknowledged [2,20,23,26] that manufacturing information can be split into two broad areas: the manufacturing knowledge (de- clarative knowledge) and manufacturing rules (procedural knowledge). The process planning knowledge can be broadly classified as: • Component knowledge; • Machine knowledge; • Tool knowledge; • Tooling knowledge; • Material knowledge. This knowledge can then be stored in a database and retrieved for various manufacturing activities including process planning.

This section examines how the knowledge can be stored in a relational database by formalizing the general data structure of the information and identifying major factors which influence the design and implementation of the relational database.

2.1. The Relational Model of Process Planning Knowledge

Firstly there is a need for a relational treatment of the knowledge identified above 1. In this study, the Entity-Relationship based modelling tech-

i Although these divisions of the process planning knowledge apply to all manufacturing knowledge, the discussion is limited to the specific domain of metal cutting.

218 Applications Computers in lndustt3

nique has ben adopted to formalize the data structure of process planning knowledge in terms of entity or relationship relations with certain recognized properties. The techniques has been described in many texts, and the interested reader is referred to P.P. Chen, Entity-Relationship Ap- proach to System Analysis and Design, North-Hol- land, 1980.

The data structure of the process planning knowledge can be represented as in Table 1 [24].

Table 1 The data structure of the process planning knowledge

Knowledge Relation category

category Entity Relationship

Component Shape.Primitive Shape.Prim : Processing. Prim Processing. Precedence.

Primitive Relationship

Machine Machine Machine : Process Process

Tool Tool Shape.Primitive : Tool

Tooling Tooling Tooling : Part : Machine

Material Material Tool : Machine : Material

Notes (1) Shape Primitives: Any component is a com-

bination of one or more shape primitives, each of which can be considered as an independent entity, possessing the attributes of overall shape, length, diameter, surface finish, tolerances etc. Thus a process plan is developed by recognizing the specific attributes--namely shape primitives--of the part in question, and then relating these attributes to the most appropriate manufacturing operations and resources. Similar approaches have been used elsewhere, particularly the idea of feature- based process planning, where the system recog- nizes the features which constitute the part, and links these features to the processing capabilities [1,22].

(2) Processing Primitives: The shape primitives are created by manufacturing processes, and the manufacturing process entities, or processing primitive entities, are therefore closely associated with the shape primitives. This implies the ex- istence of relationships between the Shape-Primi- tive and Processing-Primitive entity relations.

(3) The recursive relationships among the Processing-Primitive entity relations are used to

described precedence relationships, or processing sequences, among the processing primitives, which may be represented in the terms of the precedence graph as originally suggested by Wysk [26].

(4) The relationships between the process entities and the machine entities represent the machine processing capability.

(5) The relationships between the shape primitives and the tools provide the tool applicability knowledge, or the tool constraints.

(6) The three-way relationship among the Tool- ing, the Machine and the Part entity relations contain the tooling applicability knowledge.

(7) The tool cutting parameters, such as feed rates, cutting-speeds, tool life etc, are the properties of the three-way relationship between the the Tool, the Machine, and the Material entity relations.

(8) Each relationship has two important properties: cardinality and dependency [27]. In this study all the relationships defined above are assumed of cardinality Many-to-Many with No De- pendency for the general case.

Thus the structure and constraints of the process planning knowledge has been derived. Such structures and constraints are intrinsic to a manufacturing process, and will stay the same regard- less of developments in computer technology. What will change are the atrribute values for each of the entity or relationship sets. In principle, the data model would provide an overall framework for developing a database system. However the model derived only represents a general view of the information properties identifiable within the metal cutting application domain. The general model needs to be "tailored" to company requirements. In other words it has to be refined by taking account of the more specialized concepts and practices adopted in an individual company in order to produce a realistic model which is specific for that company. In that sense the general model provides a starting point for an individual company to develop its own model, as discussed below.

2.2. From the General Model to a Specific Model

It has been recognized that converting the general model to a specific model includes the following considerations [27]:

Computers i. Industry M. Wang, H. Walker / Intelligent Process Planning System 219

Generic Model

Enterprise rules: { Attribute assignment } Relationship property

determination } { Subentity determination }.

] - - > Conversion - - > 1 Specific ModelJ

Fig. 2. From the generic model to a specific model.

(1) Attribute assignment: In the general model, the identifier of each relation is based on the name of that relation. For instance, the identifier of the Machine entity relation is machine-number. It is the identifier that constitutes the starting point for aggregating non-identifying attributes. However the choice of the non-identifying attributes is dependent upon the practice adopted in an individual enterprise. For instance, the attributes of in- ner-diameter, outer-diameter etc are used for a rotational part but height, width etc are used for a prismatic part.

(2) Relationship property determination: The relationship properties--cardinali ty and dependency- -vary within a defined range. Within the general model, the general properties of Many-to- Many cardinality and No Dependency have been assumed. When it comes to designing a database system for an individual company, the true relationship properties must be determined. For example, in a flow-line production system, in relationships between the Tooling, the Part and the Machine will reduce to One-to-One-to-One and Total Dependency. Such constrained manufacturing environments, characterized by limited manufacturing resources and a limited product varia- tion, would set boundaries for each of the entity relations and lead to more strict cardinality and dependency properties for some relationship relations. The more strict relationship properties would eliminate the need for a separate relationship relation in the database [27].

(3) The subentity determination: All the entity relations appearing in the model are generic, as they are produced by extracting common properties of one or more entity relations while suppress- ing the differences among them. However, such relations may need to be partitioned into several subentity relations in order to accommodate various special properties of an individual company.

For instance, an individual company may have various types of machine tools and capital equipment, such as production type machine tools, special purpose machine tools, etc., and may wish to provide some kind of logical grouping of machines within the machine entity relation. In a similar way the concept of subentity sets can be applied to the Part, the Tool, and the Tooling entity relations in order to accommodate various properties within each of the generic entity relations.

Thus the refinement of the general model into a specific model for an individual company can be summarized as in Fig. 2.

The data model derived provides an overall framework for developing a relational database to contain the process planning knowledge for a particular company. In other words the model will be used as the "s tandard blueprint" for constructing the database. The structure of the database system must be based on the data model and any change made to the structure of the database must be initiated by a change in the model associated with any change in the manufacturing infrastructure.

2.3. Towards Physical Data Models

In principle the conversion from the conceptual model to a physical data model is straightforward. This is because the relational database is a collection of relations, each of which can be viewed as

Entity Relationship

j

Relation File

Tuple <--> Record Attribute <~> Field name Domain <--> Field type

Fig. 3. From the relation to the file.

220 Applications Computers in lndust O"

an abstraction of a certain restricted type of file, as illustrated in Fig. 3.

Thus each of the entity or relationship relations in the model is equivalent to a file and the trans- formation from the conceptual model to the physical model would seem to be a one-to-one conversion. However, the actual process is much more complicated than this, because certain database design rules must be followed in order to ensure database integrity. The rules include:

(1) Normalization: Normalization is a process of nonloss decomposition in which a given relation can be decomposed into its elementary form and the join operation can then be applied over the elements to produce the original relation without losing information. The objective is to ensure that the relations must not lead to redundant data and cause storage or operational anomalies. Further- more the attributes must be selected in each relation in such a way that the relation will be stable as the database grows, changes, and is used for new applications. The process is often described in terms of stages known as first, second, third, fourth and fifth normal forms. At each successive stage of normalization certain undesirable features are eliminated from the initial unnormalised relation, depending on the attribute dependency [6].

(2) Action specification: This aims to ensure that the processes of insertion or deletion will not lead the database into an inconsistent state. It specifies which operations should be rejected or accepted and, for those to be accepted, what com- pensating operations (if any) should be performed. The (primitive) operations applied to a relation include Insertion, Deletion and Update. The specification is based on a set of integrity constraint rules associated with the entity and relationship relations, which are [6]: • the Entity Integrity Constraints;

• the Relationship Integrity Constraints; • the Subentity Integrity Constraints. Each of the integrity constraint rules has associated with it a set of action specifications. The specifications can be implemented in terms of programme procedures so that each time an operation is to be carried out, it must use one of the specific procedures defined for that relation [27].

Thus the conversion of a conceptual model into a physical model can be summarized as shown in Fig. 4.

To sum up, the above discussion has shown how a relational database can be developed to contain the process planning knowledge. The knowledge is stored in the forms of: - the data structure in terms of entity and rela-

tionship relations; - the attribute values associated with each of

relations. A major advantage of a relational database system is that it provides ways for a user company to modify the database without demanding great computer system knowledge on the part of the engineers involved. These ways include pseudo- English commands, selection from menus etc. The kinds of modifications possible include: (i) additions, modifications or removals of mac-

hines, tools tooling etc, i.e. changes in the manufacturing infrastructure.

(ii) modifications of calculations of material usages, times, costs etc, i.e. changes in the attribute values.

Thus a user company is able to ensure that, when changes occur to the manufacturing infrastructure a n d / o r production methods, the process planners are able to modify the database without requiring special computing skills or external assistance, and, generate process plans which reflects such changes.

a specific, conceptual model ...........................

The Database Design Rules: : ................ : : ......................

', Normalization ',-->I Action specification

V the physical model consisting of the normalized relations with integrity constraints

Fig. 4. From a conceptual model to a physical model.


3. The Features of the Process Planning Rules

It has been shown that a relational database is able to store the process planning knowledge and also allows an efficient manipulation and retrieval of data through the structured query language. Although the SQL "can retrieve any value or any set of values that can be defined by the first order predicate calculus" [9], it is not powerful enough to support various rules required for the process planning activity, i.e. the procedural knowledge. This section identifies the features of the process planning rules, which will lead to provision of the data manipulation operations necessary for imple- menting these rules.

Two types of operations have been recognized as essential for process planning [23], and these are selection and sequencing:

(1) Selection, which selects the most appropriate machines, tools and tooling items for a particular part using the process planning knowledge. For instance, • Selection of processing primitives: A part can

be broken down into a set of shape primitives. The processing primitives are identified through the relationships between the shape primitives and the processing primitives.

• Machine selection: The processing primitives are then grouped into a sequence of operations which are used to select the machines through

the relationships between the machines and the processes.

• Tool selection: The appropriate tool is selected through the relationships between the tools and the shape primitives. A further consideration is to define the tool cutting parameters through the relationships between the tool, the machine, and the material to be cut.

• Tooling selection: A tooling item is selected through the relationships between the tooling, the machine and the part. It must be emphasized that the selection pro-

cess is not simply seeking a possible .match, but the most suitable match, where the criteria for the most suitable match are externally determined, such as least cost, maximum machine utilization, etc. In abstract terms it can be described as fol- lows (see Fig. 5): (i) There exist two entity sets, say A and B, as

well as their relationship set A : B in the database;

(ii) Given an entity or entity set E, where set E is a subentity set of the entity set B;

It is required to find an instance from the set A, which is the best match for the instance from set E, through the relationship set A : B . The operation is to generate a set of conditional relationships between the entity set E and a subset of the entity set A, say F.

(2) Sequencing, which sequences the operations

Given facts :

~ ; >/Optimized~<-- I \ selection/

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . : \ I

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The new facts:

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The external condition

Fig. 5. The Optimized Selection : generating new relationships from the existing entity and relationship relations, subject to a certain external criterion.

222 Applications Computers in Industry

n operations

Initial processing order ( Op A, Op B, ..., Op A,~.. )

The external criterion <sequence~<~

The constraint: [ Part geometry, Tool, Precedence }

Re-arranged processing order ( Op A, Op A, Op B, . ..... ) % . J

n operations

Fig. 6. Sequencing a set of machining processes.

selected in order to determine an opt imum route, taking account of the existing constraints, such as the component geometrical constraints, the tool constraints and the processing precedence constraints, etc. (see Fig. 6).

These two types of operation are supported by two separate data manipulation processes, namely the match process, which uses descriptive criteria to select possible solutions, and the optimization process, which uses numerical criteria to assess the suitability of the options produced by the match process. Selection uses the match process, and sequencing uses both the match and optimisation processes, which are discussed below.

3.1. The Match Process

Given an entity, the match process locates associated entities using the existing facts. An example would be to locate all the machines which are capable of performing a particular process using the relationship between the Machine and the Process entity relations. The match process is a typical example of first order predicate calculus, in which a global object, say an entity E, is matched against a fact object from, say, the entity relation B. The match is successful if and only if the formula involving the goal object unifies with some sub-conjunction of the formula of the fact object. Thus the match operation may be represented as

For e i , e ~ E,

(3bi )( b ~ B) A Pred.

(For e, where e is a member of E, there exists a

b, where b is a member of B, and the predicate is satisfied.)

Essentially the process peforms an exhaustive search throughout the database, and leads to three possible outcomes: • i = 0: there is no fact object available; • i = 1: a single fact object has been located; • i > 1: several fact objects have been located. In

this case optimization is necessary. Note that the fact objects themselves are stored

in the database as a result of an knowledge acquisition process which as far as possible opti- raises these facts, and as such they represent truths about the environment.

3.2. The Optimisation Process

In the case where a set of possible candidates exists (i > 1), the optimization process evaluates these candidates against the pre-determined tech- nical a n d / o r economic criteria and then selects the most appropriate solution. Optimization has been recognized as a necessary function for process planning and there are many proposed approaches to this problem [8,11,13,14].

However a general solution has yet to be found [5,18]. As an at tempt to formalize the problem, the optimization process may be divided into four basic types, each of which requires different problem-solving methods.

(1) One variable, one goal entity: For a set of candidate entities, say e,, where i = 1 . . . . . n and e ~ E ( A 1 . . . . . A,,), the problem is to find one entity which possesses the maximum or minimum value of a particular attribute, say A j, where Aj (A 1 . . . . . A,,). One example is to select the mac-


hine with minimum hourly rate. This problem can be solved by using a simple comparison technique.

(2) Multiple variables, one goal entity: In this case the previous problem is extended to maxi- mize or minimize some function of a set of attribute values in order to select one entity from the given candidates, that is, max/min f ( e i ( A p . . . . . Aq)), where Ap . . . . . Aq ~ ( A 1 . . . . . Am). This problem can be solved using linear programming techniques.

(3) One variable, multiple goal entities: This problem is different from the previous two in that it is no longer required to select the most appropriate entity from a set of candidates, but to determine the most appropriate grouping sequence within a set of candidates. A typical example is to re-arrange the operation sequence in order to satisfy some pre-determined criteria, as illustrated in Fig. 6, where minimization of tool changing is given as one example of some possible criteria. The problem is to identify the best sequence group from all the possible groups of candidates by considering the value of a particular attribute. That is, max/rain Gk((ei, A j)), where G i ~ G k is the set of all possible groups, and Aj is determined externally. This type of problem can be solved by using a comparison technique. How- ever the technique may be limited because of the "combinatorial explosion" phenomenon. For instance, with only ten components, the number of possible sequences to be evaluated is 10! = 3,628,800.

(4) Multiple variables, multiple goal entities: The previously discussed grouping type of problem is now extended to include more than one attribute, that is, max/rain Gk( f (e i (Ap . . . . . Aq))), where Ap . . . . . Aq ~ ( A 1 . . . . . Am) and k is the number of groups. This problem may be solved by an exhaustive generate and test procedure, although this will lead to a combinatorial explosion where the number of candidates within the group exceeds a threshold value, beyond which point computation of the possible combinations is uneconomic and impractical. Practically, this kind of problem can be more efficiently solved through various heuris- tics and local algorithmic methods, or by simula- tion techniques.

Despite the problems that multiple evaluation criteria bring within the optimization process, it is believed that solutions close to optimum can be achieved. Some progress has been made in this

area [14,18], and in related fields such as scheduling [10]. Further work is being undertaken at Brunel University to investigate and evaluate suitable general solutions for the defined classes of problems which remain insoluble. This will be covered by a future paper.

To sum up, it has been shown that the process planning rules are characterized by two separate data manipulation operations: match and optimization. Thus provision must be made to support these operations at the system level for purpose of creating an intelligent process planning system. While the match operation can be easily implemented by using SQL, optimisation requires unique algorithms which have to be implemented through a supporting programming library created within the relational DBMS environment.

4. The Intelligent Process Planning System in the Relational DBMS Environment

4.1. The Overall Framework

On the basis of the previous discussion, the architecture of an intelligent process planning system can be outlined as shown in Fig. 7.

The hub of the system is the relational DBMS software, in which the process planning knowledge base is developed, and through which the process planning rules interact with the data in order to generate a process plan. Therefore the system contains process planning knowledge in the database and synthesizes the process planning rules by utilizing various data manipulation operations. New process planning knowledge and rules can be added into the system through the dialogue module.

The control module is responsible for the following two functions:

(1) System maintenance: This involves the initial acquisition of processs planning knowledge and the subsequent updating of this information when necessary. Much of the information will initially be obtained from the manufacturing environment, through machine specifications and other existing data. Later the database must be modified to reflect improvements in manufacturing technology, product design etc. These modifications will be carried out using the dialogue

224 Applications Computers m lndu~trv

<-

<-

Rules:

-->I Process rules planning

I The data manipulation processor

>

Facts :

-->[ The Relational DBMS i

Process planning knowledge

<~>

Dialogue Module:

Control Module

Fig. 7. The framework for an intelligent process planning system within the relational DBMS environment.

module as an interface between the system and the user.

(2) The management of the process planning process: This involves supporting and sequencing the operation of the other system modules, which together produce a process plan. Initially the control module interacts with the user, via the dialogue module, to determine the shape primitives which make up the part from the available shape primitives stored in the database, and to extract part-dependent information such as the overall dimensions, and material composition. The part- dependent information could conceivably be defined as new shape primitives, but at the present stage of development it is sufficient to enter these attributes as variables which are then used within the planning process. The control module uses the acquired information to interact with the process planning knowledge base and select the most appropriate manufacturing resources.

4.2. The Case Study

The case study illustrates the practical implementation of the intelligent process planning system architecture, using the PICK operating system to provide the relational database management system. The project has been undertaken with the support of a major UK manufacturing organiza-

tion, Dowty Mining Equipment Ltd, and is still undergoing development.

(1) The PICK Operating system This system provides a relational DBMS

equipped with an SQL-like language called ACCESS. It also supports a terminal control language (TCL), a job control language (PROC), an extended, com- piled version of BASIC, and other general system utilities [3]. The actual relational DBMS used for the development work was in fact REVELATION, which is a PC-based version of the PICK system.

(2) The Overall Approach The process planning system developed in the

case study is of a hybrid type, mainly because a hybrid system is simpler and quicker than a purely generative approach, which is particularly important for a PC-based system. The product range under consideration comprises a variety of prismatic components, which have been classified into part famihes through representative operations, each of which is associated with a generic process plan. The plan is stored and can be retrieved according to the variant methodology. Then operations are generated or modified as necessary using the process planning rules in order to produce the completed plan. Thus the term "intelligent" has been used to represent the system's ability to


Table 2 The relationship properties constrained by the manufacturing technology

Relationship Cardinality Dependency

Shape.Prim : Processing.Prim Many : Many Total Process : Machine Many : One Total Shape.Primitive : Tool Many : One Total Tool : Machine : Material Many : One: One Total Tooling : Machine : Part Many : One: One Total

encode and use specialist informat ion regarding the complex domain of process planning rather than " au toma ted generation of process plans" as some systems may have suggested [7,17].

(3) The Process Planning Knowledge Storage The general da ta model, which was previously

derived with respect to metal cutt ing application

Table 3 The files for storing the process planning knowledge

Feature

Machine

Shape

Tool

Tooling

Material

Process

Process Plan

The relationship relation between the Shape.Primitive and Processing.Primitive

The Machine entity relation, the relationship relation between the Machine and the Process.

The Shape.Primitive entity relation, the relationship relation between the Shape.Prim and the Tool

The Tool entity relation, the three-way relationship relation between the Tool, the Machine and the Material

The Tooling entity relation, the three-way relationship relation between the Tooling, the Machine and the Part.

The Material entity relation a

The Process or the Processing.Primitive entity relations b

Details of the process plan produced c

a A separate file for the material entity was created to support the material selection process. b The Processing.Primitive entity relation was considered to be synonymous with the Process entity relation, as the relationship between them is of degree one-to-one. c The process plan file was partitioned into two sections: the generic plans and non-generic plans. A coding and classifica- tion method, which is based on both the component geometry and the processing features, is used to partition the entities and grouping them accordingly.

domain, provides a start ing point for developing the database. The system under considerat ion is a Flexible Manufac tu r ing System with a fixed set of machines capable of a variety of processes, and where each machine has a fixed set of associated tools and tooling. Thus the relationship properties are more tightly constrained, as shown in Table 2.

The files were then constructed using PICK'S dict ionary files, based on the refined data model. Table 3 lists all the files created and their conceptual equivalences. For each file a pr imary key and a set of at tr ibutes were defined according to the terms used in the company , which are represented by fields within the file, with field number one being the key field.

As the files are created, the actions, namely insertion, deletion and update, must be specified to ensure data integrity. For example, one must ensure that it is impossible to create a record with a pr imary key that is identical to that of an existing one. The act ion specifications can be im- p lemented in terms of p rogrammed procedures so that whenever an opera t ion is to be carried out, it executes using one of the specific procedures specified for that file.

(4) Provision of the Data Manipulation Operations Considering the features of the process plan-

ning rules, it can be seen that support is required for SQL-like requests along with algorithmic procedures. The PICK system supports the match procedure through the ACCESS enquiry language, and the algori thms for the opt imizat ion process are encoded in PICK BASIC as software modules which can be accessed as required by the central control system. Several p rogramming routines have been developed to cover the opt imizat ion processes, ranging f rom simple algori thms working on one variable, to a complex operat ion sequencing programme. For example, the material selection module takes a material specification, such as BS970220M07, as input, and then searches for a material of the correct specification which most closely matches the required par t dimensions (plus a machining allowance). This involves simple comparison of at t r ibute values. A more computa- t ionally complex example would be the determina- t ion of the op t imum tool usage sequence on a single machine, where one has to utilize rules of thumb, such as "a lways remain on the same face after a tool change", and other algorithms, such as

226 Applications Computers m Industry

the minimisation of indexing with a particular tool.

(5) The Development of the Control Module The control system operates using hierarchical

menus to select modules, which are executed inde- pendently, to provide the necessary system functions. It consists of a coding module, a design validation module, a material selection module, and a variant process planning module. The first module allows a code to be developed automatically, based on a description of the part in terms of its constituent features, or shape primitives. This description can be fed into the system di- rectly from Computer Aided Design via an inter- pretation module, or input by the user. The design validation module performs validation on the proposed design which may lead to modifications being recommended if it is not possible to manufacture the product economically, or at all. The module checks the original dimensional and quality specification of the component against the machines and processes which are available. If an error is detected, for example, a surface finish is required which is impossible given the available machines and processes, then the user will be informed of the problem. A possible alternative (if one exists) is then suggested to the user, and a modification made. Further developments will allow automatic modification to be made, whilst still retaining a manual edit option. The third module selects a suitable material. The variant process planning module retrieves a process plan from the existing plans, which is assessed as the most suitable for the part in question according to the code which has been assigned.

(6) The Present and Future The system is now capable of accepting a part

description in terms of the previously defined standard features which make up the part, this design is validated, and then a similar plan is retrieved. The retrieved plan provides an outline of the processing required, and the system details the operations by linking the features, or shape primitives, to the necessary processes, tools, and machine tools, using a combination of the match and optimisation operations. Following the selection of the operations, the optimisation process is used to amend the sequence of the required operations , drawing on the algorithms stored in the

software library. The system for development of process plans has not yet been site-tested, but results of tests on existing parts have been encour- aging, with computer generated responses to input drawing information producing process plans very close to those of experienced process planners.

Future system developments include th provision of a feature library, refinement of the optimization algorithms to improve the quality of process plans produced, and the development of a framework to integrate the Intelligent Process Planning system with the design function, thus allowing automatic design optimization with regard to the manufacturing capabilities. The feature library is being developed at present, and will be available for interactive use within the process planning function. It is also hoped to provide the feature library at the design stage. The data table on the CAD-generated drawing will then hold information on the features, as opposed to the present situation where information on the size and position of the holes only is held. Initially the feature data may have to be added interactively, but the aim is to make these features available within the CAD system, perhaps as icons, so that the necessary information would be stored automatically during the design process, and trans- ferred immediately to the Intelligent Process Plan- ning System.

The system development will therefore allow the system architecture, and the feature-driven planning process, to be tested in a real-life situation, which is an under-exploited area in current research. In particular, attention will be paid to the suitability of the relational representation scheme, and the manipulation procedures suggested here.

5. Conclusions

There exists a gread deal of evidence to support the idea that people do not analyse new situations from scratch and then build new knowledge structures to describe those situations. Rather, they have available in memory a large collection of structures representing their previous experience with objects and situations. To analyse a new experience, they draw on appropriate stored structures and then enhance them using the details of


the current event. Clearly the process planning process is undertaken in this manner.

In this paper the structure of the process planning knowledge has been formalized and represented in terms of a set of relations in the context of the metal cutting environment, which then allows the construction of a relational database for storing the process planning knowledge. The features of the process planning rules have also been identified in terms of a set of data manipulation processes, some of which can be supported by the RDBMS software. The paper has also identified a scope for further development in certain areas:

(1) An expert advisor to support the relational DBMS: This would translate the generic data model into a physical model automatically, taking into account the unique properties required by the users and the database design rules.

(2) Provision of the data manipulation operations: As mentioned before, the relational DBMS does not support the optimization type of data manipulation process, therefore there is a need for the development of a generic set of algorithmic procedures to provide efficient and effective solutions. These would be stored in a programming library created within the relational DBMS environment, in order to support the process planning activity.

(3) The features of the Control Module: In this paper the control module was created to support a particular case study. More work needs to be done to determine the essential features of the Control Module. This may lead to the creation of a generic Control Module for supporting the process planning activity in a defined industry domain.

Acknowledgements

The authors wish to thank Mr. G.W. Smith for his invaluable guidance and personal encourage- ment throughout this research.

References

[1] G.M. Alder et al., "Computer aided selection of machining processes", Proc. 2nd Int. Conf. Computer Aided Pro- duction Engineering, Edinburgh, 1987.

[2] S. Bandyopadhyay, A. Sengupta and S.P. Dutta, "The architecture of a knowledge-based process planning system for small scale industries, lnt. J. Adv. Manuf. Technol., Vol. 2, No. 3, 1987, pp. 37-47.

[3] R. Bourdon, "The PICK operating system", Computing Techniques, January 1988.

[4] T. Chang and R.A. Wysk, "An integrated CAD/automated process planning systems", AIIE Trans., Sept. 1981.

[5] Chao-hsien Chu and Hsu-pin Wang, "The use of artificial intelligence in process planning", Int. J. Prod. Manage., Vol. 8, No. 1, 1988.

[6] C.J. Date, An Introduction to Database Systems, Addison- Wesley, Reading, MA, 4th edn., 1986.

[7] B.J. Davies, "Application of expert systems in process planning", Ann. CIRP, Vol. 35, No. 2, 1986.

[8] B.J. Davies and L. Darbyshire, "The use of expert systems in process planning", Ann. CIRP, Vol. 33, No. 1, 1984.

[9] S.M. Dean, New Frontiers in Relational Languages from the Relational Database Systems - - State of the Art Report, edited by C. Bell, Pergamon Infortech, Oxford, 1986.

[10] M.A.H. Dempster, et al., Deterministic and Stochastic Scheduling, D. Reidel, Dordrecht, The Netherlands, 1981.

[11] W. Eversheim and H. Esch, "Automated generation of process plans for prismatic parts", Ann. CIRP, Vol. 32, No. 1, 1983.

[12] M.P. Groover and E.N. Zimmers Jr., CAD~CAM, Pren- tice-Hall, Engiewood Cliffs, NJ, 1984.

[13] G. Halevi, "Development of flexible optimum process planning procedures", Ann. CIRP, Vol. 29, No. 1, 1980.

[14] P. Husbands, F. Mill and S. Warrington, "A knowledge based process planning system from knowledge based system", in: Siriam and Adeay (eds.), Engineering Plan- ning and Design, 1987.

[15] G. Jackson and R. Wilson, "CAPP--Ture the imagin- ation", Comput. Manuf., February 1989.

[16] Ch.S. Knox, Organising Data for CIMApplications, Marcel Dekker, New York, 1988.

[17] S.T.R. Kumara, et al., "Expert systems in industrial engineering", Int. J. Prod. Res., Vol. 24, No. 5, 1986.

[18] A. Kusiak, "An integer programming approach to process planning", lnt. J. Adv. Manuf. Technol., Vol. 1, No. 1, Sept. 1985.

[19] Y.C. Lee and K.S. Fu, "A relational approach to the integrated management system for computer-aided manufacturing", A S T M Spec. Tech. Publ., 1985.

[20] D. Nan and T. Chang, "Hierarchical representation of problem-solving knowledge in a frame-based process planning system", Int. J. Intelligent Syst., Vol. 1, 1986, pp. 27-44.

[21] U. Rembold and R. Dillmann, (eds.), Computer-Aided Design and Manufacturing." Methods and Tools, Springer- Verlag, New York, 1986.

[22] A.H. Van 't Erve, "Generative computer aided process planning for part manufacturing: an expert systems approach", PhD Thesis, Twente University of Technology, The Netherlands, 1986.

[23] A.H. Van 't Erve and H.J.J. Kals, "XPI.ANE: A generative computer aided process planning system for part manufacturing", Ann. CIRP, Vol. 35, No. 1, 1986.

[24] H. Walker, Internal Report, Department of Manufactur- ing and Engineering Systems, Brunel University, Ux- bridge, U.K., 1988.

[25] Hsu-Pin Wang and R.A. Wysk, "Intelligent reasoning for process planning", Computers in Industry, Vol. 8, 1987, pp. 293-309.

228 Applications Computers in lndustl T

[26] Hsu-Pin Wang and R.A. Wysk, "A knowledge-based approach for automated process planning", Int. J. Prod. Res., Vol. 26, No. 6, 1988.

[27] Ming Wang, The intelligent database design environment

(IDDE) for the design and implementation of CIM information systems", Working Paper No. 89-3, Depart- ment of Economics and Management Science, University of Keele, U.K., 1989.

creation of an intelligent process planning system within the relational dbms software environment

Documents