Database model for hierarchical control of manufacturing cell systems in a manufacturing shop

Database model for hierarchical control of manufacturing cell

systems in a manufacturing shop

LI LIN and YI-JEN FANG

Abstract: To access a large amount of static and dynamic data sets in achieving flexible manufacturing system (FMS) control functions, a corresponding database structure must be designed to effectively support the control. Within the context of a hierarchical manufacturing control architecture, this paper discusses the development of a semantic database structure for the control needs of manufacturing cell systems in a shop. A conceptual data model is first de veloped using entity-relationship diagrams (ERD), and the database is then implemented from a relational data model by a database management system. An application program is used to illustrate the production control command decomposition in a manufacturing shop that consists of several manufacturing cells. Feedback of control commands execution is also discussed. It is shown that the data flows in the hierarchical manufacturing control can be effectively supported by the developed databases and query interface.

Keywords: manufacturing cell systems, database model, hierarchical control

M odern manufacturing systems are complex organizations which consist of several functional subsystems such as processing,

tooling, inventory, material handling and shop support- ing, each performing different tasks to achieve the overall production goal. Since many manufacturing tasks demand an overwhelming volume of data processing and communication, the effectiveness of production control directly depends on the quality of information flow in the manufacturing system ~'2

To ensure efficiency and flexibility, the control architecture of flexible manufacturing systems (FMS) is becoming vitally important. Recent research advocates a manufacturing control hierarchy. The Automated Manufacturing Research Facility (AMRF) at the National Institute of Standards and Technology (NIST) consists of five control levels: factory, shop, cell,

Department of Industrial Engineering, State University of New York at Buffalo, Buffalo, NY, USA

0951-5240/93/030185-10 (~ 1993

workstation and equipment 3-5. Within this hierarchical architecture, the control of manufacturing processes is highly distributed. Control commands are passed down the hierarchy and sensory requests are issued to the lower levels. Execution status feedback are sent to the higher control levels for generating further control commands. For various control purposes, specific information is required at different times and at different levels 6"7.

Special attention has been given to shop and manufacturing cells, since they are two of the most important levels of shopfloor control. Solberg and Helm s discussed hierarchical decomposition in coordinating activities through a hierarchical control structure. It can be recursively applied at different control levels. In an example of shop-cell two-level control, the shop controller sends control commands to cell controllers and transport requests to an Automated Guided Vehicle System (AGVS) dispatcher. Status interface from cells and the AGV system provide the execution feedback needed for generating further control commands and transport requests.

Applications of database management systems for information storage and retrieval in manufacturing have been reported by several authors 9 Jr. As various types of data are involved in the manufacturing system, efforts have to be made to capture the correct relationships between the data objects to ensure a high degree of data integrity. A database structure is then developed to satisfy the control requirements of the target manufacturing system.

The operational control of an FMS involves accessing large static and dynamic data sets ~2. When FMS control is implemented in a hierarchical architecture, it is desirable and necessary to share certain classes of data across one or more levels 4. The hierarchical control structure provides a mechanism for partitioning the databases needed to meet manufacturing requirements. The databases should be organized correspondingly in a hierarchy with different levels of details to satisfy the

Butterworth-Heinemann Ltd

Vol 6 No 3 August 1993 185

Database model for hierarchical control of manufacturing cell systems

control needs 7. The database structure consists of two major components: a static database and a dynamic database. The static database is mainly for part data, which contrains engineering and production data for the parts to be manufactured. When organized in a hierarchy, the static database contains requirements for cell processing at the shop level, and workstation requirements at the cell level. The dynamic database, on the other hand, represents system status. At the cell level, it has workstation locations of the job orders being processed and their progress, while at the shop level it has information about the job orders for the subordinate cells. The two databases jointly provide the required information for performing production activities in a closed-loop control.

As production tasks are performed down the hierarchy, a large amount of information moves vertically in the hierarchy 13. However, the transfer of control from one control module to another must be simple and without voluminous data exchange to ensure a quick system response. To solve this problem, the logical database structure must be distributed according to the needs of particular control modules ~4. Each subsystem should be able to retrieve and modify data through its local logical view processor, while the data integrity of the entire system is maintained through a properly designed database structure in the hierarchy.

To coordinate many concurrent activities within a real-time production environment, on-line update of dynamic state information is essential for making correct real-time control decisions. For instance, the information at the manufacturing cell level includes the state of each part that is in process, the number of operations that have been successfully completed, and the current location of the parts, etc. The local database that contains this information is integrated with the system's main database where long-term information is maintained 12.

In this research, a database structure for hierarchical manufacturing control is developed for cell system control in a shop using conceptual and logical database design techniques. As an information system, it supports the functional needs within the hierarchical manufacturing control architecture. We shall demontrate the use of semantic relations with control task decomposition in the manufacturing control hierarchy by imple- menting the database with a query interface. We also show that the feedback of cell system status to the shop control level through the use of this database structure and developed query interface.

Data models in manufacturing control

The ability to manage information is an important ingredient in any effort to coordinate the control activities in a complex organization 4. An information model facilitates the understanding of structure of information required by a given system.

Chen 15 described the entity-relationship (ER) model

in database systems design as a unified view of data. Entities in this model include both physical and non- physical objects (e.g. parts and production order), and their relationships are captured by entity-relationship diagrams (ERD). ERDs provide a conceptual data model that represent the user's view of the data. It can then be translated into relational data models that can be implemented in a database management system (DBMS) 16.

Similar to ERD, the IDEF1 methodology is used to construct an information model that helps understand the information structure needed to support the functions of a system ~7. The development process involves five phases: data collection, identifying entity classes, identifying relationships between entities, identifying members of the same entity class, and defining non-key attributes. The fundamental concept of IDEF~ is to build an integrated information model first, then design a database from the information model, and finally, to implement the database.

Moyne et al.lS applied the entity-relationship modelling technique to model the information structure for process flow control. Process information flows at various control levels of implementation are considered to be different views of the overall database. The process information flow moves in a hierarchical manner, and the commands from the higher levels to the lower levels are considered as recipes. ER model clustering and schema integration techniques were used to develop the global database schema.

Hsu and Rattner ~ developed a two-stage entity- relationship (TSER) approach for global data and knowledge modelling. The TSER approach represents the heterogeneous requirements in a manufacturing facility by semantic functional models. It uses an operational data structure to model the overall data resource schema.

The TSER methodology identifies the entity and relationship constructs by virtue of functional depend- encies among the constituent data items. Normalization of data structure is embedded in the modelling process rather than performed afterwards.

In an FMS, production data are normally represented by customer orders, which are transformed into production commands through material requirement planning and scheduling functions. Engineering data of the products or parts, such as process plans, numerical control (NC) and robot programming instructions, however, are not contained in these production orders. Execution of the production commands therefore requires access to the corresponding engineering and process data.

To satisfy these control needs, several database systems have been developed. Arington et al. 19 used database systems and a corresponding query interface to support manufacturing process control. Drolet and Moodie 2° used an intelligent state table that contains system states of a manufacturing cell system. Control commands are generated by database queries to the state table. Freedman et al. 21 also used state table and a

186 Computer Integrated Manufacturing Systems

relational database system for the runtime control of robotic workcells.

Chung and McClosky 22 developed a relational query language interface to a hierarchical database management system using Structured Query Language (SQL). Although the databases are distributed, the interface provides the users with a location-transparent access to diversify the databases in engineering and manufacturing environments.

Due to the vital importance of data integrity in FMS control, Engelke 6 stressed that the topology of the FMS database should be optimized to support factory applications that use the database. In particular, C A D / C A M functions in a manufacturing company requires accessing data of parts, bill of material , process information, etc., while material requirement planning (MRP) and production planning functions use input from customer orders and interact with an inventory database. Inte- gration of the two areas is accomplished by passing data such as process plans, NC programs, and robot programs. This provides a good guideline to the design of database structures and the corresponding interface to integrate them.

In a conceptual FMS data f ramework proposed by Wedekind and Zoerntlein 13, the database structure was also based on a relational model. The authors stressed that the transfer of control between different control

LI LIN AND YI-JEN FANG

layers (levels) must be simple and without a large amount of data exchange. It should be accomplished by distributing data relations in the hierarchy and by providing a location-transparent query interface.

In the aforement ioned A M R F at the National Institute of Standard and Technology (NIST), databases are also an important component to support the five-level hierarchical manufacturing control architecture 7. A static part database provides the engineering data needed to execute the production control commands that are sent down the hierarchy, and a dynamic status database supports the execution feedback to be incorporated in the control.

Database design

Within the architecture of hierarchical manufacturing control, this research will focus on the design of database structures that facilitate FMS control functions at both shop and cell levels.

The first step is to define all the important entities for the system. Table 1 is a data dictionary that defines the entities involved in the FMS control system being modelled.

Next, an entity-relationship diagram (ERD) is developed in Figure 1 as a conceptual model for the database system. The entities and their relationships in

Table 1. Data dictionary

Production Order

Shop Controller

Cell Controller

Process Plan

Part

NC machine

Robot

Input/output Buffer

NC program

Tool

Machining Operation

Part Family

Gripping Procedure

A production order refers to one part type only, which contains the following information: production order identification, identification of the part, required quantity, and due date.

The shop controller issues production orders as commands to the cell controller. It inquires the production order progress and cell status information from the database.

The cell controller obtains the production and engineering data for a specific production order, and manages the production activities within the manufacturing cell. The cell controller determines the part routing in the cell, sends commands to NC machines, and dictates the robot to move the part. It monitors the production order progress and the status information of each component system namely, machines, robot, buffers, within the cell.

A process plan contains the process steps and the sequence of the process steps. In each process step, the following information is kept: machine ID, NC program ID, tool ID, set up time, production time per piece, etc. A process plan refers to one part only.

A part is the physical object which is fabricated in the manufacturing system. A part belongs to one part family, and has a process plan. A part may be scheduled into one or more production orders.

An NC machine is the device which executes the NC programs to manufacture the part in the cell. Different set-up operations are required for different parts on the NC machine.

The robot is the only means to transport the part within the cell. The robot executes its programs to fulfill gripping procedures.

The input/output buffer is the temporary areas to store the part. The capacity of the buffer is assumed unlimited

The NC program is the instruction for manufacturing parts on the NC machine. A NC program consists of one or more machining operations written in computer codes.

Tool is the device which directly cuts the part during machining operations. A tool has its lifetime. The machining operation is the step for fabricating the part. A machining operation may need a tool to cut the part

A part family consists of one or more part types according to their similar geometry shape or their machining operation sequences. A part family refers to one type of manufacturing cell. The gripping procedure is the instruction for robot to grip and move the part. It depends on the part type and the location of part in the cell.



the diagram should be read top-down if a relation is labelled on a vertical line, e.g. 'Part Has Process Plan', and from left-to-right if a relation is on a horizontal line. Furthermore, a dot attached to an entity represents a 'many' relation. Without the dot, it is an 'one' relation. For instance, the relation between process plan and operation is 'one-to-many', since one process plan consists of several operations (machining steps to make the part).

Major relations include the following:

1. Production Order Contains Part A production order contains only one part type, and a part can be made in different production orders. Therefore this is an 'Many-to-one' relation.

2. Part Family Has Part A part belongs to one and only one part family, and a part family contains several different part types.

3. Cell Processes Part Family A part family can be processed at only one GT cell, and a cell may process more than one part family. This match-up is important at the shop level for selecting the correct cell for processing a particular order that contains only one part type.

4. Part Has Process Plan A part has one and only one process plan. Different part types cannot have the same process plan.

5. Process Plan Consists of Machine Performing NC Programs

P( Fc

I ;eli I I Prod [Ord~

>Processes

Consists r ly

Has

Macl ine ~ Proc Ster

Uses ©

ztion ]

~Contains

i Part ] Has

Has

Process Plan [

~ Consists of

Processing L Contains j [ Step r ~ Operation

I Consists Uses >of Uses

I NC L Program[" J Tool J T

> Has

t.°,i I ~]:Oer J I Execul

.~ .J Gripping -LP r°cedure ]

Figure 1. Entity-relationship diagram of cell system

A process plan consists of one or more machines to execute NC programs. Machines and NC programs in the relationship are formed in a sequential order, which represents the routing for a part in the cell.

6. Process Plan Consists of Operation A process plan is formed by several machining operations in a specified sequence. These operations describe the machining steps for a specific part. An operation may be found in different process plans.

7. NC Program Contains Operation An NC program contains one or more operations. An operation may be found in different NC programs.

8. Operation Uses Tool When a machining operation uses tools, it uses one and only one tool. A tool may be used in different machining operations, but an operation may not need a tool, such as inspection.

9. Robot Executes Gripping Procedure A robot can execute one to many gripping procedures in a cell, depending on the part and its machining stage in the process plan.

10. Part Has Gripping Procedure A part has different gripping procedures for the robot to move it from one location to another, depending on the machining stage. A gripping procedure may be shared by different part types.

Next, the relational data model is transformed from the ERD. The transformations are derived by analysing the dependency between entities in the relationships. Detailed definition of the entities with their attributes as candidate relations are given in Table 2.

Candidate relations are further normalized during functional dependency analysis. For instance, candidate relation P_Plan is a relation that needs to be normalized. It has the following semantic data format:

P_Plan(Plan_id, Sequence, Operation_id, Standard_time, Tool, NC_prog_id, Mach_id)

The primary key in the relation is the combination of Plan_id and Sequence, because it determines the unique operation step in a process plan. This relation satisfies the requirement in the first normal form, since every attribute value in this relation is atomic. By analysing the functional dependency between the attributes in this relation, the non-key attributes are fully dependent on the primary key. Therefore, the relation is also in the second normal form. The functional dependency in this relation is represented as follows:

Plan_id, Sequence --> Operation_id, Standard_time, Tool, NC_prog_id, Mach_id

The non-key attributes are not mutually independent because Standard_time and Tool can also be deter-


Table 2. Entities and attributes

Entity Attribute

Production Order (El) Part (E2) Part Family (E3) Cell (E4)

Process Plan (E5) Processing Step (E6) NC Program (E7)

Machine (E8) Operation (E9)

Tool (El())

1/O Buffer (Ell) Robot (El2) Gripping

Procedure (El3)

Order#, Part#, Quantity, Due_Date, Start_Date, Comp Date, Status Part#, Part_Name, GT_Code Part_Family#, Family_Name, # of part type Cell#, Cell_Name, # of Machine, Status Plan#, Part#, Planner, Description

Plan#, Step#

NC_prog#, Program_Name, Program_execution_time Machine#, Machine_Name, Status Operation#, Std__time, Tool#, Cut_Time, Description Tool# Tool_Name, Tool_life, #_in_Storage Buffer#, Buffer _Name Robot#, Robot_Name, Speed, Status Gripping#, Part#, From_Pos, To_Pos, Moving~Timc

mined by Operation_id in this relation. This transitive dependency indicates that the relation is not in the third normal form. To normalize this relation, it can be reduced into two relations, R1 and R2. The functional dependency in these two relations are as follows:

(a) Relation RI: Plan_id, Sequence --~ Operation_id, NC_prog_id, Mach_id

(b) Relation R2: Plan_id, Sequence --) Standard_time, Tool

Both relations are now in third normal form. The relation P_Plan can be represented in the form of RI, and relation R2 can be combined into the candidate relation Operation.

Database implementation and query interface

The normalized relations are embedded in the database management system (DBMS). The control modules in the hierarchical control system access their data sets via the DBMS by using the SQL interface. Since the control functions are distributed and limited at their own control levels, SQL query operation development at each control is simplified.

The query operation can be performed on a single table or on multiple tables. The distinction is based on the data structures of the tables, and the information to be retrieved.

Li LIN AND YI-JEN FANG

The single-table query operation is developed if the information needed can be obtained from just one data table. For example, if the production orders with the same due_date are to be found, the query operation can be performed only on the Order table by specifying the value of the Due_date. A sample SQL construct is:

SELECT Order_id FROMz Order WHERE Order.Due_Date = Due_Date (specified by

the user)

The production order information is maintained in the shop level. Developed from the previous database design, the production order has the following data structure:

Order (Order_id, Part_id, Part_name, Quantity, Due_date)

When the cell is ready to process production orders that have been issued by the shop, it cannot get the production and engineering data from the Order structure alone. However, the Part and P_Plan data structures shown below can provide the needed links from Order to Process_Plan:

Part (Part_id, Part_name, Plan_id, Family_id, Drawing_no, GT_code, Weight) P_Plan (Plan_id, Sequence, NC_prog_id, Mach_id)

The information in the process plan for a particular order can be derived from these data structures and their links by specifying the Order_id in the SQL query operations. The SQL query construct for this information retrieval is thus a multi-table operation:

SELECT Plan_id FROM Order, Part, P_Plan WHERE Order.Order_id = Order_id AND

Order.Part_id = Part.ParLid AND Part.Plan_id = P_Plan.Plan_id

Note that the Boolean operator AND requires that all conditions be met in this query.

The single-table and multi-table SQL constructs above show the two basic types of query operations in the relational DBMS. Further query operations are developed in the succeeding example program, which represents the use of the proposed database structure in the hierarchical manufacturing control environment.

Illustrative example

Programming implementation

An application example is developed in PARADOX 3.5 DBMS 23. This example program demonstrates the use of query operations to retrieve the data in a hierarchical manufacturing control system.



The database tables implemented in PARADOX have the structures as previously discussed, and the contents of the tables are further defined in PARADOX. In the example program, the user is asked to follow the instructions on the screen to retrieve the information at different control levels in performing a production task decomposition. Control flow charts for the example program at the shop and the cell levels are shown in Figures 2 and 3, respectively.

Manufacturing cell system

The application is for a manufacturing shop that has three robotic cells each dedicated to making a family of parts. The product line in this shop contains viscous torsional vibration dampers to be used to absorb vibrations in inner-combustion engines, such as those used for powering stock race cars, commercial trucks and ocean-bound sea vessels. A vibration damper is composed of a housing (with an inner ring), a cover, an inertia mass, and high-viscosity silicon fluid inside the housing. With the damper mounted on the fly wheel of an engine, the torsional vibration from the intermittent and successive impacts of the pistons can be absorbed by the shearing force between the high-visosity silicon fluid and the free-floating inertia mass enclosed in the housing.

Cell Control

I Mel~l IlCon EXIT ~ II Mer

Status I Feedback I_/i'h-Y6~_/T~3-7-7_ I QUERY I _ ~ ~-~ I-"/E~-~F"/~.---;~;7~.~/-"l~Order I-"/ Iprn/c~i"na , ' . . . . . ' [ Update Statusl / Re.,

~ l P r o c e s s i n c j I | ~1~i"~1 -Io-o"~-Tr~l -IlZnfo. II ~

I ...... , , . . . . . . , IlMenu I / I" m ~

I Exit I Processing

Info.

I Ouer P r-'oc-e-ss Q-u Plan ,ult /

J ~ L Yes ,/~ r~ -II : c

I (] ipping [o.

Quer 1 I Grippir I Proced e

/ Result

I I Operation

Info. INPUT ~ee - - Op~

/Machine ~ = ~ IMac

OU IRes

I Mac

/ Que It / / Resl

ToolingJ Exit Znfo. t I /INPUT /

~n ~*~-[ Ma chin-~e -#'/ fine I

~ EXIT S h n ° P ° l @

New Or /,NPUT / _ I N--'~-~w Or der/---~-i Data / [ Update

Status Feedback

E'xit

Order List

QUERY Insert Order pdate Status

m :ted IProc~

Q"- I Processing I

ssing rWaiti .~

W"~Ou ~g AI--]~ IQuery I Ord(Irs I ~ Res:~t /

5

J Updc I Orde

/OUTF i/ Repo

Figure 2. Logic flow of database system queries (shop level)

Figure 3. Logic flow of database system queries (cell level)

All the process plans for the parts are developed and stored in the database. For instance, the housing is fabricated of sheet metal in a spinning cell, which consists of a sheet metal spinning machine that performs a cold forming to convert sheet metal pans to damper housings, an NC lathe that cuts the necessary fringe and deburs the edge, an NC drilling machine that drills several holes for mounting the damper to the fly wheel. After machining, the housing is dynamically balanced on a balancing machine.

Production control command decomposition

We now demonstrate how a hierarchical decomposition is achieved using the database structure and the query interface. As discussed earlier, production commands represented by production orders need be decomposed at each level in the control hierarchy, and the required engineering data and process parameters need be retrieved from the part database. We have developed a prototype program to illustrate this process. Figure 4 shows the program's shop control data retrieval menu, order selection menu and a list of all production orders as a query result. Note that as we pointed out, there is no information about which cell is required for which order in this list.


Hierarchical Manufacturing Control Database System

Shop Control Menu

I. New Orders (Entering New Order Data)

2. Order List (Waiting, Processing, Completed Orders)

3. Feedback Information (Status Feedback from Cells)

4. Exit (Return to Mein Menu)

Hierarchical Manufacturing Control Database System

Order List Menu

i. All (Display all production orders in the Database)

2. Waiting (Display Waiting Orders in the Database)

3. Processing (Display Processing Orders in the Database)

4. Completed (Display Completed Orders in the Database)

5. Exit (Return to Shop Control Menu)

Production Order List (All)

Order# Part# Part Name QTY Due Date Status Ceil

017 IIS005 S" housing 200 8/07/82 pROCeSSING 013 023 IM005 5" inertia mass 150 8/07/92 %GLITIWG 035 025 HS006 6" housing 200 8/07/92 I~ITING 013 035 IM006 6" inertia mass 175 8/07/92 WAITING 035 058 IM009 9" inertia mass I00 8/07/92 ~kITING 835 087 HS010A I0" housing 145 8/07/92 ~KITING 013 082 HS010B i0" housing 200 8/07/92 WAITZNG 013 128 HS005 5" housing 150 8/07/92 WAITING 013 167 IM005 5" inertia mass 150 8/07/82 WAITING 035 189 HS006 6" housing 200 8/07/92 WAITING 013 246 HS009 9" housing I00 8/07/92 WAITING 013 280 RS018 18" housing i00 8/07/92 WAITING 013

Figure 4. Production order retrieval at the shop level). (a) shopcontrol data retrieval menu," (b) order list menu; (cl list of production orders

L1 LIN AND YI-JEN FANG

Hierarchical ~u~/facturing Control Database System

Cell Control Menu

I. Processing Information (Production Comm~%nd from Shop)

2. Feedback Information (Status Feedback from Machine)

3. Exit (Return to Main Mlknu)

Please enter a choice and press <Enter>:

Please move the cursor to select the cell Press <F2> to continua, or <Esc> to cancel

Cell Id Cell Name

013 Cell HS 035 CelI--IM 043 CelI--CVR

RETRIEVING PROCESSING DATA FOR THE ORDER Mov~ the cursor and press <F2> to select the order.

Hierarchical Manufacturing Control Database

Production Order List (Waiting)

Cell#: 013 Cell Name: Cell HS

Order# Part# Part_Name Quantity Due Date Start Date

025 HS006 6" housing 200 8/07/92 8/06/92 087 HS010A I0" housing 145 8/07/92 8/06/92 092 HS010B i0" housing 200 8/07/92 8/06/92 128 HS005 5" housing 150 8/07/92 8/06/92 189 HS006 6" housing 200 8/07/92 8/06/92 246 HS009 9" housing i00 8/07/92 8/06/92 280 HS018 18" housing I00 8/07/92 8/06/92 311 HS005 5" housing i00 8/07/92 8/06/92

Figure 5. Information retrieval at the cell level. (a) Cell control data retrieval menu; (b) cell selection," (c) production orders for selected cell

Since cell system control is our focus in this paper, we focus our discussion on the database functions at the cell level.

1. Selecting a cell The data retrieval program starts by asking the user to select a cell from a list of cells on the screen. The purpose is to find all the production orders that are to be processed by the selected cell. Figure 5 shows the screens for selecting a cell. In this example, of the three ceils in the shop, the housing spinning cell (CELL_HS, Cell_id 013) is of interest. It can be seen that all housing orders are selected.

Next, we will show how a production order is decomposed down the control hierarch.

2. Selecting the production order The result of the previous operation is a list of production orders for the selected cell. As shown in Figure 5c, the database structure of the production order is:

Order (Order_id, Par'Lid, Quantity, Due_Date)

The cell database only has the structure:

Cell (Cell_id, No_of_Mach, Mach2_id . . . . )

Machl_id,

Since there is no direct information link between these two data structures, a multi-table query operation is developed to retrieve the production orders that the selected housing cell is responsible to process:

SELECT Order_id, Part-id, Quantity, Due_data FROM Order, Part, P_Family, Cell WHERE Order.Part_id = Part.Part_id AND

Part.Pf_id = P_Family.Pf_id AND P_Family.Cell_id = CelI.Cell_id (user

selection)

The task is further decomposed to obtain the engineering data in the part's process plan. Since the data structure of the production order does not contain this information, a link is provided by the attribute Part_id in the order data structure provides to the part's data structure. In addition, the attribute Plan_id in the part's structure supplies a further link to the part's process plan. The information on the process plan is retrieved via these links among the data structures. The SQL construct on this query is as follows:

SELECT Sequence, Mach_id, NC_Prog_id, FROM Order, Part, P_Plan WHERE Order.Order_id = Order_id (user selection)

AND Order.Part_id = Part.ParLid AND Part.Plan_id = Plan.Plan_id



The result is the process plan listed in Figure 5b.

3. Retrieval of process plans and robot gripping procedures The results of the query operation on selecting the production order are the routing information and the robot gripping procedures for the selected order in the specified cell. These are shown in Figure 6.

4. Retrieval of machine operation and tooling information The detailed information of machining operations on each machine is obtained by another query operation. Therefore, the program then asks the user to select a machine from the routing information. Since the operations are contained in an NC program used by a machine to process a part, further information retrieval is made by a query on the data structure of NC program and machine operations. An example of the SQL construct is as follows:

SELECT Op_id, Tool_id, Std_time, Cutting_time FROM NC_Prog, Operation WHERE NC_Prog.NC_id -- Nc_id (from user

selection) AND NC_Prog.Op_id = Operation.Op_id

Hierarchical Mlu~ufacturing Control Database System

Processing Information Menu

i. Process Planning Info. (Data related to Process Plan}

2. Gripping info. (Robot Gripping Procedure of Parts)

3. Exit (Return to Cell Control Menu}

CELL: 013 ORDER: 128

Process Pla~ (Routing i~the Cell}

Order#: 128 Part#: HS005 Cell#: 013 PPlan#: 001 Part_Name: 5" housing CellName: CelI HS

Sequence 0P# NCPROG# Machine# Description

1 11051 II01 101 sheet spinning 5" 2 12051 1201 102 turning O.D. 5" 3 12052 1201 102 tunring I.D. 5" 4 13051 1301 103 drilling 5" 5 14051 1401 104 dynamic balancing 5"

The result of the query is a list of machining operations in an NC program for the user-specified machine. The tool used for each operation is also obtained. Figure 7 shows the results of detailed machine operations. In this case, the lathe (Machine # 102) is selected.

The task can be further decomposed to obtain information on tool, such as tool_life, etc., which is an important piece of information to maintain the tool in the cutting condition. It can be retrieved by executing a query on the tool data structure, as shown in Figure 7d.

The control command decomposition process is summarized in Figure 8, which also shows the interface of the database to the control functions in the system.

Execution feedback composition

One of the often-ignored but very important aspect in manufacturing control is the feedback of control execution status. It is not generally available in the open literature. In this paper we also show that this in- time feedback can be achieved by using the database structure.

After an order has been completed on each machine, a summary report of machining operations is generated

RLierarchical Manufacturing Control Database Systa

Operation / Tooling Xnfo. Menu

I. Operation ~nfo. (Std Time, Tool, Cutting_Time...}

2. Tooling Info. (Tool_Life, Remain_Time...)

3. Exit (Raturn to Processing Znfo. Menu)

Routing in the Cell

Order#: 128 Cell#: 013 Part#; HS005 Cell Name: Cell_aS

Sequence Machine# Machine_Name

1 101 Spin MC 2 102 Lathe 3 103 Drilling M 4 104 Balance M

Machining Operation

Order#: 128 Cell#: 013 Machine#: 102 Part#: ES005 Cell_Name: CslIHS MachineName: Lathe

NC# OP# StdTime Tool# CutTime Description

1201 12051 .58 TR01 .42 external turning 5" housing 1201 12052 1.3 TR02 i.i internal turning 5" housing

I Tooling Information

order#: 128 Cell#: 013 Machine#: 102 l~a r t# : aS005 Ce i l . _Nm: ce i l_aS Machine. ~ m s : Lathe

I Op# Tool# ToolName Tool Life Tool_RemainTime

I 12051 TR01 CUTTER 4000 3426 12052 TR02 CUTTER 3700 2767

Robot Q r i ~ i n g P r o o e c l u r s

Order#: 128 Cell#: 013 Robot#: R01 Part#: mS005 CellName: Cell Bk~ Speed: 50

~# n~x_P0s TO POS ~_~U_T~

ooi Bll 1oi .74 002 I01 102 .79 003 102 103 .89 004 103 104 .57 005 104 B12 .45

Figure 6. Retrieval of process plans. (a) Processing information menu; (b) process plan; (c) robot gripping procedure

Figure 7. Retrieval of operation and tooling information. (a) Operation~tooling information menu; (b) machine selection; (c) machining operation information; (d) tooling information


Production Command From Shop

Order

l Order # Part -~ Quantity DueDate 'Siatus

Plan

i ! : r ~ #"

#

Part Part # Part_Name

GP GP# Part # Robot # Prom Pos To_P~

To Robot Controller

Step

~ ! l i ! P~rrog # ] ~ CT°ntC~rolllle r Machine # I

II°.

Nc_op I , Mc-r°°l I ,0per -~NC Prog#l L---I Machine# L~Op# ;:+ o+

rice | Tool IStd Time [ Roman_ [CutTime

Ti.me

i To Device Controller

Figure 8. Hierarchical decomposition of production commands

from the database, which, as shown in Figure 9a, represents the execution feedback from the machines to the manufacturing cell controller. Listed in the report is all the information about the production order, as well as the time used on each machine.

Similar detailed information of tools is also available from the database. Figure 9b shows such a summary report, which includes the actual cutting time on each cutting tool and the remaining.tool life.

Figure 9c is a general report for the just finished production order. In addition to start and finish times, it also gives the numbers of good and scrapped parts.

After this feedback information is received by the database, the status of the production order just finished will automatically be updated from 'Processing' to 'Complete'. From the shop-level database, a query for all completed production orders will verify this cell- to-shop feedback.

Conclusion

In this paper, a semantic database structure for hierarchical manufacturing control is discussed. The development includes the requirement analysis of the problem under study, design of the conceptual data model, and design of the relational data model that is implemented in a DBMS.

Ll LIN AND YI-JEN FANG

=~ ....

production Order F~ck Statui XnfozlnationReport

Order#: 017 Status: COMPLETED Cell#: 013

part#: HSO05 Due Date: 8/09/92

part Nams: 5" housing Start_Date: 8/06/92

Quantity: 200 CompleteDate: 8/06/92

Machine# Machine_Name Total Time on Machine

i01 Spin MC Ii0 102 Lathe 376 103 Drilling M 246 104 Bal~nce M 90

production Orde= Feedback Status Information Report (Tooling)

Order#: 017 Status: COMPLETED Cell#: 013

part#: ES0O5 Due Date: 8/07/92

Part Name: 5" housing Start Date: 8/06/92

Quantity: 200 CompletQ_Date: 8/06/S2

Machine# Tool# Tool_Name Time on M/C Tool Rem~!nTima

102 TR01 CUTTER 84 3342 102 TR02 CUTTER 220 2547 103 DR01 DRILL 212 3878

Production Order Feedback Information Report

Order#: 017 Status: COMPLETED Processing Cell: 013

Part#: HS005 Total Cell Time: 1510

Quantity: 200 Good Qty: 200

Due Date: 8/07/92 Scrapped Qty: O

Start Date: 8/06/92

Complete Date: 8/06/92

Figure 9. Feedback of production order execution status. (a) Machine operation information summary report; (b) tooling information summary report; (c) cell order processing summary report

An entity-relationship model is first developed in the conceptual database design. Transformation from the ER model to the relational model is presented. The final outcome of the relational model is the normalized relations.

This study uses the query operations in the DBMS to retrieve and update the information pertaining to the hierarchical control needs. The usage of the database structure in the hierarchical control is shown by an example written in PARADOX's Programmer's Application Language (PAL).

The application examples show that the developed database structures, and the query interface can be used to effectively support the needs in the hierarchical manufacturing control. When a control system is implemented, a proper interface can also be developed to integrate the control functions with the database to provide the manufacturing data needed.

Acknowledgements

This research is supported in part by the National Science Foundation, Division of Design and Manu- facturing Systems Grant No. DDM9209452.

Vol 6 N o 3 A u g u s t 1993 193


References 12

1 Hsu, C and Rattner, L 'Information modeling for computerized manufacturing', 1EEE Trans. Syst., Man & Cybern., Vol 20 No 4 (19??) pp 758-776

2 Tiemersma, J J and Kals, H J J 'A real-time monitoring and control system for small batch part manufacturing', Proc. Manuf. Int. Part 3: Int. Aspects of Manuf., Atlanta, GA (March 25-28 1990) pp 41-48

3 Simpson, J A, Hocken, R J and Aibus, J S 'The automated manufacturing research facility of the National Bureau of Standards', J. Man@ Syst., Vol 1 No 1 (1982) pp 17-32

4 Jones, A T and McLean, C R 'A proposed hierarchical control model for automated manufacturing systems', J. Man@ Syst., Vol 5 No 1 (1986) pp 15-25

5 Scogin, D N and Titone, M J 'Automated manufacturing research facility (AMRF) based manufacturing system control software', Proc. Man@ Int. Part 1: Intelligent Manufacturing Structure, Control and Integration, Atlanta, GA (March 25- 28, 1990) pp 39-48

6 Engelke, W D 'Databases in flexible manufacturing systems (Chapter 5)', Handbook of Flexible Manu- facturing Systems, Academic Press, New York (1991)

7 Williams, D J Manufacturing Systems - An Intro- duction to the Technologies, Halsted Press, NY (1988)

8 Solberg, J J and Heim, J A 'Managing information complexity in material flow systems', NATO ASI Series, Vol. F53, Advanced Information Techno- logies for Industrial Material Flow Systems (Nof, S Y and Moodie, C L, eds.), Springer-Verlag, Berlin (1989) pp 3-20

9 Lee, R M 'Database inferencing for decision support', Decision Support Syst., Vol 1 (1985) pp 57-68

10 Vernadat, F 'A conceptual schema for a CIM database', Proc. A UTOFACT 6, Society of Manu- facturing Engineers (1986) pp 11.24-11.41

11 Vickery, A R 'Design for a manufacturing data base for management use', Comput. and Ind. Eng., Vol 7 No 3 (1983) pp 225-240

Maimon, O Z 'Real-time operational control of flexible manufacturing systems', J. Manuf. Syst., Vol 6 No 2 (1987) pp 125-136

13 Wedekind, H and Zoentlein, G 'Conceptual basis for database applications in flexible manufacturing systems', Proc. IEEE Int. Conf. on Robotics and Automation, Raleigh, NC (1987) pp 551-557

14 McLean, C, Mitchell, M and Barkmeyer, E 'A computer architecture for small-batch manufacturing', IEEE Spectrum, Vol 20 No 5 (1983) pp 50-64

15 Chen, P P 'The entity-relationship model - toward a unified view of data', ACM Trans. Database Syst., Vol 1 No 1 (1976) pp 9-36

16 Date, C J Introduction to Database Systems, Vol 1 (5th ed), Addison-Wesley, Wokingham (1990)

17 Bravoco, R R and Yadav, S B 'A methodology to model the information structure of an organization', J. Syst. & Softw., Vol 5 (1985) pp 59-71

18 Moyne, J R, McAfee, L C Jr and Teorey, T J 'An application of entity-relationship data modeling techniques to the automated manufacturing processes', Proc. 2nd Int. Con. on Data and Knowledge Syst. for Manuf. and Eng., IEEE Press, Gaithers- burg, MD (October 16-18, 1989) pp 206-215

19 Arington, M J, Hartley, T T and Railey, M R 'Manufacturing process control through data base/ query process representation', Proc IEEE IECON (1985) pp 52-57

20 Drolet, J and Moodie, C L 'State-table innovation for cell controllers' Comput. and Ind. Eng., Vol 16 No 2 (1989) pp 235-243

21 Freedman, P, Michaud, C, Carayannis, G and Malowany, A 'A database design for the runtime environment of a robotoc workcell', Robotics and Comput.-Integrated Manuf., Vol 5 No 1 (1989) pp 21-31

22 Chung, C W and McCloskey, K E 'A relational query language interface to a hierarchical database management system', Proc. 2nd Int. Conf. on Data and Knowledge Syst. for Manuf. and Eng. IEEE Press, Gaithersburg, MD (October 16-18 1989 pp 105-112

23 P A R A D O X 3.5 User's Manual, Borland Inter- national (1991)


Database model for hierarchical control of manufacturing cell systems in a manufacturing shop

Documents

Transcript of Database model for hierarchical control of manufacturing cell systems in a manufacturing shop