A Shop Floor Control Architecture for

Computer Integrated Manufacturing

by

Jeffrey S. Smith

Texas A&M University

239A Zachry Engineering Center

College Station, TX 77843-3131

Walter C. Hoberecht and Sanjay B. Joshi

The Pennsylvania State University

207 Hammond Engineering Building

University Park, PA 16802

Abstract

The evolution to CIM has been slower than expected. This can be directly attributed to high software development and maintenance costs and the difficulty in achieving the required levels of integration between systems. These problems are especially evident in the development of the shop floor control system (SFCS). Many researchers have developed “standard” CIM architectures. However, these structures are often verbose, textual descriptions which are ambiguous and lack formality. This makes descriptions based on these architectures unsuitable as a basis for control software development. Furthermore, without a formal language for describing manufacturing systems, it is difficult for researchers to discuss and compare different system configurations. In light of these problems, this paper identifies a formal structure for shop floor control. The formal structure is based on a three-level hierarchical control architecture. The purpose of this structure is to allow manufacturing systems to be described completely and unambiguously. This description can then be used as a basis for control software development, which will simplify the implementation of automated CIM sytstems.

Keywords: Shop floor control, Flexible Manufacturing Systems, Computer Integrated Manufacturing, Control architecture, Formal Model

1.Introduction

Computer Integrated Manufacturing (CIM) has recently received a great deal of attention as an effective strategy to improve manufacturing responsiveness and quality. CIM seeks to integrate the entire manufacturing enterprise using a network of computer systems. However, the evolution to CIM has been slower than expected. This can be directly attributed to the high software development and maintenance costs and the difficulty in achieving the required levels of integration between systems (Ayres, 1989; Merchant, 1988). These problems are especially evident in the development of the shop floor control system (SFCS). The SFCS is responsible for planning, scheduling, and controlling the equipment on the shop floor.

In order to define the requirements for system control many researchers have developed “standard” CIM and FMS control architectures (Beechman, 1989; Jones and McLean, 1986; Jones and Saleh, 1990, Joshi et al. 1990; Senehi et al., 1991). These architectures attempt to identify a standard structure for computer controlled manufacturing systems. However, these architectures have not been defined in sufficient detail to address the software development and maintenance problems associated with the implementation of a SFCS (Ayres, 1989; Mettala, 1989). In fact, control systems still appear to be extremely implementation specific even if the designers adhere to one of the “standard” architectures. One explanation for this is that most of these architectures are simply verbose, textual descriptions of the manufacturing system’s general structure and there is no concentration on the development of the required control systems. Consequently, these descriptions are often ambiguous and incomplete, and, hence, are inappropriate as a basis for software development. In addition, it is difficult for researchers to discuss and compare different system configurations without a standard “language” for describing the manufacturing systems.

We propose to integrate the system design and software development phases of SFCS implementation. Our research has been focused on creating a shop floor control software development methodology using Computer Assisted Software Engineering (CASE) tools. This methodology will reduce controller software costs while also providing improved levels of manufacturing system integration. The improvements in system integration stem from the formal descriptions of the components. Once the individual components’ behavior is completely defined, the interactions between individual components can be formalized. This concept is illustrated in Figure 1. Within this paradigm, the control architecture provides the formal structure under which the specific implementation can be described. This formal description can then be used as a basis for control software development. In order to develop these tools, we have found it necessary to extend the traditional shop floor control architecture to include formal definitions of the individual components of the architecture. In this context, the term formal implies precise and unambiguous.

The formal definitions of the shop floor configuration are used as input to a software generation system and provide a means to describe different shop floor systems for comparisons. The software generation system is based on a formal model of the control requirements (Smith, 1994b), and a C++ class library implementing the details of the individual controllers (Smith, 1994). These two components supply the control model and software generator illustrated in Figure 1. This paper presents the extended control architecture required to generate the implementation specific description of a system that serves as the input. The control architecture presented here is not a unique solution to the problems described. Instead, it illustrates that there is a formal language in which control architectures can be expressed which allows for construction of generic controllers. The development of these controllers has been demonstrated in two laboratories and is described in detail by Smith (1992) and Smith and Joshi (1994, 1994b).

The target manufacturing environment is characterized by having a large number of distinct part types and low production volumes, approaching single part production. Furthermore, processing is performed on general purpose machine tools without requiring extensive setups or changeovers. Shop floor control in this environment is an extremely broad topic. A complete description of all facets of this problem would fill an entire book. This paper seeks to identify a detailed architecture for shop floor control which facilitates the automatic or semi-automatic generation of a significant portion of the control software. The rest of this paper is organized as follows. Section 2 provides a brief background on control architectures. Section 3 describes the proposed architecture and controller structure. Section 4 describes a methodology for SFCS development which is based on the proposed structure.

2.Background

In the context of shop floor control, a control architecture should provide a blueprint for the design and construction of a SFCS. It should completely and unambiguously describe the structure of the control system as well as the relationships between the system inputs and the system outputs. Albus et al. (1981) describe a hierarchical robot control system and identify three basic guidelines for developing manufacturing control hierarchies: (1) Levels are introduced to reduce complexity and limit responsibility and authority, (2) each level has a distinct planning horizon which decreases as you go down the hierarchy, and (3) control resides at the lowest possible level. The robot control system introduces the concept of integrating hierarchically decomposed commands from higher levels with status feedback from lower levels to generate real-time control actions.

The National Institute of Standards and Technology (NIST) has been developing an Automated Manufacturing Research Facility (AMRF) since 1981. The purpose of the AMRF is to provide a testbed for research directed towards the development of standards for use in flexible manufacturing (Jones and McLean, 1986; Simpson et al., 1982). As a part of their research, a hierarchical control architecture has been developed. A new project at NIST called the Manufacturing Systems Integration (MSI) project has been established to refine and extend the original NIST architecture work (Senehi et al., 1991). One of the main contentions of the MSI group is that the five level hierarchy imposed by the original NIST architecture is too rigid in structure. In response, the new MSI architecture only defines three types of controllers: equipment, workcell, and shop. A hierarchical structure of arbitrary depth can be constructed using these three types of controllers. However, the primary concern in the MSI project has been to develop standards for system (i.e. controller) interconnection. There has been little work reported on methods for system development and implementation.

One of the primary limitations of the original NIST implementation is the lack of sophisticated planning and scheduling at the lower levels in the hierarchy (Jones and Saleh, 1990). As a result, there are essentially only two distinguishable layers. One to do the decision making and one to do the control. As a result of these inherent problems, Jones and Saleh (1990) propose a so-called “multi-level/multi-layer” control architecture. The structure of this architecture is based on both spatial and temporal decompositions of the system. An important aspect of this architecture is the decomposition of the control tasks at each level into adaptation, optimization, and regulation functions. Joshi et al. (1990) present a three level hierarchical control model based loosely on the lower three levels of the original NIST hierarchy. According to this “scaleable architecture,” the tasks for each controller are separated into planning, scheduling, and control tasks. These tasks are similar to the adaptation, optimization, and regulation functions described by Jones and Saleh.

Judd et al. (1990) describe a methodology and a related set of tools for developing manufacturing system control software. These tools have been developed based on early work by Naylor and Volz (1987) dealing with the development of integrated manufacturing control software. In this work, they introduce the notion of a software/hardware component as an integrated assemblage of a machine and the control software for that machine. Judd et al. (1990) have extended this concept and created the formal specifications for these components. This formal machine control specification is critical in the development of integrated systems, however, this work concentrates only on the low-level physical control and does not yet consider the higher-level planning and scheduling aspects of an integrated manufacturing system. Related work dealing with these planning and scheduling aspects within the software/hardware component concept is described by Chaar (1990).

Recently, several researchers have expressed concern over the rigidity of the hierarchical structure. Hatvany (1985) points out the need for a new type of manufacturing control model which will: 1) permit total system synthesis from imperfect and incomplete descriptions, 2) be based on the automatic recognition and diagnosis of fault situations, and 3) incorporate automatic remedial action against all disturbances and adaptively maintain optimal operating conditions. Duffie and Piper (1987) present a part-oriented heterarchical control system in which each individual part and machine is represented by a system entity. Part entities have knowledge about the processing that they require and machine entities have knowledge about the processing that they can perform. Part entities “broadcast” processing requirements over the system network and machine entities similarly broadcast processing availability. When a match is found, the part and machine entities negotiate and, once an agreement is made, the part is transported to the machine and processing begins.

Upton et al. (1991) present some preliminary results in the use of heterarchical systems for manufacturing system control. The results are based on a simulated manufacturing system with a standard part flow and multiple possible machines (each with a different processing time for similar parts). Upton et al. point out that, based on the simulations, the distributed architecture dispatches jobs as a centralized controller might: using the best machines when idle, and progressively less effective machines when busier. Upton et al. state that further research in process planning, communications, and on-board information processing is required in order to make the heterarchical architecture feasible for shop-floor control. Lin and Solberg (1992) also describe a “market-based” heterarchical control system based on autontomous agents. This model uses a pofit-directed mechanism for component negotiation.

Ostroff (1990) describes a temporal logic based controller for real time discrete event processes. Based on the characteristics for these processes, small to medium discrete parts manufacturing environments are certainly within this domain. Furthermore, Ostroff goes on to describe some of the benefits of a formal framework for these systems:

  • in the process of formalizing informal requirements, ambiguities, omissions, and contradictions will often be discovered.
  • the formal model may lead to hierarchical semi-automated system development methods.
  • the formal model can be verified for correctness by mathematical methods.
  • a formally verified subsystem can be incorporated into a large system with greater confidence that it behaves as specified, and
  • different designs can be compared.

It is precisely these benefits that we seek. However, a necessary precursor to development of formal functional characterization of shop floor control is the definition of terms, and the description of the structure of the control system to which these techniques will be applied. Laying this foundation is the topic of this paper.

3.Architecture

The architecture described in this paper follows the hierarchical model. Although the heterarchical model has some intuitively appealing characteristics, the predictability system behavior is questionable and more research and experimentation is required in order to prove its stability and benefit. The architecture for a hierarchical system must describe the decomposition of the system into individual subsystems and provide functional decompositions of these subsystems. The architecture should also provide the guidelines necessary to develop these subsystems so that they can be transparently integrated into the larger system. The primary goal of a hierarchal structure is to develop systems whose subsystems are completely independent so that individual components can be developed at different locations (e.g. by different vendors) and can be replaced or updated as necessary without adversely affecting the rest of the system.

Among existing hierarchical architectures there is much debate over the required number of distinct levels. We identify three “natural” levels (which are generalized from Joshi et al. (1990) and Jones and Saleh (1990)): From the bottom of the hierarchy to the top (as shown in Figure 2) are the equipment, workstation, and shop levels. The equipment level is defined by the physical shop floor equipment and there is a one-to-one correspondence between equipment level controllers and shop floor machines. The workstation level is defined by the layout of the equipment. Processing and storage machines that share the services of material handling machine together form workstations. Finally, the shop level acts as a centralized control and interface point for the system. The primary responsibility of the shop controller is to provide the centralized access to the shared resources in system.

These descriptions of each level are virtually identical to those descriptions provided by Jones and McLean, 1986; Jones and Saleh, 1990; Joshi et al., 1990; Simpson et al. 1982; and others. However, while these qualitative descriptions of each level provide a conceptual view of the hierarchical decomposition, they do not provide the specific details required to formalize the control software requirements for control systems based on these architectures. In order to facilitate software generation (automatic generation, in particular), more detailed descriptions of the decomposition and of the individual levels are required. Providing these detailed descriptions is the primary objective of this paper. After a describing a set of preliminary definitions, each level in the control hierarchy will be formally defined.

3.1Preliminary Definitions

A part is an individual item that is to be produced by the manufacturing system. While a part is logically an individual item, it may actually be an assembly or fabrication composed of other parts. In the production system, each part will have several administrative attributes. Some of these include the part type, part number, due date, customer number, etc. A part will also have a set of technical attributes which describe the part and define the required manufacturing operations. These technical attributes are used to create a process plan for the part. A process plan provides the processing instructions necessary to produce the part. The representation of a process plan used in this research is a directed graph that shows the precedence constraints and alternative routings for the part as paths through the graph (see Figure 3). Each node in the graph represents a specific operation or set of operations performed by a machine or group of machines. Each arc represents the movement of the part from the machine represented by the tail node to the machine represented by the head node. Any path through the graph represents a feasible processing route for the part. Therefore, by assigning processing costs to each node and transport costs to each arc, the total cost for each routing alternative can be determined. The graph can be also hierarchically constructed to show various levels of detail. These levels map directly to the control levels in the proposed architecture. This representation is a simplified view of those described by Mettala (1989) and Catron and Ray (1991).

We also introduce the concept of a part group. A part group is a group of parts which is handled as a single entity. For example, several parts can be attached to a multi-part fixture for transport and/or processing. In this context, the parts and the fixture together constitute a part group. Part groups correspond to the smallest units which are assigned to a controller’s subordinates. For example, consider the case where a pallet of parts is removed from a storage device, placed on an AGV, and delivered to a workstation for processing. Once at the workstation, the individual parts are removed from the pallet, processed by the machines in the workstation, and placed back on the pallet. From the storage system and AGV points of view, the parts and the pallet together constitute a part group since the parts are not separated from the pallet. However, from the workstation point of view, they do not constitute a part group since the parts are removed from the pallet and processed individually. Assemblies are special cases of part groups which are not separated (unless rework is required). An important property illustrated by the assembly and disassembly cases, is that part groups can be dynamically created and destroyed by different controllers. In its simplest form, a part group is one or more items being processed, handled, or transported as a unit.