1.3 INPUTS AND OUTPUTS FOR PROCESS PLANNERS

Before discussing the details of how process planners operate, it is worth a short consideration of the planning context. There are a number of inputs to planning systems as reported in Lenau [1992]. These vary widely, and can have drastic effects on the abilities of the planner. At the output there are a number of factors required for complete process plans, but previously established manual methods have provided a thorough understanding of the requirements.

1.3.1 Process Plan Modeling

It is necessary to specify what information will be requested in a process plan that is modelled in a particular system. While the decision seems obvious there are a number of fundamental factors to be considered. First, there is the process description that varies greatly between each technology and manufacturing facility. Second, and more challenging, is the relationship (such as operation precedence) between operations. When dealing with a simple linear plan all we have is a list of operations. If the process plan is non-linear it can have parallel or alternative operations and we must look to more sophisticated representations.

Assuming the non-linear process plan is stored in a graph, then the nodes and arcs could be assigned in a number of ways.

• Operations

• Operation Steps

• Resources (typically machines or capacity groups)

• State of the Work in Process

• Routings

When dealing with assembly process plans this can be represented with numerous Bill Of Material (BOM) and operation sheets. The state of Work In Process (WIP) is well suited to inspection planning for parts. Routings and Work orders are better suited to batch orders where the production conditions may vary. All of these methods represent various manifestations of the fundamental data. The data itself has a few important data structure requirements,

• plans for various workparts,

• alternate plans for a workpart,

• a list of operations in a plan (with precedences),

• alternate operations for an operation in a plan,

• a list of steps for an operation (with precedences),

• alternate steps for each step,

• detailed data about each of the above levels of plan hierarchy.

Many methods to date limit these requirements for practical reasons. For example XPS-2 [Nolan, 1989] uses a process plan structure which is shown in Figure 1.1 Process Plan Data Interface Specification (PPIS) Hierarchy.

 

Figure 1.1 Process Plan Data Interface Specification (PPIS) Hierarchy

This structure is further augmented with sequencing graphs to determine the precedence of the various plan steps.

A method to indicate parallel, and alternative operations was reported by Tonshoff et. al. [1989]. They opted for a plan representation using Petri nets. Using this structure they were able to create plans that could be easily rescheduled when problems occurred on the factory floor that invalidated a process plan operation. A similar approach was adopted by Kruth and Detand [1992]. Mantyla [1993], suggested a process plan structure capable of defining process plans for the relationships between steps and alternatives for operations.

1.3.2 Product Modeling

The geometrical and non-geometrical knowledge about a product design can be difficult to represent formally. As a result many methods have been developed for representing a product design.

• Frames/Features

• B-Rep (Boundary Representation)

• CSG (Constructive Solid Geometry)

• Decision tree

• 2D drawings

• Group Technology (GT)

Frames can be used to represent data that is in a fixed format, such as machining features. The example in Figure 1.2 Part of a Frame Based Feature Model was taken from Kusiak [1991]. In the example the feature is a rectangular pocket, and dimensions are given with tolerances. Other information such as surface finishes, and wall thicknesses are also given for planning purposes. Finally, the connectivity of the feature to other faces on the part is defined.

 

Figure 1.2 Part of a Frame Based Feature Model

Frames are fairly rigid in their form, and are therefore commonly used with feature based models. The reader should be aware that there are also examples where frames and features are not used together. These models experience difficulties when a nonstandard (not available in the modeler) feature is required [Karinthi and Nau, 1989][Shpitalni, 1991]. Many systems have been developed with feature based representations, such as Kjellberg et. al. [1990] and Hummel and Brooks [1986]. There are also CAD systems capable of doing design by features, such as those by H.A. ElMaraghy [1991] and Arikan and Totuk [1992]. More recent work has implemented features in an object oriented framework [Marefat et. al., 1993] [McNeilly, 1993]. For some extensive lists of features see Wilson [1983] and ESPRIT [1990].

Boundary Representation (B-Rep) has become the most popular method of representation for solid modelers and, as a result, for new CAPP systems also. B-Rep models explicitly define all of the faces on a solid, as well as the connectivity to other faces. But one problem with these models is that after the model is created, features must be recognized by examining sets of faces. It is difficult to associate feature type information with these models, because the feature is not present in the stored model. But, by far it is most difficult to extract a single feature when multiple features intersect.

Constructive Solid Geometry (CSG) is a useful approach that carries high level information, and can be easily interpreted into B-Rep easily at any time, whereas conversion from B-Rep to CSG is very difficult [Brun, 1989]. Early work in CAPP has seen a simple CSG model used by Woo [1977], but there have not been many other uses since then. This method has a problem dealing with non-primitive shapes. At present there are some approaches to incorporating splined surfaces into CSG models, such as Ling et. al. [1987] who modelled sheet metal bends with CSG. Varady [1986] had investigated incorporating splined surfaces into the Build solid modeler (an early research solid modeler). He supplied a normal vector to identify outside surfaces, and he used the surfaces for CSG cuts.

Some older methods rely upon input of data from 2D drawings. When used for rotational parts these can be very effective (turned parts can be considered 2D). But, when dealing with 3D objects, the model becomes ambiguous. Another older approach is based upon querying the user about the part in question. In effect the user answers questions from the computer and, as a result, a decision tree is traversed.

Group Technology (GT) is a very popular abstract method for representing designs. It is used to identify subsets or families of similar parts for the purpose of realizing common features. This improves the design and process efficiency through standardization. The GT codes can be made to represent products by using any combination of geometry, manufacturing process, or function. The advantages of using such a coding system are standardization, reducing design proliferation, and it provides a basis for value engineering. To reduce the proliferation of new designs, GT can be used to perform searches for existing designs. The standardized plans also provide a basis for standard values for time and cost. In most cases GT codes are used in Variant systems, but in one case a Generative system was developed using a GT code as the basis for generating plan steps [Iwata et. al., 1987].

GT methods are highly sensitive to the specific GT code selected. Despite the attempt to create a standard code, the results always have to leave options for customization. Also, because GT codes are an abstract representation of a part, they do not carry enough detailed information for representing the part.