Resource modeling for the integration of the manufacturing enterprise

Journal of Manufacturing Systems

Resource Modeling for the Integration of the Manufacturing Enterprise Jay Steele, PRI Automation, Billerica, Massachusetts, USA Young&n Son, Dept. of Systems and Industrial Engineering, University of Arizona, Tucson, Arizona, USA Richard A. Wysk, Dept. of Industrial and Manufacturing Engineering, Pennsylvania State University, University Park, Pennsylvania, USA. E-mail: [email protected]

Abstract Researchers are beginning to develop taxonomies of dif-

ferent knowledge domains in order to specify the requirements of engineering functions in various manufacturing enterprises. These interrelated functions include product design, process planning, capacity planning, production costing, quality control, acquisition or reconfiguration of resources, planning and scheduling of shop activities, and execution of shop activities. These taxonomies and functions are not typically integrated in today’s manufacturing enterprise. This results in inefficient manual transfer of knowledge between domains and the unavailability of critical information required for decision making. Object-oriented design methodologies are useful for modeling diverse information and behavior. Furthermore, planning, analysis, and control of resources such as machine tools, fixtures, and tooling increasingly dominate the engineering functions. This paper demonstrates how to integrate these functions with an object-oriented resource model that links information from different knowledge domains. These functions are implemented using different software packages that can easily access the common resource data because the data are embedded in the resource class structure. This resource model is based on software objects that have a one-to-one correspondence with physical objects. This resource model is illustrated using object-oriented software, but the model may also be applied to distributed object and agent architectures.

Keywords: Information Technology, Manufacturing Systems, Computer Control

Nomenclature The following is a partial list of the nomenclature

used in this paper:

BS Buffer storage class E Equipment class F Fixtures class FEA Features class I Instructions class MH Material handler equipment class

MP Material processing equipment class MT Material transporter equipment class P Part class R Facility class T Tools class

1. Introduction Currently, the engineering and production func-

tions of the vast majority of manufacturing enterprises are not explicitly integrated. That is, common information required for two or more functions must typically be recreated using a different representation for each function. Thus, most of the enterprises involved with discrete part manufacturing have the following problems:

Much of today’s automated production is driven by programmable logic controllers (PLCs) that control “islands of automation”. The capabilities of the production resources are only implicitly understood by experienced process planners and manufacturing engineers; therefore, product design and process planning are not integrated. The quality control function is only indirectly connected to process planning; therefore, quality problems are only corrected after measurement, instead of directly building quality into production. Resource information for MRP II (manufacturing resource planning) software is typically expressed in terms of workstations, and its planning and scheduling output is not directly trans- latable into machine instructions. Product cost estimation is based on financial reporting rather than managerial control requirements.

407

Journal of Manufacturing Systems Vol. 19/No. 6 2001

l The logic of interaction between machines in discrete event simulations is not directly used to control the plant.

l Reliable process planning for new equipment considered for acquisition is difficult.

These issues are widely recognized as problems in manufacturing. For instance, the grand challenge #1 from the National Science Foundation’s Visionaiy Manufacturing Challenges for 2020’ is to create concurrent engineering capabilities to reduce time to market and accommodate changes in product and production technology. Commercially, effort to solve these integration problems has typically only been successful for point solutions within one company’s family of products. For instance, computer- aided manufacturing software, such as ProEn- gineerTM and MetCAPPTM, typically integrates the product model with limited internal resource models of machines that are not integrated with equipment vendor data.

To provide solutions to these integration problems, it is necessary to define the different domains within manufacturing enterprises and clarify how information should flow between these domains. Then software mechanisms can be developed to integrate the domains. Researchers have developed reference models of activities and data flow between these domains within manufacturing enterprises.23 Governmental agencies are currently proposing standards to facilitate translation between different applications in the enterprise.4*5 These standards can be used for integration between different functions in the enterprise by enabling the translation from one application into another application that integrates with another domain. Researchers have also proposed to use languages based on formal ontologies to precisely define the information in specific knowledge domains within the enterprise.6 For instance, Fadel, Fox, and Gruninger’ developed an ontology for resource scheduling. In another domain, a formal finite-state machine language is used to define elements of shop floor control.8 Formal languages can prevent ambiguous translation between databases with common premises or within a single domain by providing the ability to prove that specific mappings of concepts are logically true. These standards and formal languages that specify the elements and their relations in a given knowledge domain define that domain. Thus, communica-

tion can be established between these different domains by creating software mechanisms that reference and manipulate instances of the elements for- mally established in the different domains. The data required for these various manufacturing domains are stored. Different software packages can then be created that reason about the resources by using the same object-oriented structure with different class behaviors. This architecture facilitates sharing of resource data across the distributed enterprise and the development of software to implement engineering functions.

2. Background Perhaps the most promising paradigm for inte-

grating across different engineering domains, software vendors, and computer platforms is the distributed object architecture. This was demonstrated by the A Framework for Enterprise Integration (PRE) architecture9 and the Simulation Assessment Vali- dation Environment (SAVE) architecturelO that link software packages from different domains without imposing any a priori model of enterprise integration. Furthermore, it has been shown that object-oriented design simplifies the task of modeling complicated information and behaviors. Researchers have also proposed using software agents that use such distributed object architectures along with intention and reasoning to integrate across enterprises.” To facilitate communication between these agents representing different domains, agent communication languages such as Knowledge Query and Manipulation Language (KQML) have been developedI that explicitly define message content by specifying an ontology at the header of messages. Given the task of actually integrating manufacturing enterprises, questions still remain such as what knowledge should be represented by these ontologies and how this knowledge can be used to solve manufacturing problems.

Automated production machines are increasingly being used in modem manufacturing, where the human operator may tend up to four or more machines. Such machinery requires large investments and has highly specialized capabilities relative to manual operations. Thus, many of the manufacturing enterprise’s activities deal with different perspectives of these manufacturing resources. These activities are typically defined by different knowledge domains and

408

Journal of Manufacturing Systems Vol. 19/No. 6

2001

include process planning, production costing, simulation analysis, resource acquisition, scheduling of shop floor activities, shop floor control, and quality control. These interactions between models of resources and the activities of the manufacturing enterprise are illustrated in Figure 1. There have been efforts to model these resources to support the different activities in this diagram. Aguiar, Murgatroyd, and Edwards*3 developed a formal method for specifying resources as constraints in a top-down Open Systems Architecture for Computer Integrated Manufacturing (CIM-OSA) design of manufacturing systems to support the equipment acquisition activity. Pancerella, Hazelton, and Frosti proposed combining process models with equipment models to constrain the design process by

process planning activities. Jurrens, Fowler, and Algeo5 proposed a manufacturing resource model standard for translating between different specifications of machine tool equipment, cutting tools, hold- ers, and so on, to support manufacturing systems integration and activities such as equipment acquisition.

Several ongoing standards efforts under the gov- ernance of the International Organization for Standardization (ISO) are relevant to the resource modeling. Some of them follow:

l ISO/TC (Technical Committee) 29 is a technical committee on small tools. ISO/TC 29/WG (Working Group) 34 works on cutting tool data, and IS0 13399 is a standard of cutting tool data

resource capabilities to support the product design and representation and exchange.15

Product Model

Legend

Data store b Data flow

/

Actor

Figure I Activity Diagram of Enterprise Architecture (Information Flow)

409


l ISO/TC 184 is a technical committee on Industrial Automation Systems and Integration. ISO/TC 184/SC (Sub Committee) 1 is titled physical device control, where ISO/TC 184/SC l/WG 7 is known as the STEP-NC (IS0 14649). STEP-NC is the extension of STEP so that it can be used to define data for NC (Numerical Control) machines. In the past, CNC machine tools had to be programmed using G and M codes (from IS0 6983), without any semantic content that referred to the part being processed. STEP-NC will make G and M codes obsolete.i5

l ISO/TC 184&C 4 is titled Industrial Data. Relevant standards from this subcommittee include (1) Industrial Manufacturing Management Data (MANDATE project, IS0 1553 l), (2) Process Specification Language (PSL, IS01 8629), (3) Parts Library (IS0 13584), (4) Standard for the Exchange of Product Model Data (STEP, IS0 10303), (5) Integration of Industrial Data for Exchange, Access, and Sharing (IIDEAS, IS0 18876), and so on.lsl’

l ISO/TC 39 is a technical committee on machine tools, where ISO/TC 39/SC 2 is titled test con- ditions for metal cutting machine tools and ISO/TC 39/SC 8 is titled working holding spin- dles and chucks.15

This paper develops an object-oriented architecture that is based on classes of manufacturing resources that were developed by Wysk, Peters, and Smith’* for process planning. In addition to extend- ing these classes, this architecture incorporates other knowledge domains within the enterprise by defining attributes and behaviors of the resource model classes that are based on elements from these domains. The 1553 1-3x series, currently being developed by International Organization for Stan- dardization (ISO) for manufacturing resources management data, propose establishing a standard for describing resources, the way of using and main- taining them, their capacity and capability, and an information model to trigger, estimate, and monitor them. Our architecture demonstrates how general classes of these resources and their behaviors might be modeled. Elements are incorporated from other domains that are well defined by STEP, PSL: for- mally established ontologies, other mathematically valid languages, or by common practice. Then, software can be developed to assist with many of the

activities in Figure I that connect different parts of the enterprise. Such software allows engineers to simulate, control, reconfigure, and purchase resources in a “plug and play” fashion. This satisfies the information requirements for the proposed solutions to the concurrent engineering challenge from Visionary Manufacturing Challenges for 2020,’ which include systems modeling capability, modular equipment, and “plug and play” hardware and software. This architecture provides a structure for modeling the data and behaviors from different knowledge domains based on critical resource objects that have a one-to-one correspondence with the physical objects in the real world. Furthermore, grounding the enterprise integration architecture firmly in manufacturing resource objects provides a sorely needed emphasis on the means of industrial production, which is sometimes lacking in today’s manufacturing enterprises.19

For example, the activity of process planning in Figure I takes a product specification and a model of the resources and generates a process plan. A human process planner begins this activity by mapping production requirements for the product to abstract manufacturing processes. Next, the process planner matches these abstract processes to the capabilities of specific resources in the plant or that are available for purchase. Note that three different domains are connected by this activity: product model, abstract manufacturing processes, and resource description. There have been efforts to map features in the product model to abstract manufacturing processes to determine the manufacturability of the product.*’ However, these efforts have not connected these abstract manufacturing processes to actual equipment classes. Our software architecture links these different domains by embedding abstract processes in the behaviors of high-level resource classes. Furthermore, specific capabilities are embedded as procedural constraints to satisfy product requirements in lower-level classes that directly correspond to specific manufacturing resources. The rest of this paper illustrates how this approach enables the development of tools, in the form of software applications, to link enterprise domains with process planning, production cost analysis, acquisition of resources, planning and scheduling of shop activities, creation of the shop floor execution system, and the maintenance of the resource model. The resource model was tested using the following procedures:

410

l Designed the attributes and methods for classes of an object-oriented resource model.

l Stored the resource information in an appropriate database whose structure reflects the resource model.

l Developed object-oriented software applications that utilize instances of resource objects from the database information.

. Added class methods to software to automate engineering functions that link different domains of the enterprise.

l Tested software applications using a resource model database for a realistic manufacturing environment.

3. Resource Model Framework To integrate the different functions and domains of

the manufacturing enterprise, the general resource model is defined in terms of a set of standard object- oriented classes with the properties of inheritance, ownership, data hiding, automatic class initialization, and polymorphism as described by Booth.” These manufacturing resource classes enable the easy transfer of information between different knowledge domains of the enterprise and the resource model as long as the information that these classes and their attributes represent is unambiguous. For example, one attribute of a drill press (or any other machine resource class) is its current status as determined by the shop floor execution system. The production scheduler that uses this status to determine the schedule must make decisions based on the same interpretation of the current status-that is, the machine could be idle, busy, or broken. Other examples of engineering activities con- tained within resource classes include reasoning about the cost of usage of a resource by the production planning function and calculating the process capability of a resource for the quality control activity. It is impor- tant to note that part of the attributes and behaviors for a given resource object is solely dependent on the resource as delivered from the vendor. These include equipment classification, kinematic specifications, initial estimates of process capability, and initial cost. Other information depends on the installation of the resource in the shop, such as layout of the machine, available tooling, and cost of usage.

Wysk, Peters, and Smith’* classify the assets of manufacturing systems using symbolic definitions from set theory. According to this classification,


2001

manufacturing assets include members of the equipment set (E), tool set (T), fixture set (F), and instruction set (I), which belong to the general set R = E u T u F u I. These assets are grouped according to an object-oriented and hierarchical shop floor model. According to Smith,8 these assets may be grouped hierarchically using the following concepts: shop, workstation, and equipment. Thus, in an object-oriented classification, manufacturing resource classes include a facility class R that may own instances of the workstation class W. Each workstation class may own instances of the manufacturing equipment class E, tool class T, fixture class F, and instruction class I. Objects in these classes that cannot be grouped in a workstation are directly owned by the facility object. Subclasses of class E include material processor (MP) class, material handler (MH) class, material transporter (MT) class, and buffer storage (BS) class. These classes and their subclasses contain attributes designed to facilitate the activities illustrated in Figure I. Thus, there are attributes such as short- and long-term status, process capabilities related to part feature types, cost of usage, information to compute process time, and location in the facility. These classes and some of their attributes are illustrated by Figure 2. In Figure 2, using the Unified Modeling Language (UML) symbology defined by Eriksson and Pen- ker,22 class ownership is denoted by the “owns” association, while a superclass and its subclass have an inheritance relationship.

The material processors are the equipment that add value to a product either by transforming its state closer to the desired final physical state or by certifying that features of the product match specification through inspection. Material removal machines (machine tools), assembly machines, welding robots, electronic integrated chip placement machines, and coordinate measurement machines represent instances of this class. Different types of material processes are classified into subclasses of the MP class. For instance, milling machines represent one of these subclasses, while turning centers represent another subclass.

The material handlers are equipment that load/unload products to/from equipment for processing, storage, or transportation, while material transporters move products between stations. Typically, material handlers have the kinematic flexibility to change the orientation and position of the part to

411


Mate -OlX!

ma “7’

? inhhritc ‘7”

inh tits ?

inhgrits

Figure 2 Resource Model Classes (UML format)

properly insert the part into equipment fixturing. Material handlers are typically industrial robots, and their placement in the shop floor layout determines which buffers, machines, and ports they may access. Material transporters, on the other hand, are equipment that usually lack manipulation and simply move products from one location to another. Examples of material transporters are automated guided vehicles (AGVs) and conveyors. Possible part movement within the facility with the use of these entities is specified with classes that instantiate ports, locations, and facilitators. A port represents a unique internal buffer belonging to a machine that owns one or more precise physical locations for part storage. These ports can be represented as nodes in the graph defining the paths parts can follow through the facility. Thus, the capability of each MH object to load and unload parts is defined by a list of loadable and unloadable ports. The capability of each MT object to move parts is defined by a list of reachable ports. The collection of these lists defines the material handling connectivity graph of the facility.18 Note that these ports only denote a buffer, and it may not be physically possible for a given MH resource to retrieve specific parts from a given port. Locations are specific, predefined areas in the port that may hold single parts of a given type. The coordinates of each part location are defined with respect to the port in order to keep these locations independent of changes in the facility layout. Lastly, instances of the BS class either passively hold parts with a possible

mechanical inversion or actively store the parts with an automated storage and retrieval system (AS/RS).

The tool assets in a manufacturing facility are instances of the T class of effecters. These effecters are used to enable material processors to perform operations on parts. This class includes processing machine tooling, CMM probes, and welding guns. Note that there is explicit ownership and grouping in this definition because only specific classes of tools function with different material processors. Thus, the subclass for MP that describes lathe machines only may own instances of lathe tool classes. Figure 3 illustrates some tooling classes and their attributes that can be owned by MP objects.

Fixtures in a manufacturing facility are instances of the F class that constrain parts to a location and possibly an orientation relative to the coordinate frame of some instance of the MP, MH, MT, or BS classes. For instance, a fixture might be a pneumat- ic clamp that holds the workpiece rigidly to a position and orientation in the work area of a milling machine. Another fixture is an electromechanical robotic gripper that holds a part fixed relative to the coordinate frame of the robot arm’s end effector coordinate frame. Other fixtures include part bins with a lesser constraint on position and slots on a conveyor belt that are built-in constraints of position and orientation. Similar to tool asset classification, there is also explicit ownership and grouping in this definition because specific classes of fixtures only function with specific classes of equipment.

412


2001

e ma

inherits

Surt&aTooi

inherits

Sore Material SPeC

inherits inherits

Face-mill End-mill

inherits

liOleTOOl

i47 start dia ax depth

inherits inherits

T/O Matwial soec

Reamer Matertal

Figure 3 Resource Model Tool Classes

The instructions for programmable resources in a _ _ - ._. manufacturing facility are instances of the class I that specify how manufacturing equipment entities can perform some task. Instances of subclasses of I include NC programs with machining instructions, robot programs to pick up a part at some location, an electronic chip placement machine program, and a solder reflow oven control program.

Figure 4 illustrates a part (P) class, a feature (FEA) class, and related classes. A part object is

defined by a list of features, the AND/OR graph of these features that defines precedence between the features, and a start and end buffer. A part object also owns an object of material class that defines the material type and hardness. A feature object may own one or more datum objects. Datum objects link the datum features that specify the location of a feature with the object representing the feature. Thus, datum objects have distance and tolerance attributes. The distance attribute defines the nominal distance

owns --

Figure 4 Part Model Classes (UML format)

413


between the datum and the feature, while the tolerance attribute defines the tolerance associated with this distance.

4. Creation and Maintenance of Resource Model Database

In the implementation, the resource class object data are stored in a relational database that is structured to support the object definitions in the resource model. A relational database was chosen because of the extensive human interfaces provided by commercial relational databases. The class methods that implement different layers of engineering functions are embedded in object-oriented software. This software creates instances of resource classes by reading the relational database tables and con- verting the tabular data into object data. This enables humans to directly monitor and adjust the data records for the resources in a manufacturing envi-

determined by the standard resource classification so that the object-oriented software can easily be designed to read the object-data from the database records. Similarly, the object-oriented software may also modify data in the database, such as the status of resources. To keep this simple, one table is created for each resource class, and the table is named using the same name as the resource class. Then each record in the table corresponds to the data for one instance of the class. Furthermore, the fields containing class attribute data have identical names as the class attribute names. The ownership relation between two classes is expressed using a one-to- many relation between primary keys of the owning table and foreign keys of the owned table. The inheritance relation is expressed using a one-to-one relation between the primary keys of the superclass table and the primary keys of the subclass table. Figure 5 illustrates some of the tabular relationships of the relational database that reflects the resource classifi-

ronment. Naturally, the structure of the database is cation in Figure 2.

Figure 5 Relationship Diagram of Database Tables of Resource Model

414

Journal OfManufacturing Systems Vol. 19/No. 6

2001

For the proposed resource model to reflect the actual resources in an enterprise’s manufacturing plant, the resource model database must continually be updated by a description of new resources that are added to the plant and by the status and measured capabilities of existing resources. This activity is represented in Figure I and takes inputs of process capability, equipment arrival, and status. Process capability ratios for quality control23 are a compact and standard means for storing process capability. Thus, these ratios are stored as attributes of resources to enable resource class methods to match process capabilities with tolerance specifications of the part. Ideally, this fixes a threshold for the num- ber of defects per production volume for the part and allows the process planner to directly plan for quality in resource selection and the process plan. As statistical data are collected from the shop floor using standard manufacturing execution system techniques, the results from the data analysis are stored in the resource model database of the plant. Any improvements in quality are also updated in the resource model. This integrates the quality control function with process planning and resource usage. Similarly, the recorded downtime history for resources on the shop floor can be summarized and updated in the resource model along with the current status of these resources.

5. Process Planning These resource classes facilitate the integration

of the engineering functions by providing a means to store the attributes and behavior of the resources. Reasoning about a resource’s capabilities for process planning is embedded in methods within the resource classes. These methods are based on standard language and practices for the specific equipment classes and reference object classes from other domains such as the product model, precisely defined by STEP-like elements representing features. Wysk, Peters, and Smith18 defined the possible discrete actions for different resources at the three levels of the hierarchy. At the shop level, the possible actions are load, unload, process, and move. Load specifies that a MH resource puts a part into a port and moves away. Unload specifies that a MH resource picks a part from a port and moves away. Process specifies that a MP resource performs some change to the mate-

rial of a part. Lastly, move specifies that a MT resource moves a part between workstations. These actions may be decomposed into more specific actions at the workstation level based on rules in the workstation class. For instance, a shop- level load action specifying that a MH robot resource puts a part into a MP machine resource translates into the following workstation actions: machine opens chuck, robot puts part into chuck, machine closes chuck, robot opens gripper and moves away. At the equipment level, these workstation actions are further decomposed into precise equipment instructions such as kinematic tra- jectories and machine tool paths. These actions are used at different levels of the shop floor hierarchy as building blocks for process planning by assign- ing to these actions preconditions and changes to the world state. Then, through the application of situation calcu1us,24 process planning software can determine a correct sequence of these actions to change from an initial part state to the goal state of a finished part. Given this action sequence, the process plan then specifies the sequence of command messages that correspond to these actions at the shop level by looking up the message names in the resource objects. Execution of these shop-level messages subsequently launches the execution of lower-level workstation and equipment-level messages and actions.

The MP process planning function may plan out feasible material removal processes for a specific facility represented by object R to match part specifications by querying all of its MP objects for each part feature. Because the process action does not require interaction between different resources within a workstation, the query is passed directly from the shop level to the equipment level. Then MP process planning class methods match the capability of the MP object against a feature (FEA) object. The planning procedure follows:

. a featurefeai of interest E FEA and a featurefeui that specifiesfeui’s position,

l a piece of processing equipment e E (MP c E), and

. a tool t E T, a fixturefE F, an intention int, and location lo,

equipment e is considered to be capable of making the feature feai if all of the following predicates are true:

415


(1) Owns (e, t), (2) makes (t,feaJ, owns (e, j), spec$es (f&j, feaJ, and locates (f; feai, int, lo). These predicates are defined as follows:

. owyls (a, b): true if a owns b

. makes (t E T, fea E FEA): true if tool t is designed to make feature fea

l speczfzes (a, b): true if a is designed to specify b’s position (related with a datum)

l locates cf E F, $?a E FEA, int, Zo): true iff is

designed to locatefea’s position with intention int using locator lo.

Because these process planning activities (implementation of predicates) are built into the resource class methods, virtual or polymorphic functions may be used to make this query independent of the changes in the MP objects for the facility or the type of feature.

Given this resulting aggregate MP process plan with alternatives, the next requirement is to create an aggregate MH plan that can move the part from a raw material buffer to the specified MP objects and then to a finished material buffer. Thus, the shop process planner generates a plan to move the part between these MP and BS objects according to the material processing plan by querying the MH and MT objects owned by the R or facility object. As mentioned previously, within workstations, rules embedded within object methods are used to determine the required actions by different machines to satisfy the part movement. Thus, the workstation queries its MH objects for the capability to first put a part into a machine chuck, release the part, and then move to a clear position. MH process planning methods match the capability of the entities against the material movement specification. These MH planning methods first check the port to be loaded against the list of loadable ports for the given MH object. If the port is in the list of loadable ports, then the kinematic and environmental constraints to sat- isfying the load task are checked using procedural constraints. These procedures use a combination of attributes that specify the kinematics of the MH object with the parameters defined by Denavit and Hartenberg 25 along with behaviors that match the kinematics to the product model and other constraints. Thus, one behavior is a path planning algo- rithm26 that attempts to plan a collision-free path for the MH object from a safe robot position to grasp

the part and back again. Specifically, for a given part at a port, the material handling process planner determines which of the predefined part locations at a port are accessible for picking or placing by a material handling resource. If any of the locations at a port are accessible by the resource, then the process plan specifies that the MH resource is capable of accessing the part at that port if the part can be placed at any of the accessible locations. Lastly, instructions are generated that specify sufficient information for the MH entities to move the part from locations at one port to another port. The resulting overall process plan from the machining and material handling process planning consists of an AND/OR task graph for the actual resource objects belonging to the facility and includes references to these instruction sets as well as the estimated time of execution. The AND/OR graph is seman- tically defined by Metalla2’ and can also be expressed using A Language for Process Speci- fication (ALPS):* Process Specification Language (PSL),4 the IS0 process plan model (IS0 TC 184/SC4), and so on. This process plan of shop-level actions and execution times reflects the capabilities of physical resources in the facility to manufacture the part and may be used either for capacity planning, production cost analysis, simulation, or for actual production.

6. Production Costing Activity-based costing has been proposed as a

way to integrate manufacturing cost estimation more closely with actual manufacturing costs. Johnson and Kaplan29 illustrate how typical manufacturing product cost estimation is based on the requirements of financial reporting as opposed to the requirements of manufacturing engineers and managers. Thus, typically, only one cost driver, such as direct labor, determines product costs, and all overhead costs are incorrectly allocated based on this driver. Such data are not useful for allocat- ing existing and new resources to production requirements. Instead, CooperJO suggests classify- ing the cost of activities with the categories of unit level, batch level, product sustaining, and facility level. Because discrete part manufacturing defines the scope of the resource model architecture, an activity-based cost rate is assigned to each resource class instance. This cost is a function of

416

the indirect cost to use the resource (power, water, coolant), direct labor to tend the machine during its operation, maintenance, and replacement. This cost concept is based on the basic cost value of using 1 unit amount of a resource for 1 unit of time by an activity.31

In our schema, the process plan defines the resources and time that are used by activities to make the part. Thus, unit-level manufacturing costs for a given product are computed by summing the products of all of the activities and active resource cost rate for individual units in the product’s process plan. Batch-level costs are computed by summing the products of setup activities and dormant resource cost rates for batches of units defined in the process plan. Batch-level costs include the activity-based cost of material handling that moves the units in batches. It is impor- tant here to note that these activity cost rates for resources do not always stay constant in practice. For instance, if the production rate within a given time period is increased and labor goes into over- time, then the labor cost component of the activity cost rate increases. Also, if the production lines are not balanced or are significantly blocked by frequent downtimes, then the costs of dormant resources will not be modeled in this process plan costing. This type of variable cost modeling goes beyond the scope of this research.

7. Shop Floor Execution Models Wysk, Peters, and Smith’* define the execution

portion of production to be the function that dispatches resources to tasks by issuing command messages to these resources. The interaction between the production execution system and the physical facility in Figure I represents this function. This execution function is implemented by using message-based part state graphs (MPSGs) that define a set of discrete actions and their sequences at three different levels defined by Smith.8 Furthermore, this execution model is automatically generated at the shop and workstation levels using the resource model. On the shop level, the MPSG has states and transition arcs that correspond to load, unload process, and move actions. Typically, the move actions directly correspond to actions by MT resources, while the load, unload and process actions are decomposed within work-

Journal of Manufacturing Systems

Vol. 19INo. 6 2001

station-level graphs corresponding to different workstations. Actions specified at the worhtution level, such as pick, put, process, and grasp, are decomposed further at the equipment-level graphs corresponding to specific equipment resources. The connectivity graph of the facility, described in a previous section, defines all of the possible interactions between the set of MH u MT resources and all other resources in the facility. The information represented by this graph is used, based on the list of loadable and unloadable ports for MH resources and the list of reachable ports for MT resources, plus additional information regarding the behavior of resources, to construct the shop-level MPSG. For instance, if a port belonging to a MP resource is on the list of loadable ports for a MH resource, then it is assumed that a load action is possible by that MH resource to the MP resource. This is followed by a process action by the MP resource, which is followed by an unload action by all MH resources with the port on their lists of unloadable ports. For loads to other types of resources, such as MT or BS entities, other rules apply that reflect the intention of loading the part to these resources. For instance, a load to a MT resource is followed by a move by the MT resource.

On another level, the workstation-level MPSGs are generated by decomposing all of the possible shop-level actions for the resources owned by each workstation object. For example, a previous section discussed how a load operation by a MH resource to a MP resource decomposes into the following workstation steps: assign the MP resource and open its chuck, MH resource puts part into chuck, MP resource closes chuck, and lastly MH resource opens gripper and moves away. Because processing is intended to occur after loading a MP machine, the workstation class also contains the rule that specifies that the MP does a process action after the load step. The workstation MPSG takes high-level instructions from the shop MPSG, decomposes the instructions, executes the instructions, and then sends back confirmation that the shop-level instructions were executed successfully. The message names to and from the shop are read from the shop object, while the message names for the equipment messages are read from the equipment objects owned by the workstation. The portion of the workstation MPSG for these load and process steps is illustrated by Figure 6.

417


load

proces._ol_ws

process_ok_mw

process_wm

Messages . XXKSW: Shop to Workstation

Worbtation to Shop W”.lrdzl+inn m Dnhn, process_sw

. xxi_ws:

. xxx_wr: ..VIRIIP.IVII w I,vYV,

. xx_wm: Workstatbn to Process Machine

. xxx_mw: Process Machine to Workstation

. xxx-r-w: Robot to Workstation

load_ok_ws

Message Functions . I: input messages to Workstation . 0: output messages from Workstation

Figure 6 Workstation MPSG Generation Rule for Robot Load to Processing Machine

8. Planning and Scheduling Shop Activities

In general, decision making in shop floor control activities has been partitioned into planning and scheduling. According to Jones and Saleh,32 planning is responsible for selecting between alternative routes and splitting part batches to meet capacity constraints, while scheduling is responsible for evaluat- ing candidate process plans and generating/updating expected start and finish times (the schedule) for the activities in the selected plan. According to Metalla,” planning is associated with removing OR nodes (deORing) and scheduling is associated with removing AND nodes (deANDing). Criteria used in deORing and deANDing include resource status, activity-based cost, processing time, material handling time, routing flexibility, and equipment load balancing. The criteria information is stored in the resource model, and it is dynamically maintained as the system changes. In this research, planning and

scheduling are performed separately. Given a production requirement (a group of process plans where each process plan contains alternatives), the planning module uses a two-step procedure. First, the alternative sequences associated with nonoperational resources are eliminated from the candidate sequences for the second step. Next, a good sequence is selected based on the equipment load-balancing criteria. It should be noted that material handling is also considered in planning.

Process plans provide “what” and “where” information, while scheduling mainly focuses on the determination of “when”. In general, the output of scheduling is either (a) a sequence of jobs for each resource or (b) a combination of dispatching rules. For the former case, the sequence of jobs is called a “work to schedule” for each resource. The start/finish times may be generated only for a purely static environment and a high-fidelity scheduler. In the latter case, each releasing/dispatching rule is associat-

418

ed with each decision point (e.g., logical queue in simulation). The start/finish times for each individual task, in this case, are not determined at the scheduling stage but will be dynamically determined at the actual production stage. Due to the dynamic nature of flexible manufacturing systems, the latter case is used for the simulation-based scheduling in this research. The resource model provides information for the scheduling module both in the system development stage and in the system operation stage. During system development, the resource model provides control policies such as releasing/dispatching strategy for each decision point. During system operation, the resource model provides real-time data for control policies that include resource status, activity-based cost, and processing and handling time.

Smith and colleagues33 proposed that once the system design has been finalized, the simulation that was used for evaluation can then be used as a basis for system control. This type of control is referred to as simulation-based control. Smith et al. also describe the architecture and implementation issues of simulation-based control. In the simulation-based control environment, the same simulation model can be used as a real-time control module (task generator) as well as a module to preview the results of different scheduling policies. This environment integrates the details of the. physical manufacturing system with the simulation analysis and production scheduling. Simulation modeling generally requires a high level of system detail. In addition to knowing about the system to be modeled, the modeler must also be skilled in the use of the simulation language, and potentially in appropriate statistical methods. Even for the experienced simulation modeler, modeling a complicated system can be a very time-con- suming process. There have been efforts to eliminate this constraint by generating the simulation model for analysis from already existing entities.34 This paper provides a framework to generate a simulation model for control from the shop-level MPSG that is generated from the resource model. Thus, the simulation model dispatches resources from the shop- level perspective and does dynamic scheduling according to scheduling policies.

In general, simulation models for shop floor control are composed of three classes of information: (a) static model information, such as shop layout and resource information, (b) dynamic information,


2001

such as potential part routing and state transition information, and (c) interfaces to/from an executor, databases, and external programs. The resource model provides the static information for the simulation model, while a shop-level MPSG execution model provides the dynamic information for the simulation model. The static information includes project information, replicate information, statistics, counters, pictures for animation, and names. For the dynamic portion, the finite state automata (FSA)- based shop-level MPSG combined with resource managing blocks specifies the skeleton of dynamic information (part flow) in the simulation model. For each entity (e.g., part), the state changes as its tasks are completed. Rules have been devised to generate a simulation model from the FSA-based MPSG execution model (a set of tasks). These rules are based on a resource management strategy that is specified in the resource model. For instance, if the shop-level MPSG specifies a load operation that involves a robot and a process machine, then both resources must be seized for the part before the operation may occur. After the load operation is completed, the robot resource is freed while the process machine is still seized. Figure 7 illustrates this example.

9. Resource Acquisition and Reconfiguration

The process of choosing specific resources for reconfiguration or purchase based on production requirements is expedited by the “plug and play” nature of the resource model. If a resource model standard such as the standard proposed by Jurrens, Fowler, and Algeo5 becomes accepted among manu- facturers and their vendors, then descriptions of resources available for reconfiguration or purchase could be developed using common terminology. For instance, we envision a resource object classification with unambiguous semantics defined using a common object-class language such as EXPRESS.35 The vendor has a resource database with a structure that matches this resource classification. Then software tools could be developed that copy the vendor’s description and classification of a specific resource into a new record of the resource model database. Then the vendor resource information becomes accessible to object-oriented planning software that simulates the potential benefits of this resource. Thus, the vendor-specific resource information is

419

Journal of Manufacturing Systems Vol. 19iNo. 6 2001

load_sw process_sw SEIZE: Machine2,l; Robot,1

;z DELAY: MglDFime,load-xd~:NEXTW$~;

Robot,1 ;

load_ok_ws process_ok_ws

Figure 7 Generation of Part of Simulation Model from Shop-Level MPSG

provided while the planning engineer determines other resource attributes such as position in the plant layout, tooling, and so on. The resource class behaviors that are used throughout the enterprise may be provided by software that is designed to accept these standard objects as parameters for input or output.

10. Illustration of Concepts with an Example Scenario

To illustrate the concepts explained so far, we propose the following scenario. A manufacturing engineer needs to determine how to make a new product within her company’s manufacturing plant. A resource model that uses the standard resource model classification describes the current resources of this plant. A STEP-like product model defines the new product in terms of features such as holes and sur- faces. The engineer, as an expert in manufacturing processes, knows the basic processes that will create the product from raw materials. She also knows the general categories of resources that can perform these processes. The engineer then uses process planning software, described in a previous section, that reads the resource model database of the plant to determine if the existing resources are capable of manufacturing the part. After computation, the process planning software indicates that the MP objects and their tooling in the resource model are capable of creating all but one hole in the part. This difficult hole is specified to have a high diametric tolerance that is impossible to create using the twist drill objects owned by the existing MP resources. To

plan for this difficult feature, the engineer identifies a basic process that will create the product. With her process knowledge, she selects the reaming operation with its high diametric tolerance capability. Next, she matches the category of reaming tools and possible vendors to this process. The classification of tooling includes references to the type of MP resources that can hold specific categories of tooling. In this case, the class of vertical milling machines supports the reaming tool. Next, the engineer can download the vendor-supplied object records for different reamer tools and determine the existing MP milling objects in the plant that use the&e types of tools. Now, the engineer can update her resource model of the existing plant resources with the new tools assigned to the appropriate MP objects. Next, the engineer must check if the MT and MH objects in the plant, representing robots and AGVs, are capable of executing the material handling plan resulting from this material processing plan. The engineer may have to change attributes of these objects, such as their positions (adjusting the layout), or add new fixture objects such as grippers to satisfy the constraints of the process plan. The results from the process planner connected to this new resource model assist the engineer to determine which tooling or fixtures are the best investment based on capability. This strategy also applies to the purchase of MP, MH, or MT objects, where the engineer tests out machines by adding them to the resource model and generating process plans based on their capabilities. Once a process plan is created the manufacturing engineer can automatically generate a simulation model to test

420

Journal of Manufacturing Systems Vol. 19Mo. 6

2001

Kardex AR/W port 1

Vert. MN Port 6

PUMA

Horiz. Mill Port5

ABB Robot

i’ . . . . . . . . . . . . .

AGV j i Station ;

ABB Robot

:.... . . . . . . . . . . . . . . . . . . . . . .

Lathe Port 10

Figure 8 Layout of Computer Integrated Manufacturing Lab

out the performance of the process plan. In this man- ner, the unit production cost may be estimated from the new process plan and the activity-based cost rates of the new resources. If the unit production cost is feasible, then the new resources may be purchased and installed in the physical plant. Next, a shop floor execution model is generated from the resource model. Lastly, this execution model and the simulation model are used to control the production of physical products. During production, the resource model database is continuously updated with the actual measured performance of the new resources.

11. Prototype Implementation Example Manufacturing System and Associated Resource Model

A resource model was created describing capabilities, locations,

that contains data and cost of usage

42

of machines and tools in the Computer Integrated Manufacturing facility at The Pennsylvania State University. This information integrates the engineering functions for this facility. Figure 8 illustrates the layout of machines in the facility that is reflected in the resource model. This resource model includes two workstations where each has three MP objects representing a Haas vertical milling machine, a Haas lathe, and a Haas horizontal milling machine. Each workstation also has a MH object representing an ABB robot arm. Each of these ABB robot arms is capable of moving parts between the machine tools and an AGV station. A MT object, representing an AGV resource, moves parts between a BS object representing a Kardex AS/KS and the workstations. Lastly, a MH object, representing a PUMA 560 robot arm, moves parts between an AGV station and the AS/KS. The MP objects own tool objects that are either physically located on the machine tools or can

Journal of Manufacturing Systems Vol. 19iNo. 6 2001

be loaded on the machines. For example, the two MP vertical milling machine objects own tooling for hole making. These tools include 52 types of twist drills, 36 types of reamers, and four types of boring tools. Data for the attributes of these tools, following the classification illustrated by Figure 3, were developed using data from Walsh36 and the United States Cutting Tool Institute.37

The port numbers for each general pickup or place position are specified in Figure 8. The loadable and unloadable ports for the MH object representing the PUMA 560 robot are ports 1 and 2, the left workstation ABB robot can load and unload ports 3, 5, 6, and 7, and the right workstation ABB robot can load and unload ports 4,8,9, and 10. The list of loadable and unloadable locations at each of these ports for each machine is a function of the geometry of the given part and obstacles in the environment. Lastly, the AGV MT object can reach ports 2, 3,4, and 11.

Process Planning A process planner and object-oriented product

model were developed to evaluate if this resource model integrates engineering functions for this facility. This process planner uses reasoning built into its own methods within the common resource model classes combined with means-end analysis plan- ning24 to match desired results with the capabilities of the resources. Thus, for material processing planning, the process planner seeks to match a part feature with a machining operation that is able to create the feature. Preconditions for this machining operation then become the next part feature to be created. For example, to create a hole feature in an aluminum workpiece with a Brine11 hardness of 148 in this facility, the process planner checks all available tooling owned by the Haas MP objects. The feature, with a depth of 0.5 in., diameter of 0.5 f 0.0003 in., center location f 0.015 in., and a maximum surface finish of 16 u-in., matches with the final result of a modeled reaming operation by the Rl-2Ml reamer tool. As specified in the resource model in Appendix A, the Rl-2Ml can do a finishing operation on 1108 aluminum with 1 OO- 150 Brine11 hardness that results in a hole with a final diameter of 0.5 f 0.0001 in., a surface finish of 16 u-in., and the center location f 0.01 in. The model for the finishing operation specifies the cutting speed = 60 in./rev and the feed = 0.015 fpm. To determine the time and cost of using

this process for design feedback, production planning, and production scheduling, standard machining time and costing equations are used to compute the cost of this operation. These are as follows:

machining time = 60 11: * diameter * depth / (12 * feed * speed)

total time = machining time + tool change time * machining time / tool life

total operation cost = total time * cost / time + machining time * tool cost / tool life

In the third equation, the “cost/time” factor is the key to the calculation, and reasonable constant data have been used. From these calculations embedded within class methods and the resource model information that specifies the tool’s cost rate, estimated life, and tool change time, the total time for the reaming operation is 5.36 seconds and the cost is $2.15. The resource model for the tool also specifies that the minimum start diameter parameter for the Rl-2M 1 tool is 0.4375 in. Thus, the precondition for doing the preceding operation is a hole of diameter 0.4375 in. As defined in Appendix A, the capabilities of another tool owned by the Haas mill, the DR7- 16M 1 twist drill, matches this hole’s specifications. Based on the recommended parameters in the resource model of 95 fpm and 0.012 in./rev and the preceding time and cost estimating equations, the total estimated time for the drill operation is 4.01 seconds and the cost is $1.5 1.

Once a final machining plan is generated, the process planner plans the material movement operations to move the part from a raw material buffer to the MP objects and then to a finished parts buffer.\ This involves a separate search for each material movement between locations in the facility. Again, means-end analysis is used for this search so that the planner matches the place position of the part with the capabilities of the MT and MH resources to physically place the part at the given location. Next, the possible pick ports corresponding to this place port are traced back until the required pick location corresponding to the previous machining operation is found. Thus, the search engine discovers that the first machining operation on the left Haas vertical milling machine requires that the PUMA 560 robot pick the part from the raw material buffer at port 1 and put it onto an AGV at port 2. Next, the AGV moves the part to port 3. Lastly, the ABB robot moves the part from

422

Journal of Manufacturing Systems Vol. 19Mo. 6

2001

port 3 to port 5 at the Haas vertical milling machine. Note that this reachable port list for each resource only reflects the facility designer’s initial plan for the buffers serviced by a given MH or MT object. The planner uses this reachable port list to reduce the initial search space and then uses path and grasp planning techniques to determine if the given MH resource is physically capable of picking and placing the given part between locations at the ports. The ideal process plan to move a given part specifies which locations, at a given port, different MH or MT entities are capable of retrieving or putting the part. For example, in the facility illustrated by Figure 8, the planner determines that the PUMA 560 robot is capable of moving the part from locations l-4 at port 1 on the Kardex ASRS to locations l-3 out of the four locations on an AGV at port 2. This is because a query to the motion planning system for the PUMA 560 robot revealed that location 4 at port 2 is outside of the reach of the robot. Then, the cost of this operation is simply computed using the estimated velocity of the machine, the distance to move the part between ports, and the cost per time to use the resource. Again, this cost may be used for design feedback in addition to production planning and scheduling.

The final process plan, generated by this process planner, integrates both the design and production functions. For design feedback, the sum of the cost of each MP, MT, and MH operation to create the part is used to give the designer an estimate of the cost of the design. Note that this activity-based cost does not reflect queuing costs in actual production, blocked production, and defects. After the design is finished the final process plan is passed along to the production function along with the appropriate instruction sets in order to control the physical shop floor resources to manufacture the part. The software implementing the production control functions uses the same resource classes with different methods to make planning and scheduling decisions based on the resource model and this production plan. Lastly, a shop floor execution system, generated from the resource model, issues commands to the resources based on the production plans of the parts in the current set of production orders.

Shop Floor Execution Model and Simulation Model Generation

Given a resource model, methodologies generating a shop floor execution model and a simulation

model have been presented in Sections 7 and 8, respectively. The software tool developed for the implementation is primarily in a Visual Basic Application (VBA) embedded in Microsoft Access 97TM-an Open Database Connectivity (ODBC) and Structured Query Language (SQL) compliant database system.

To store a generated shop-level execution model (MPSG model in this case), a Microsoft Access 97 database table has been used. Figure 9 shows the database structure and a portion of the generated data for the manufacturing system in Figure 8.

The Visual Basic Application (VBA) enabled the generation of an ArenaTM simulation model. The Automatic Simulation Model Generator (ASMG) and the Microsoft Access 97 database interact with each other through the Microsoft Access 8.0 Object library and the DA0 3.5 (Data Access Objects) Object library. DA0 is an application program interface (API) available with Microsoft’s Visual Basic that lets a programmer request access to a Microsoft Access Database. Part of the generated Arena model for the manufacturing system in Figure 8 is shown in Appendix B.

(a) Database structure

Figure 9 Database Structure for Storage of a Generated Execution Model and

Generated Data for Manufacturing System in Figure 8

423


Portability and Limitations of Proposed Architecture

A resource model and functions of an example manufacturing system have been presented in Section 11. As partially shown previously, software tools developed to implement the architecture in this research provide convenient user interfaces. For example, users can describe their manufacturing systems by filling in data in Microsoft Access database tables. The architecture presented in this paper appears to be easily applied to other automated shop floor environs. However, there are a few limitations of the software tools, including the following:

l The process planner is not able to pinpoint to the user why a resource configuration is unable to make a part.

l The capacity of material processing and handling equipment is assumed to be one.

l Mathematical verification of formal models (the symbolic logic structure) is ongoing research.

12. Conclusion This paper presented a resource model architec-

ture that integrates manufacturability analysis for product design, process planning, production costing, quality control, resource acquisition, planning and scheduling of production, and execution of shop activities with the behavior of the physical manufacturing resources (embedded in software application methods) that determine these functions. This architecture is based on a set of manufacturing resource classes that determine the structure of a resource model database. These classes are also used to build object-oriented software packages that implement different engineering functions. These functions are integrated because they are built on top of a common set of classes that have a one-to-one correspondence with physical resources. Furthermore, resource data can easily be shared between equipment vendors and man- ufacturers if they agree on a common, “plug and play” representation of these resource classes. These resource classes ease the development of engineering software that reasons about manufacturing resources because the resources do not have to be separately modeled for each application. This model also serves as an example for commercial enterprise software using a distributed object archi-

tecture. Such software may integrate different software packages that implement the different engineering functions with distributed object wrappers based on these resource object classifications.

References 1. National Science Foundation, Visionary Manufacturing Challenges

for 2020 (1998). 2. S. Feng, “Manufacturing Planning and Execution Objects Foundation

Interfaces,” NISTIR 6232 (Gaithersburg, MD: Nat’1 Institute of Standards and Technology, 1998).

3. W Gielingh and A. Suhm, IMPPACT Reference Model: An Approach to Integrated Product and Process Modelling for Discrete Parts Manufacturing (Springer-Verlag, 1993).

4. C. Schlenoff, M. Gruninger, F. Tissot, J. Valois, and J. Lubell, “The Process Specification Language (PSL): Version 1.0, www.nist.gov/psl, Nat’1 Institute of Standards and Technology (2000).

5. K. Jurrens, J. Fowler, and M. Algeo, “Modeling of Manufacturing Resource Information,” NISTIR 5707 (Gaithersburg, MD: Nat’1 Institute of Standards and Technology, July 1995).

6. M. Fox and M. Gruninger, “On Ontologies and Enterprise Modelling,” lnt’l Conf. on Enterprise Integration Modelling Technology 97 (New York: Springer-Verlag, 1997).

7. F. Fade], M. Fox, and M. Gnminger, “A Generic Enterprise Resource Ontology,” Proc. of 3rd IEEE Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, Morgantown, WV, 1994.

8. J.S. Smith, “A Formal Design and Development Methodology for Shop Floor Control in Computer Integrated Manufacturing,” PhD thesis (University Park, PA: Pennsylvania State Univ., 1992).

9. B. Whiteside, J. Friedman-Hill, and R. Detry, “PRE: A Framework for Enterprise Integration,” Proc. of Design of Information Infrastructure Systems for Mfg. Conf., Ft. Worth, TX, May 1998. 10. J. Poindexter and P. Cole, “Simulation Assessment Validation Environment (SAVE): Reducing Cost and Risk Through Virtual Manufacturing,” AGARD Conj Proc. (Oct. 1997). 11. N. Berry and C. Pancerella, “‘Agent-Based Enterprise Integration,” Proc. of 4th lnt’l Conf. and Exhibition on the Practical Application of Intelligent Agents and Multi-Agents (PAAM 99), April 19-2 1, 1999. 12. T. Finin and J. Weber, “Specification of the KQML Agent- Communication Language,” DARPA Knowledge Sharing Initiative External Interfaces Working Group, Feb. 1994. 13. M. Aguiar, I. Murgatroyd, and J. Edwards, “Object-Oriented Resource Models: Their Role in Specifying Components of Integrated Manufacturing Systems,” Computer Integrated Mfg. Systems (~9, nl, 1996), ~~33-48. 14. C. Pancerella, A. Hazelton, and H. Frost, “An Autonomous Agent for On-Machine Acceptance of Machined Components,” Proc. of Modeling, Simulation, and Control Technologies for Mfg., SPIE, Philadephia, Oct. 25- 26, 1995. 15. International Organization for Standardization (ISO), http://www.iso.ch/meme/memento.html 16. International Organization for Standardization (ISO), MANDATE Document No. IS0 15531 (1991). 17. International Organization for Standardization (ISO), STEP, Product data representation and exchange, Standard No. IS0 10303-n (1992). 18. R.A. Wysk, B.A. Peters, and J.S. Smith, “A Formal Process Planning Schema for Shop Floor Control:’ Engg. Design and Automation (VI, nl, 1995), pp3-10. 19. R. Florida and M. Kenny, The Breakthrough Illusion: Corporate Americab Failure to Move from Innovation to Mass Production (Basic Books, 1990). 20. S. Gupta and D. Nau, “A Systematic Approach for Analyzing the Manufacturability of Machined Parts,” Computer-Aided Design (~27, n5, 1995), ~~323-324. 21. G. Booth, “Object-Oriented Development,” IEEE Trans. on Sofbvare

Engg. (vSE 12, n2, 1986), ~~211-221.

424

22. H. Eriksson and M. Penker, UML Toolkit (New York John Wiley &

Sons, 1998). 23. Douglas C. Montgomery, Introduction to Statistical Quali@ Control (New York: John Wiley & Sons, 1997). 24. Nils J. Nilsson, Artificial Intelligence: A New Synthesis (San

Francisco: Morgan Kaufmann Publishers, 1998). 25. J. Denavit and R.A. Hartenberg, “Kinematic Notation for Lower-Pair Mechanisms Based on Matrices,” Journal of Applied Mechanics (1955),

~~215-221. 26. J. Latombe, Robot Motion Planning (Boston: Kluwer Academic Publishing, 1991). 27. E. Mettala, “Automatic Generation of Control Software in Computer- Integrated Manufacturing,” PhD thesis (University Park, PA: Pennsylvania State Univ., 1989). 28. B.A. Catron and S. Ray, “ALPS: A Language for Process Specification,” Int’l Journal of Computer Integrated Mfg. (~4, n2, 1991), pp105-113.

29. H. Johnson and R. Kaplan, Relevance Lost: The Rise and Fall of

Management Accounting (Cambridge, MA: Harvard Business School Press, 1990). 30. R. Cooper, “Cost Classification in Unit-Based and Activity-Based Manufacturing Cost Systems,” Journal ofCost Mgmt. (Fall 1990), ~~4-14. 31. K. Tham, M. Fox, and M. Gruninger, “A Cost Ontology for Enterprise Modeling,” Proc. of 3rd IEEE Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, April 1994, Morgantown, WV 32. A.T. Jones and A. Saleh, “A Multi-level/Multi-layer Architecture for Intelligent Shop Floor Control,” Int’l Journal of Computer Integrated Mfg.

(~3, nl, 1990), ~~60-70. 33. J.S. Smith, R.A. Wysk, D.T. Sturrok, S.E. Ramaswamy, G.D. Smith, and S.B. Joshi, “Discrete Event Simulation for Shop Floor Control,” Proc. of 1994 Winter Simulation Conf., 1994, ~~962-969. 34. S. Mathewson, “The Application of Program Generator SoRware and Its Extensions to Discrete-Event Simulation Modeling,” HE Trans. (~16,

1984), ~~3-18.

35. D. Schenck and I? Wilson, Information Modeling the EXPRESS Way (Oxford UK: Oxford Univ. Press, 1994).

36. R. Walsh, McGraw-Hill Machining and Metalworking Handbook (New York McGraw-Hill, 1994). 37. United States Cutting Tool Institute, Metal Cutting Tool Handbook, 7th ed. (Industrial Press, 1989).


2001

Authors’ Biographies Dr. Jay Steele is a senior simulation engineer for PRl Automation. He

has participated in research and coauthored several papers relating to robot- ics, manufacturing process planning, data modeling, and enterprise integration. He holds a doctorate in industrial engineering from Penn State University and a bachelor’s degree in applied physics from the University of California. Dr. Steele is a member of SME.

Dr. Young-Jun Son is an assistant professor in the Dept. of Systems and Industrial Engineering at the University of Arizona. Dr. Son received his BS degree in industrial engineering with honors from POSTECH in Korea in 1996 and his MS and PbD degrees in industrial and manufacturing engineering from Pemr State University in 1998 and 2000, tespectively. His research interests include computer-integrated manufacturing, simulation-based shop floor control, distributed simulation, virtual manufacturing, and virtual enterprises. Dr. Son was the Rotary International Multi-Year Ambassadorial Scholar in 1996, the Council of Logistics Management Scholar in 1997, and the recipient of the Graham Endowed Fellowship for Engineering at Penn State University in 1999. He was the representative of the Dept. of I&ME for the Engineering Graduate Student Council at Penn State University in 1997. He is an associate editor of the International Journal of Modeling and Simulation and a professional member of ASME, IEEE, IIE, INFORMS, and SME.

Dr. Richard A. Wysk is well known for his work in computer-integrated manufacturing, computer-automated manufacturing, computer- aided process planning, and concurrent engineering. He holds the Leonhard Chair in Engineering at Penn State University. Prior to his current position, he was director of the Institute for Manufacturing Systems and holder of the Royce Wisenbaker Chair in Innovation at Texas A&M University. Dr. Wysk also served on the faculty of Virginia Tech and worked in industry as a research analyst for the Caterpillar Tractor Co. and as production control manager for General Electric. He is a decorat- ed Vietnam veteran. Dr. Wysk is the author of several textbooks. Honors recognizing his research include the Institute of Industrial Engineers David F. Baker Distinguished Research Award and the Society of Manufacturing Engineers Outstanding Young Manufacturing Engineer Award. He holds bachelor’s and master’s degrees in industrial engineering and operations research from the University of Massachusetts and a PhD in industrial engineering from Purdue University.

Appendices A and B follow.

425

Ap

pen

dix

A:

Par

t o

f R

eso

urc

e M

od

el (

To

ols

)

DR

7-16

Ml

Tw

ist

Dri

ll R

esou

rce

Dat

a R

l-2

Ml

Rea

mer

R

esou

rce

Dat

a

para

met

ers

com

mon

to

all

mac

hine

to

ols

“hol

e”

Cla

ss

of t

ool

(hol

e m

akin

g to

ol)

“tw

ist

drill

” to

ol

type

“t

wis

t dr

ill

7-16

Ml”

to

ol

labe

l, on

ly

used

fo

r hu

man

in

terf

ace

“Ml”

to

ol

mat

eria

l 1.

0 se

tup

time

[sec

.] 0.

40

mac

hini

ng

cost

/tim

e [d

olla

rs/s

et.]

2.

0 to

ol

cost

[d

olla

rs]

0.10

to

ol

chan

ge

time

[sec

.] 50

00.0

to

ol

life

[sec

.] pa

ram

eter

s fo

r ho

le

mak

ing

tool

s 1.

3125

m

ax

dept

h [i

n.]

0.0

min

imum

st

artin

g di

amet

er

[in.

] pa

ram

eter

s sp

ecif

ic

to t

wis

t dr

ills

0.43

75

fina

l di

amet

er

[in.

] 0.

005

bila

tera

l di

amet

ric

accu

racy

[i

n.]

0.01

0 po

sitio

n ac

cura

cy

(allo

wab

le

diam

eter

of

cen

ter

poin

t)

[in.

] m

ater

ial

depe

nden

t ch

arac

teri

stic

s “a

lum

inum

” m

ater

ial

type

la

bel

“110

8”

wor

kpie

ce

mat

eria

l 10

0 m

inim

um

hard

ness

[B

hn]

150

max

imum

ha

rdne

ss

[Bhn

] 63

m

inim

um

surf

ace

fini

sh

[p-i

n.]

95

cutti

ng

spee

d [f

pm]

0.01

2 fe

ed

of t

ool

[in.

/rev

olut

ion]

“a

lum

inum

” w

orkp

iece

la

bel

“110

8”

wor

kpie

ce

mat

eria

l 15

1 m

inim

um

hard

ness

[B

hn]

200

max

imum

ha

rdne

ss

[Bhn

] 63

m

inim

um

surf

ace

fini

sh

[p-i

n.]

100

cutti

ng

spee

d [f

pm]

0.01

2 fe

ed

of t

ool

[in.

/rev

olut

ion]

tool

cl

ass

(hol

e m

akin

g to

ol)

tool

ty

pe

tool

la

bel

tool

m

ater

ial

setu

p tim

e [s

ec.]

mac

hini

ng

cost

pe

r tim

e [U

sec.

] to

o1 c

ost

[$]

tool

ch

ange

tim

e [s

ec.]

tool

lif

e [s

ec.]

max

imum

de

pth

[in.

] m

inim

um

star

ting

diam

eter

[i

n.]

para

met

ers

com

mon

to

all

mac

hine

to

ols

“hol

e”

“rea

mer

” “r

eam

er

Ml”

“M

l”

1.0

0.40

2.

0 0.

10

5000

.0

para

met

ers

for

hole

m

akin

g to

ols

1.5

0.43

75

para

met

ers

spec

ific

to

rea

mer

s 0.

50

0.00

1 0.

010

0.00

01

0.01

0 m

ater

ial

depe

nden

t ch

arac

teri

stic

s “a

lum

inum

” “1

108”

10

0 15

0 32

11

5 0.

012

16

60

0.01

5

fina

l di

amet

er

[in.

] ro

ughi

ng

bila

tera

l di

amet

ric

accu

racy

[i

n.]

roug

hing

po

sitio

nal

accu

racy

[i

n.]

fini

shin

g bi

late

ral

diam

etri

c ac

cura

cy

[in.

] fi

nish

ing

posi

tiona

l ac

cura

cy

[in.

]

mat

eria

l ty

pe

labe

l w

orkp

iece

m

ater

ial

code

m

inim

um

hard

ness

[B

hn]

max

imum

ha

rdne

ss

[Bhn

] ro

ughi

ng

min

imum

su

rfac

e fi

nish

[p

-in.

] ro

ughi

ng

cutti

ng

spee

d [f

pm]

roug

hing

fe

ed

[in.

/rev

olut

ion]

fi

nish

ing

min

imum

su

rfac

e fi

nish

[p

-in.

] fi

nish

ing

cutti

ng

spee

d [f

pm]

fini

shin

g fe

ed

[in.

/rev

olut

ion]

“alu

min

um”

mat

eria

l ty

pe

labe

l “1

108”

w

orkp

iece

m

ater

ial

code

15

1 m

inim

um

hard

ness

[B

hn]

200

max

imum

ha

rdne

ss

[Bhn

] 32

ro

ughi

ng

min

imum

su

rfac

e fi

nish

[p

-in.

] 12

0 ro

ughi

ng

cutti

ng

spee

d [f

pm]

0.01

2 ro

ughi

ng

feed

[i

n/re

volu

tion]

16

fi

nish

ing

min

imum

su

rfac

e fi

nish

[p

-in.

] 65

fi

nish

ing

cutti

ng

spee

d [f

pm]

0.01

5 fi

nish

ing

feed

[i

n./r

evol

utio

n]

Appendix B. Part of Generated ArenaTM Simulation Model (Experiment File)


2001

PROJECT,

ATTRIBUTES:

STATICS:

VARIABLES:

QUEUES:

AESMG,Young Jun SON,,Yes;

100,Pointer PP: 102,Order ID: IO4,Port_loc: 106,NC_file: 108,Equipment_id: pid:

frequency=0.01;

pid assign value, 1: pointer_Vert. Mill, 1: pointer-Ho&. Mill, 1:

Queue_AGV Station_O,FirstInFirstChtt: Queue_Lathe_O,FirstInFirstOut:

101,PartType: 103,order size: 1 OS,Robot_loc: 107,Time: SM_Realtime_Counter: SM_RealTime_TaskID;

# parts system,O: mode,2: pointer-lathe, 1;

Queue_Vert. Mill_O,FirstInFirstGut: Queue_Horiz. Mill_O,FirstInFirstGut;

PICTURES:

COUNTERS:

REPLICATE,

EXPRESSIONS:

NICKNAMES:

TASKS:

1 ,Gear_shift: 2,Lid: 3,Cube: 4,Yoyo: Default;

End run, 1000,Replicate;

1,0.0,10000,Yes,Yes,0.0;

SendMsgs l_Expr( l),par_enter#2@5_wb;

pick#2@l_sw_ExecExpr,O.O: put#2@3_wb_ExecExpr,O.O put##2@4_sw_ExecExpr,O.O: par_enter#/2@5_wb_ExecExpr,O.O: mv_to_spbs#2@5_wb_ExecExpr,O.O: pick#2@3_wb_ExecExpr,O.O: pick#2@4_wb_ExecExpr,O.O: mv_to_mp##2@l_wb_ExecExpr,O.O: pick_ns#2@5_wb_ExecExpr,O.O: mv_to_mp#2@3_wb_ExecExpr,O.O: mv_to_mp#2@4_wb_ExecExpr,O.O: process@l_wb_ExecExpr,O.O: put_ns#2@5_wb_ExecExpr,O.O: process@3_wb_ExecExpr,O.O: process@4_wb_ExecExpr,O.O: put#2@l_wb_ExecExpr,O.O;

put_ns#2@5_wb,O.O,“sim:bige:put_ns#2@5_wb %03.0f pos=%.Of sentity=ABB Robot”,IDENT,Robot_loc: pick_ns#2@5_wb,O.O,“sim:bige:pick_ns#2@5_wb %03.0f pos=%.Of sentity=ABB Robot”,IDENT,Robo_loc: mv_to_mp#2@l_wb,O.O,“sim:bige:mv_to_mp#2@l_wb %03.0f sentity=Vert. Mill”,IDENT: mv_to_mp#2@3_wb,O.O,“sim:bige:mv_to_mp#2@3_wb %03.0f sentity=Horiz. Mill”,IDENT: part_enter#2@5_wb,O.O,“sim:bige:par_enter##2@S_wb %03.0f ptype=%.Of”,IDENT,Part Type: mv_to_mp#2@4_wb,O.O,“sim:bige:mv_to_mp#2@4_wb %03.0f sentity=Lathe”,IDENT: put#2@l_wb,O.O,“sim:bige:put#2@l_wb %03.0f pos=%.Of sentity==ABB Robot”,IDENT,Robo_loc: put#/2@3_wb,O.O,“sim:bige:put#2@3_wb %03.0f pos=%.Of sentity=ABB Robot”,IDENT,Robot_loc: put#2@4_wb,O.O,“sim:bige:put#2@4_wb %03.0f pos=%.Of sentity=ABB Robot”,IDENT,Robot_loc: process@l_wb,O.O,“sim:bige:process@l_wb %03.0f filename=%.Of sentity=Vert. Mill”,IDENT,NC_file: process@3_wb,O.O,“sim:bige:process@,3_wb %03.0f filename=%.Of sentity=Horiz. MilP’,IDENT,NC_file: process@4_wb,O.O,“sim:bige:proces.s@4_wb %03.0f filename=%.Of sentity=Lathe”,IDENT,NC_file: pick#2@l_wb,O.O:‘sim:bige:pick#2@l_wb %03.0f pos=%.Of sentity=ABB Robot”,IDENT,Robot_loc: pick#2@3_wb,O.O,“sim:bige:picl#2@3_wb %03.0f pos=%.Of sentity=ABB Robot”,IDENT,Robot_loc: pick#2@4_wb,O.O:‘sim:bige:pick#2@4_wb %03.0f pos=%.Of sentity=ABB Robot”,IDENT,Robot_loc: mv_to_spbs#2@5_wb,O.O,“sim:bige:mv_to_spbs#2~5_wb %03.0f sentity=AGV Station”,IDENT,

427

Resource modeling for the integration of the manufacturing enterprise

Documents

Transcript of Resource modeling for the integration of the manufacturing enterprise