INTRODUCTION

This paper reports on a collaborative research project between CIRP members that was started in 1990. This project is carried out partly in Ontario, Canada at McMaster University and the University of Western Ontario, and partly in Baden-Würtemberg at the Fraunhaufer Institute for Production Automation (IPA) in Stuttgart. The aim of the project is to further research in the field of fully automated process planning and real time production planning and control. The research focuses on the integration of the two systems CAPP (Computer Aided Process Planning) and PPC (Production Planning and Control). The objective is to establish a strong link between the two activities CAPP and PPC which is more responsive to unexpected events on the shop floor such as bottlenecks and resources shortages. Some of these problems cannot be solved by scheduling techniques only and require replanning of the processes themselves, with the least disturbance of the overall production system. Our research focuses on the integration issues between the two systems, the representation of products and processes, and resource data representation and exchange, event handling and “real time” related issues, common definition of variables and attributes, and the use of standard databases.

NEED FOR CAPP/PPC INTEGRATION

An outline of CAPP research may be found in the papers by Alting and Zhang(1989), Ham and Lu (1988), Eversheim (1985), Lenau and Alting (1990), and Weill et al. (1982). Most the research has centered around metal cutting processes. Ham and Lu (1988) suggested future directions for research efforts in CAPP. The authors pointed out that process planning is often carried out without consideration of job shop status information, such as resource availability, breakdown of equipment or disruptions caused by stochastic bottlenecks. Replanning is done by improvisation and can result in long through-put times. Eversheim et al. (1990) describe the current situation of orders processing in industry as: “detailed information about the order on the one hand and the actual shop floor situation on the other hand are not available; realistic planning of the order processing is still the exception”. The authors propose an Assembly Management System which should provide sufficient information about the actual situation in case of disturbances. It is suggested that during order processing (planning), process alternatives, which mirror the flexibility of the assembly process, be incorporated. However, integration and common definition between CAPP and PPC are not discussed. Another paper dealing with the subject of integration, from a high-level CIM perspective, is a model presented by Harhalakis et al. (1990). The model discusses integration at the facility level and is presented along with the rules of interaction between the constituent modules. The authors used this approach to automatically update the various databases used by CAD, CAPP, and MRP. Törnshoff and Detand (1990) proposed, as part of the ESPRIT Project 2457 FLEXPLAN, a “process description concept” which can be used by planning, scheduling and control systems throughout a manufacturing environment. A Petri-net graph-based representation is generated during process planning. It provides information structures which can be continuously enhanced during the progress of manufacturing. For example, the PPC system calculates order due dates, the scheduling system determines planned start and termination dates as well as resource allocation data, and the monitoring system updates the actual process history. However the issues of events and related feedback from PPC to CAPP to respond to shop floor “disturbances” and the way for CAPP to replan are not discussed. This approach assumes that the systems to be integrated e.g. - the CAPP and PPC systems - use Petri nets.

An approach for replanning “on-line” is presented by Ruf and Jablonski (1990). In this approach it is proposed that a static process planning system be used which identifies all combinations of manufacturing resources that are suited to produce a part. A dynamic resource allocation system decides on-line which of the possible resources have to be used in order to execute a manufacturing order. The paper deals with a feature-based part description, and does not consider issues of integration with a PPC system.

In summary, traditional CAPP systems are static, linear (strictly sequential), and they assume unlimited factory resources. To achieve an optimal schedule, process plans should take into consideration the actual workshop status as well as any capacity constraints. The reviewed research shows the necessity of breaking away from the process plan as a static and linear sequence, and the need to have plans that are able to represent parallelism and alternative operations or resources. Similarly PPC systems should use a strategy that can benefit from the non-linear, alternative plans representation. The task of integrating such CAPP and PPC systems, even in the presence of such capabilities, is not a minor one. This paper focuses on this important subject, which has not been much discussed in previously published research. In particular, we wish to discuss the need for common definitions and the use of distributed vs. standard and common databases. The type of events and resulting communication between various modules in a concurrent engineering and parallel heterogeneous processing environment are also considered.

APPROACH TO CAPP/PPC INTEGRATION

There are three possible approach for integrating CAPP and PPC. The first approach is a high-level integration of functions and CIM modules which can be called a “global integration scheme”. The work of Harhalakis et al. (1990) is in this category. Each CIM module (CAD, CAPP, and MRPII) is allowed to maintain its own database and an updating scheme is devised. This method is very data intensive, and results in duplication of data, and does not address the need for non-linear plan representation which considers actual manufacturing resources and constraining resources and events. The manufacturing systems’ “events” are not considered. Instead their events relate to each individual data record, not to the status of the modules in the system.

The second approach is the opposite extreme, and proposes complete integration of planning and scheduling. In this approach CAPP and PPC become one system. The merits of this is that planning and control depend on each other and must ultimately use the same data. Moreover, the borderline between planning scheduling and control is fuzzy. In this approach the system should obviously use a common database management system. The representation would be common, using Petri-nets for instance, to model logical and temporal relationships. FLEXPLAN is a system being developed in that direction by Törnshoff and Detand (1990).

However, CAPP systems are essentially time independent, while PPC systems are necessarily time dependent. Today’s CAPP systems do not take these dependencies into account. Even if we overcome this difficulty and merge the planning optimization task and the scheduling optimization task into a single optimization task, it cannot be solved due to complexity reasons as noted by Törnshoff et al. (1989).

The third approach, which is described in this paper, can be considered a realistic intermediate between the first two approaches. The proposed approach to integration is essentially modular. In this, Process Planning and Production Planning and Control do not need to be one system. However, the CAPP and PPC systems need to have the ability to interact with shop floor disturbances (events), non-linear process plans, and resources and constraints. Physically the database can be common or a standard distributed database. However common definitions, structures, interpretations of events and synchronization issues in a multi-tasking networked/parallel environment are considered. In fact in this approach a separate module called the “Integrator” is used. It should be recognized however that the boundaries between the various modules are in fact arbitrary. Several physical implementations are possible. The modular approach has practical advantages including flexibility of implementation as well as the possibility of integrating existing CAPP and PPC systems. In the remainder of this paper we describe the functions of the Integrator, and the RPE (Reactive Planning Environment) module which was developed in connection with this project (Stranc 1992). RPE allows for representative evaluation, and selection of alternate plans. The PPC system which is addressed in this project is GRIPPS (Kuhnle 1991).

RPE REACTIVE PLANNING ENVIRONMENT

The reactive planning environment (RPE) system is conceived and implemented to achieve a number of objectives:

1. Represent process plans at various levels of detail and abstraction to suit both detailed process planning (micro) and operations planning and sequencing (macro).

2. Allow the combination and representation of mixed domain operations in a plan. In particular it deals with product assembly planning as well as other processes which may be required to complete a product such as welding, soldering, cleaning, inspection, fabrication and machining at the macro operation level (not detailed task planning).

3. Represent precedence constraints for a given task as well as the resources required for completing the task.

4. Capture and model alternate resources, alternate routes and alternates processes, albeit less than optimal, along with the preferred or best plan.

5. Represent the resources and plant by models compatible with those used by PPC systems.

6. Allow alternate plans evaluation, according to user defined criteria such as time, scrap rate, load balancing and cost, and selection of the best plan under given conditions such as absence or over-utilization of certain resources.

The RPE system is designed and implemented, under the direction of Professor Hoda ElMaraghy at McMaster University, by C. Stranc (1992), and P. Nguyen.

A scheme for representing micro and macro tasks in a process plan and routing sheets using a multi-layered precedence graph has been developed. Resources are modelled and associated with each task. ‘PreConstraints’ define order between macro tasks (operations). ‘AltConstraints’ are used to specify alternative processing methods within a process plan which can achieve a common end result (Figures 1, 2, 3, & 4). For example, alternate plans for a product assembly using manual, semi-automatic or fully automated systems may be represented and used as substitutes to deal with bottlenecks. These alternatives are examined and evaluated as needed, using graph search methods, in response to feedback from the PPC system.

INTEGRATING RPE WITH CAPP & PPC

RPE uses a feature-based, object-oriented approach (ElMaraghy, 1991) to represent a product structure hierarchically. Bills of material produced by conventional CAD systems may also be used. Current process planners produce detailed (micro) tasks in a single domain (e.g. machining or assembly). The resulting plans are input to RPE and corresponding precedence graphs are generated. These are edited and modified interactively by the user to add operations not considered by the micro process planners. It is also possible to enter the whole plan and alternatives interactively by the user through an effective graphical interface. The output from RPE is the recommended plan. The precedence graph process plan format would be useful to those PPC systems which are capable of using this powerful representation in rescheduling. Alternatively, the precedence graph is converted to the usual sequential process plan format in a flat file for use by traditional PPC systems. This allows RPE to be interfaced with conventional PPC systems currently in use. The selected plan and operations sequence are also displayed along with the resources layout within the plant.

PPC systems often aggregate individual resources (machines, tools etc.) into a higher level resource called a capacity group. One of the important integration issues we faced was the development of a clear definition of resource models used by CAPP and RPE and capacity groups used by PPC and a mapping between the two.

THE CAPP/PPC INTEGRATOR

The interprocess communications used between CAPP, RPE, and PPC are divided into two categories,

- Common data (process plans and resources)

- Events (a notification of a change in data status, or a request)

The data is produced, utilized and updated by the CAPP, RPE, and PPC systems. When data is changed, it results in a data change notification event. If a system wants to declare data invalid, it does this with a request. Therefore, when operating in steady state the interfaced systems pass events and requests to push and pull process plans in production.

The issue of common data may have a profound impact on the event types which the system uses. For example, if a CAPP system is based on its own proprietary data base (or files), and the PPC system is based on another database, then:

- there are two copies of all plans,

- the internal representations may be different,

- transfer between databases is difficult.

This problem also occurs when using files, or other data storage mechanisms. Therefore, in lieu of a common database the integrator should use its own internal common data definition to transfer data between CAPP, RPE and PPC. The primary (and novel) function of the Integrator is dealing with events from CAPP, RPE, and PPC. Events are passed to the integrator using messages, and then to another client using messages. Depending upon the message source, and content, the Integrator may send a message to another process. The content of messages will commonly be:

- a notification that data has changed,

- a request to change data since a failure has occurred, and the data must be changed (request).

If a common data base is used, then a message does not need to contain any data, and only needs to refer to the data which has been changed. If a common database is not used, then the integrator must maintain its own database, which is updated when data changes. This update may come in two forms: either all data is passed as messages, or all data is remotely accessed from files and databases. To summarize, the three types (cases) of event handling features of the CAPP/PPC integrator are:

With common databases,

1. Pass references to changed data.

Without common database,

2. Pass all changes as messages

3. Pass references to all changes to be read into the Integrator database from CAPP, RPE and PPC databases and files.

Passing data as in case 2 is time consuming, and the integrator may be overwhelmed by the volume of data. Using the common database is the simplest solution, except that all applications are tied to the same database software. The final method in case 3 uses the references to changed data to load common data structures in the Integrator. It is commonly agreed that simply passing a reference to changed data is the best mechanism. Cases 1 and 3 above are dependant on direct access to the outside data sources, common or not. The case 3 approach was chosen to accommodate the greatest number of CAPP and PPC systems. Case 1 should be adopted when a global and common database is used.

For our implementation the Integrator uses the same database used by PPC. In this case it is a commercial Relational Database, and the PPC system is GRIPPS (Kuhnle, 1991). The RPE program runs on PDL files (ElMaraghy, 1991), and thus the integrator will handle reading these files and writing the data to the commercial Database. A similar function occurs for the CAPP system.

Two methods for communication between processes have been developed independently, but provide the same functionality. In the first message passing mechanism, a database table is used to store messages which may be picked or issued by any database client. In the other method, a message server (Jack and ElMaraghy, 1992) is used, and connects all modules (CAPP, RPE, PPC, and the Integrator) through the use of TCP/IP sockets (Sechrest, 1986). Using a complex communication scheme, messages are routed between groups. This method of communication is suited to client programs which are not registered on the database. The block diagram of the CAPP/PPC Integrator is shown in Figure 5.

Figure 5 illustrates the basic structure of the software. The message layer deals with interprocess communication between the Integrator and CAPP, PPC and RPE. The Executive routines track message content, and decide how to respond, by directing data transfer and issuing new events. The data structures are used for internal storage of the data when transferring between applications. To load these structures there is a generic data interface layer, which may use various sources of data. These source are PDL, a standard database and CAPP files. The final features shown are the filtering routines. The filter functions will “screen-out” resources which are unavailable or overutilized for planning. This is used when sending resource data to RPE.

In Figure 6, the basic flow of events is pictured. All events will start when a message is issued from CAPP, PPC, or RPE. This message will trigger the loading of data into the Integrator. The data is then downloaded to another data store, using filtering if required. A message is then issued to the recipient of the new message.

Common Data Definition:

The definitions of common data are essential to make the CAPP/PPC Integrator work. These are required so that data from either CAPP or PPC could be put in a common format, which could then be translated into another format. This also gives the Integrator the ability to store plans if required. While CAPP and PPC have common requirements for the process plans themselves, there is a significant difference in the representation of resources. The PPC program uses the concept of Capacity Group, which described a collection of resources, while CAPP and RPE refer to resources. Therefore the common definition of data includes a mapping between resources, and the capacity groups they are lumped into.

Figure 7 below shows the basic process plan structure used in the common data definitions. This representation was influenced by the PPC program GRIPPS (Kuhnle, 1991).

On the other hand a complete description of resources is required so that the CAPP and RPE programs can pass adequate information so that when a PPC plan fails because of a capacity group, the failure can be mapped back to a particular resource.

Integrator Events:

The event model is flexibly defined, to allow updating when newer CAPP and PPC system technologies have become available. The list pictured below gives a good indication of what these events are,

From CAPP to the Integrator

- A new process plan is ready

- An updated version of a process plan is ready

- Process plan is unavailable

From the Integrator to CAPP

- A process plan has failed

- A process plan is required

From RPE to CAPP

- An optimal process plan for available resources is ready

- Process plan is not available

From CAPP to RPE

- Optimize process plan

From PPC to Integrator

- Process plan required

- Resource is unavailable, send new plan

- Resource is over-utilized, send alternate plan

From Integrator to PPC

- A new process plan is available

- A revised process plan is available

These events are encoded as part of the message, along with the reference to data (process plans or resources).

REFERENCES

Alting L., and Zhang, H., 1989, Computer Aided Process Planning: the state-of-the-art-survey, The International Journal of Production Research, vol. 27, no. 4, pp. 553-585.

ElMaraghy, H. A., 1991, Intelligent Product Design and Manufacture, in Artificial Intelligence in Design, edited by D. T. Pham, Springer-Verlag, pp 147 - 169.

Eversheim, W., 1985; Survey of Computer Aided Process Planning Systems, CIRP Annals, Vol. 34/2/1985.

Eversheim, W., Grop, M., and Lehmann, F., 1990; Innovative Assembly Management; CIRP Annals, Vol. 39/1/1990, pp. 1-4.

Ham, I., and Lu, S., 1988, Computer Aided Process Planning: The Present and The Future, Annals of the CIRP, Vol. 37, pp. 591-602.

Harhalakis, G., Ssemakula, M. E., and Johri, A., 1990, Architecture of a Facility Level CIM System, Proc. of CIMCON’90, U. S. Government Printing Office, pp. 430-445.

Jack, H., and ElMaraghy, W. H., 1992, A Manual for Interprocess Communication with the MPS (Message Passing System), DAMRL Report No. 92-08-01, The University of Western Ontario, London, Ontario, Canada.

Kuhnle, H., 1991, IPA Stuttgart Germany, personal communications regarding the IPA GRIPPS system for PPC.

Lenau, T., and Alting, L., 1990; Prerequisites for CAPP; 22nd CIRP International Seminar on Manufacturing Systems, University of Twente, Enschede, Netherlands.

Ruf, T., and Jablonski, S., 1990, Flexible and Reactive Integration of CIM Systems: A Feature Based Approach, CSME Mechanical Engineering Forum.

Sechrest, S., 1986, An Introductory 4.3BSD Interprocess Communication Tutorial, in Unix Programmer’s Manual Supplementary Documents 1, by The Computer Systems Research Group, The University of California.

Stranc, C., 1992, M.Eng. Thesis, in progress, McMaster University, Hamilton, Ontario, Canada.

Törnshoff, H.K., and Detand, J., 1990; A Process Description Concept for Process Planning, Scheduling and Job Shop Control, 22nd CIRP Intern. Seminar on Manu. Sys., Univ. of Twente, Enschede, Netherlands.

Törnshoff, H.K., Beckendorff, Ur, and Anders, N., 1989; FLEXPLAN - A concept for Intelligent Process Planning and Scheduling”, CIRP Intern. Workshop on Computer Aided Process Planning, Hannover University Sept. 21-22, pp. 87-106.

Weill, R., Spur, G., and Eversheim, W., 1982; Survey of Computer-Aided Process Planning Systems, CIRP Annals, Vol. 31/2/1982.

BCAPP Report