Hostname: page-component-74656f9884-8r8nv Total loading time: 0 Render date: 2026-11-07T13:37:27.619Z Has data issue: false hasContentIssue false
  • English
  • Français

Integrated product and process data for business to business collaboration

Published online by Cambridge University Press:  12 February 2004

BOONSERM KULVATUNYOU ,
NENAD IVEZIC ,
RICHARD A. WYSK  and
ALBERT JONES
BOONSERM KULVATUNYOU
Affiliation:
Manufacturing Engineering Laboratory, National Institute of Standards and Technology, Gaithersburg, Maryland, USA
NENAD IVEZIC
Affiliation:
Manufacturing Engineering Laboratory, National Institute of Standards and Technology, Gaithersburg, Maryland, USA
RICHARD A. WYSK
Affiliation:
Department of Industrial and Manufacturing Engineering, Pennsylvania State University, University Park, Pennsylvania USA
ALBERT JONES
Affiliation:
Department of Industrial and Manufacturing Engineering, Pennsylvania State University, University Park, Pennsylvania USA
Rights & Permissions [Opens in a new window]

Abstract

Collaborative development of engineered products in a business to business (B2B) environment requires more than the selection of components from an on-line catalogue. It involves the electronic exchange of product, process, and production engineering information during both design and manufacturing. Although the state of the practice does include a variety of ways to exchange product data electronically, it does not extend to the exchange of manufacturing process data. The reason is simple: process data are usually tied to specific manufacturing resources. These resources are not known typically at product development time. This paper proposes an approach called integrated product and process data, in which manufacturing process data are considered during product development. This approach replaces traditional process plans, which are resource specific, with a resource-independent process representation. Such a representation will allow a much wider collaboration among business partners and provide the necessary base for collaborative product development.

Keywords

Collaborative ManufacturingCollaborative Product DevelopmentIntegrated Product and Process DataProcess Planning DecompositionProcess Planning EvolutionVirtual Enterprise

Information

Type
Research Article
Information
AI EDAM , Volume 17 , Issue 3 , August 2003 , pp. 253 - 270
Copyright
© 2003 Cambridge University Press

1. INTRODUCTION

In a business to business (B2B) collaborative product-development framework, the service provider should be able to evaluate manufacturability and cost from the product data provided by the client. Moreover, in such a framework, the client and the service provider should be able to communicate the evaluation criteria, discuss the manufacturing content, and resolve any issues regarding conditions (e.g., time) of service delivery and general B2B relationships.

Traditionally, collaborative product-development approaches have relied exclusively on the product design data. However, design data do not provide sufficient information for B2B collaborative product development. There are two main reasons. First, design data do not provide the vocabulary, such as manufacturability and cost, to enable business-level communications. Second, geometric data alone are not sufficient for a number of downstream activities such as purchasing, production planning, and scheduling, which are needed to compute delivery dates, another crucial ingredient of B2B communications.

The objective of this paper is to propose a new approach whereby data describing a high-level work content are generated and associated with the features in the product design. This data, which constitutes a new type of process plan, supports a precise evaluation of manufacturability and cost and serves as a foundation for B2B communications and negotiations. Traditional process plans are resource specific: the data are generated based upon available resources, associated process knowledge, and capability. The proposed approach provides a resource-independent view of the process plan called Resource Independent Operation Summary (RIOS). This view is important because the client cannot know or assume the process capability of the manufacturer. For example, a machine at one shop will have different process accuracy from the same machine at another shop due to differences in usage and environment.

RIOS is a process model view of the product data and is the essential component of our proposed architecture. It captures high-level process and manufacturing requirements. RIOS-based architecture was created based on works in process knowledge modeling by Chang and Wysk (1985); process planning decomposition by Wysk et al. (1995); and process representation by Catron and Ray (1991) and Wysk et al. (1995).

In this paper, we make use of material-removal processes, such as hole making, roughing, and face making, in a flexible-manufacturing domain to illustrate our approach. For this application domain, the process knowledge includes the shape-producing capability, magnitude of volumetric capability, compatible materials, and production rate. This general process knowledge plays an essential role in generation of a RIOS instance from the design data. The RIOS specification schema itself consists of a number of information schemas including operation-level schema, process-level schema, graph-representation schema, and request for quote schema. Hence, generation of a RIOS instance implies an instantiation of these schemas in the context of a specific manufacturing task and general process knowledge.

As a conceptual example, Figure 1 illustrates the design of a part to be made from alloy steel wrought with 250 Brinell hardness. Using the general process knowledge, a process engineer can establish that the material removal process should be used to manufacture the part. Subsequently, a RIOS specification can be generated for the design, as illustrated in Figure 2. The figure illustrates that the RIOS specification captures high-level manufacturing requirements into two levels of directed graphs.

An example part design.

An example RIOS requirement specification.

The rest of this paper is organized as follows. Section 2 provides literature reviews of works related to the product data for manufacturing system integration and the process representation. Section 3 describes a collaborative manufacturing architecture that motivate the use of RIOS functionality. Section 4 outlines the key concepts that guided construction of RIOS. Section 5 gives important details of the schema definitions that constitute RIOS specification. Then, Section 6 illustrates construction of a RIOS instance using an example part. Finally, Section 7 concludes the paper by summarizing the proposed architecture and the RIOS approach.

2. LITERATURE REVIEW

Traditionally, collaborative product-development approaches have relied exclusively on the product design data. However, design data do not provide sufficient information for B2B collaborative product development. There are two main reasons. First, design data do not provide the vocabulary, such as manufacturability and cost, to enable business-level communications. These quantities must be derived from the design data. However, the technologies that can automatically map design data to manufacturing work content, which is necessary to evaluate the manufacturability and compute the cost, have been used successfully on simple products only. They fail to meet accuracy and completeness requirements needed for products that exhibit properties such as feature interaction, feature intersection, and feature isomorphism. Furthermore, their computational complexity is still very high because of the combinatorial explosion that occurs in performing machining-volume search (Subrahmanyam & Wozny, 1995).

Second, geometric data alone are not sufficient for a number of downstream activities such as purchasing, production planning, and scheduling, which are needed to compute delivery dates, another crucial ingredient of B2B communications. Other product representations are being defined on top of the geometric data. Among them are STEP (Standard for Exchange of Product Model Data, ISO 10303) Geometry and Topology Models Part 42 (International Organization for Standardization, 1994), Mechanical Product Definition for Process Planning Using Machining Features Part 224 (International Organization for Standardization, 2001), and Feature-Based Design Description Language (FDDL), a nonstandard effort by Gu and Elmaraghy (1989). These approaches will allow new features to be defined by combining a set of core features or by relating them directly to the geometric data. Although the set of core features provides better semantics for engineering, they are too detailed for B2B business-level communications. The ability to generate new, aggregate features will resolve this problem; but it may cause interpretation problems, which may lead to errors in the generation of work content. In addition, none of these approaches allows alternative representations, which would provide the flexibility of alternative semantics for the same features, thereby reducing the risk of interpretation problems.

Reviews of a number of process representations indicate that none of them satisfies the representational and functional requirements needed by RIOS as shown in the first column of Table 1. The reviews can be summarized and discussed by categorizing the process representation into five categories.

  1. Process representation for system analysis: These process representations are, for example, behavior diagrams (Ballard, 1991), Functional Flow Block Diagrams (Defense Systems Management College, 1986; Grady, 1993), and IDEF0 (Knowledge Based Systems, Inc., 2001a). The existing representations in this category have no semantic formalism; thus, they are not machine understandable, although some of them possess mathematical formalism, such as the Generalized Activity Network (Elmaghraby, 1977) and Hierarchical Task Network (Erol et al., 1994).
  2. Process representation for process documentation: IDEF3 (Knowledge Based Systems, Inc., 2001b) is an example of process representation in this category. It provides a formal construct to document how to do things, as well as what the system can do. Similarly, the process representation in this category merely provides a formal construct for human communication.
  3. Process representation for activity planning and scheduling: The representations in this category typically have limited capability; it represents the temporal relationship between tasks for planning and scheduling of resources. Examples of the process representations in this category are the Gantt Chart and PERT Chart (MI Standards Committee & Duncan, 1996). These representations provide no construct that would relate the task to the product information.
  4. Process representation for information interchanging: The process representations classified into this category are STEP AP2131

    Process planning representation for numerical control machining.

    (International Organization for Standardization, 1995b), STEP Part 492

    Process planning representation, structure, and properties.

    (International Organization for Standardization, 1995b), Process Specification Language (PSL; Knutilla et al., 1998), and Process Interchange Format (PIF; Lee et al., 1996). PSL, STEP Part 49, and STEP AP213 (which in turn relies on Part 49), which satisfy most of the requirements for the B2B collaborative product development shown in Table 1. However, these process representations only provide abstract-level constructs to identify the resource and the process capability requirements without specifying what those capabilities are.
  5. Process representation for manufacturing control: Examples of process representations in this category are the AND/OR directed graph by Wysk et al. (1995) and ALPS (A Language for Process Specification) by Catron and Ray (1991).

Summary of RIOS characteristics versus the representational and functional requirements of process representation

Wysk et al. (1995) specified a formal process plan schema associated with the manufacturing resource information that is necessary to control a computer-integrated manufacturing (CIM) system. This process plan schema provides sufficient information to evaluate the manufacturability, manufacturing cost, and product completion time. Although the schema has syntactic formalism based on the AND/OR directed graph, it lacks semantic formalism. The purpose of the schema is for shop floor control; thus, it is has no task composition/decomposition feature. ALPS was expected to be an integration protocol among process, production, and execution in a fully automated CIM system. It defines the information schema for specifying the information, resources, products, and materials that are required for performing manufacturing processes in terms of object entities (i.e., in an object-oriented manner).

APLS is extended from the AND/OR directed graph representation and the process view of GASP simulation language. Particularly, the hierarchical abstraction is a notable solution to the conflicting goals of simplicity, explicitness, and completeness of process specification that are important to RIOS. For example, an intelligent system would accept high-level specification and search for more information such as resource requirements from the given plan, eliminating the need for explicit resource allocation information. Although ALPS provides a rich construct, its emphasis is on the temporal relationship between tasks and events. ALPS also lacks linkages to resource capability requirement, process capability requirement, and product data.

Although the process representations identified by ALPS are powerful for its application areas, they lack one or more representational capabilities necessary for B2B collaborative product development. The rich syntax capability is typically important for low-level process representation where events and interactions between resources need to be handled. RIOS schemas developed in this research addresses all the process representation requirements identified in Table 1.

3. RIOS-BASED MANUFACTURING COLLABORATION ARCHITECTURE

Our main argument is that a definition of work content is necessary for B2B collaborative product development. Current technologies and past research efforts do provide us with accurate and repeatable approaches to work content generation. A key element of the proposed collaboration architecture is that work content can be specified and encoded independent of the target manufacturer and then sent to any manufacturing partner for automatic evaluation and negotiation. Such a work content specification, which we call RIOS, must be resource independent and integrate product data with process data.

Figure 3 illustrates an example of a collaborative, B2B Automatic Vendor Selection (AVS) architecture using RIOS. In this figure, a product designer, the client, has designed a part and needs to select a supplier to produce it. The client generates the RIOS specification of the design by using the generic process knowledge of the application domain. A request for quote, consisting of production requirements, design data, and RIOS data, is then distributed to different manufacturing (vendor) agents to evaluate time, cost, and manufacturability.

The Web-based automatic vendor selection architecture.

Each manufacturing agent must be able to understand RIOS so that its Resource Specific Process Planning (RSPP) module can generate a Resource Specific Routing Summary (RSRS) using input from the Manufacturing Resource (MR) model and the Process Knowledge (PN) model (see Fig. 3). The MR model is an information model that characterizes the available equipment (machine tools, robots, humans, cutting tools, fixtures) that the vendor could select to manufacture the finished product. The MR model must represent the technological and economical specifications for that equipment. For example, the technological specifications of a machine tool may include table size, repeatability, and capacity; the economical specifications of that same machine tool may include utilization cost, number of such machines, and operating status, as described by Kulvatunyou and Wysk (2000).

A PN model characterizes the process capabilities of the vendor. This model may be decomposed into shop-level knowledge and machine-level knowledge. Shop-level knowledge declares the processes the vendor can execute and the best attainable performance. This knowledge can be expressed in terms of high-level vocabularies such as shape-producing capability, quality, and process accuracy. Machine-level knowledge consists of both declarative and procedural knowledge. The declarative knowledge expresses the process capability specific to each resource, possibly in combination with other resources; the procedural knowledge expresses how resources should be utilized to achieve a set of process requirements.

The RSPP module uses the MR and PN models to determine when a given RIOS requirement matches the vendor's core competency. When a match occurs, the RSPP module generates the RSRS, a resource-specific specification of work content. For example, the RSRS of a vendor agent that results from a hole making process requirement may consist of twist drilling and finished reaming sequences whereas the RSRS of another agent may consist of twist drilling and semifinish boring sequences. Once the RSRS is generated, the vendor agent can respond to the client with delivery time and cost computed using, say, activity-based cost accounting procedures. A Manufacturing Control model, which represents the production strategy and activity flow of the manufacturing system, may be used to generate the cost and time estimations by taking Master Production Schedule and system dynamics into consideration. If not, the agent may initiate a negotiation process with the client or third party vendors

4. RIOS FUNDAMENTAL CONCEPTS

In this section we describe four concepts essential to the construction of RIOS: the process hierarchy that provides fundamental semantics for the RIOS specification, Universal Level Process Knowledge (ULPN) that includes only common process knowledge not specific to resources, the decomposition of process planning decisions that assures resource independence during RIOS construction, and the augmented AND/OR directed graph (digraph) that provides a representation scheme for RIOS.

4.1. Hierarchical modeling of process specification

Merriam–Webster's Dictionary (2001) provides seven definitions for the word “process.” There are three generic definitions and three definitions directed to specific fields such as biology, law, and manufacturing. In the most appropriate definition for this context, a process is “a series of actions or operations conducted to achieve an end.” This definition implies that a process may consist of a single operation with its own result or several actions, with each of these actions consisting of one or more such operations.

Figure 4 illustrates the process hierarchy, adapted from Ray (1987), and conceptualized in this research. Processes are clustered into two different types: self-driven and intentional. A self-driven process occurs by itself, for example, a natural or biological process. This type of process is not relevant to this research. An intentional process is actuated purposely by some mechanism, often human. In manufacturing, we can decompose these intentional processes into two types: business processes and fabrication processes. Business processes deal primarily with the integration and manipulation of information. Fabrication processes deal primarily with the transformation and transportation of materials. As such, they define the limitations on producibility and manufacturability of a given facility; hence, they are the focus of this research. In this paper, we limit the discussion to material transformation, specifically material removal processes. We believe that the results can be extended easily to material transportation.

The process hierarchy.

The process hierarchy in Figure 4 provides a semantic basis for RIOS scalability. That is, other types of processes can be added to the schema by subtyping the entities in the hierarchy, and definitions can be incorporated into the RIOS specification by following the procedure illustrated in Section 5.

4.2. ULPN concept

Process knowledge can be organized into three levels: a universal level, shop level, and machine level (Chang & Wysk, 1985). ULPN plays a significant role in RIOS because it contains only knowledge that is common to every resource capable of implementing that process. The Manufacturing Advisory Service (MAS) created by UC Berkeley associates (Wright, 2000) is an excellent repository of ULPN. Furthermore, MAS has demonstrated that a small subset of appropriate manufacturing approaches can be identified from conceptual design information. Examples of conceptual design information are overall shape, type of material, type of geometry, and overall precision. The ULPN also includes knowledge to perform economical analysis of processes such as minimizing the cost of selected processes and the number of handlings and maximizing the ease of handling. The use of ULPN will be illustrated in Section 6, where example RIOS construction is detailed. Two other levels are the shop level, which refers to the attainable process capabilities of a shop, and the machine level, which refers to the machine-specific process capabilities. Because they are resource specific, they are not used to generate RIOS; they are, however, used to process the RIOS and obtain RSRS by the manufacturing vendors.

4.3. Process planning decision decomposition

A resource-independent process plan, which can be used to evaluate product manufacturability at different facilities, must not presume resource availability and capability of those facilities. Thus, the decomposition of process planning into resource-independent decisions and resource-dependent decisions is critical. The resource-independent decisions are used to generate RIOS; the resource-dependent decisions are used to map RIOS to a resource-specific plan. Two prior efforts are relevant to our work.

First, Wysk et al. (1995) divided process planning into three steps: feature graph (precedence graph) generation, AND/OR graph of CLDATA (Cutter Location DATA), and AND/OR graph of machine/tooling/fixture combinations (NC File). Although CLDATA is portable to different machining equipment, only the first step of this process planning decomposition is resource independent. Once the CLDATA is generated, the specifications of equipment and tooling have already been defined and the processes that satisfy the accuracy requirements are already selected as well.

Second, Shah and Mantyla (1995) stated that tasks in process planning could be divided into the following four subtasks: operation planning: process selection; setup planning: grouping of operation; fixture planning: selection of work holding; and NC program generation: machine motion control program generation. It can be seen that the first two steps are in the reverse sequence to that proposed by Wysk et al. (1995). Shah and Mantyla (1995) left the process precedence until the second step and grouped them according to the tool access direction.

Although these two decompositions provide a high-level description of a good sequence of decision making, they lack sufficient detail for our purpose, which is separation into resource-independent and resource-dependent decisions. To do this, we need to augment these decompositions with several important constraints.

  1. precedence constraints due to geometric constraints: tool access direction and work holding orientation;
  2. precedence constraints due to relocating the part adversely affecting the repeatability requirement of a part, for example, refixturing resulting in loss of positioning accuracy;
  3. precedence constraints due to geometric tolerance requiring extreme repeatability, for example, reference surfaces must be machined before the specified surface (Wysk, 1977);
  4. precedence constraints due to economical rationalization of machining (typically side effect constraints), for example, machining a rough surface with a rough (inexpensive) process before applying a delicate (small and expensive tool) machining process; sequencing the process to reduce tool chattering;
  5. process accuracy constraints, that is, selection of required processes to achieve the specified accuracy. The result is a process precedence because of an unidirectional chain of process operations (Wysk, 1977), for example, when a hole needs to be bored or reamed, it must be drilled first;
  6. technological constraints: resource availability including available tools, fixtures, and machines (e.g., machine criteria may include acceptable part size, power, kinematic capability; and
  7. process economy: selection of the operation based on minimum cost and/or time.

The decisions regarding the first four constraints are resolved based on part geometric data, tolerance specification, and ULPN with minimum reflection on the resource and process capability specifics. Therefore, these four constraints are resolved at the time of RIOS generation. The other three decision criteria will be resolved at the time of RIOS mapping. Although interdependencies may exist among constraints, these can be handled by the alternative plan representation in RIOS (described in Section 4.4).

4.4. RIOS Representation

Because a product can be machined in several ways, RIOS must have the flexibility to allow alternative processes to be specified whenever they can be justified by the ULPN. Therefore, an augmented AND/OR directed graph (digraph) representation is used to facilitate that flexibility. This graph representation will be detailed in Section 5.2.

The RIOS specification is a requirement specification. That is, it only indicates the process and manufacturing capabilities necessary to produce the product. A requirement specification would consist of a statement like “The hole on this product requires a hole making process that can achieve 0.5-in. diameter and 0.008-in. positioning accuracy.” A descriptive specification would consist of a statement like “The hole on this product needs twistdrilling at 0.4687-in. diameter and then boring with 0.5-in. diameter.”

5. RIOS SPECIFICATION

RIOS specification schemas are divided into five parts to ensure extensibility and flexibility: RIOS_Support, RIOS_Transaction, RIOS_Operation_level_information, RIOS_GRAPH, and RIOS_Process_level_information. The support schema defines information entities in support of (i.e., shared by) other schemas. The graph representation schema provides precedence and alternative constructs to specify the requirements and processes defined in the operation information and process information schemas. The following subsections describe and partially illustrate each schema using the EXPRESS-G graphical representation (Schenk & Wilson, 1994; complete models with EXPRESS formal syntax can be found in Kulvatunyou, 2001). Figure 5 illustrates the EXPRESS-G notations.

EXPRESS-G symbols.

5.1. RIOS_Support entities

Entities defined in the RIOS_Support schema are used by other schemas. These entities include measurement entities and workpiece specification entities among others. Figure 6 illustrates the schemas of Workpiece and Length_measure entities.

Example entities in RIOS_support schema.

5.2. RIOS_Graph representation

The RIOS_GRAPH schema employs an AND/OR directed graph representation with extensions in the logical connection, task composition, task decomposition, and the process oriented nodes to capture the process plan alternatives, hierarchical tasks, and high-level process plan information. Because the RIOS schema represents high-level information, it is not necessary for the schema to have the capabilities to represent all the information requirements as described in Wysk et al. (1995). For example, it does not need to represent time duration, resource allocation, exception handling, error recovery, and cost data.

The RIOS graph representation essentially consists of AND, OR, and GROUP logical connections. The OR junction represents alternative processes or operations. The OR junction provides flexibility to the resource requirement evaluation. The AND junction represents alternative sequencing of the processes where both branches need to be visited. It has two subtypes—Serial_and and Parallel_and. The Parallel_and has another degree of freedom to execute the tasks simultaneously. The AND junction typically reflects alternative processing styles. The GROUP junction indicates that the processes within the connection may be combined into a single processing sequence.

RIOS is represented at two levels: Operation-Level Graph (OLG) and Process-Level Graph (PLG). Each node in the OLG specifies setup, types of resources required for all processes within the operation, and tolerance equations. Processes are associated to each operation by assigning a PLG to each node of the OLG. Each node in the PLG specifies the process capability requirements (e.g., dimensions and accuracy) to shape the workpiece into a finished product. PLG integrates process data with the product data by referencing the geometry from within the process requirement.

5.3. Transaction information

The RIOS_Transaction schema provides support for the request for quote interactions between a client (e.g., design house) and a manufacturing vendor. The application objects defined in this schema include business information and production requirements (business objectives such as order quantity and expected delivery time). The schema also defines application objects that encapsulate RIOS information necessary for manufacturability and cost evaluation such as part model and RIOS graph. The base entities in this schema are the RFQ_Transaction and the Quote entities.

5.4. Operation-level information

The RIOS_Operation_level_information schema defines information for equipment capability requirements, including kinematics, setup, work-holding capacities, and tolerance equations (variables in the equations will be associated with those in the process-level information). Figure 7 partially illustrates the schema. The schema has a hierarchical structure with each entity having either no label or an ABS label. The entities labeled with ABS are abstract entities; those with no label are instantiable (concrete) entities. One proceeds down this hierarchy, choosing among ABS entities that may exist at each level until only instantiable entities remain. Section 6 will illustrate the use of this schema.

Example entities in RIOS operation-level information schema.

5.5. Process-level information

The abstract entities in this schema (Fig. 8) associate processes to those operations modeled in the operation-level schema. For example, if the material-removal operation is specified, only the material-removal process subtypes can be associated with the operation. Each process is a unit of operation for which several passes may be needed to achieve the requirements in a process entity. In addition, each of these process entities is not a composition of others by definition. For example, each Hole_making_process is a single hole. A composite hole should be specified by placing several Hole_making_process within a GROUP connection. Then graph-based pattern matching can be used to recognize the process composition.

Example process entities in the RIOS process-level information schema.

Figure 9 illustrates the schema of Roughing_process entity as an example of several processes shown in Figure 8. The definition of each process essentially consists of geometric, topological, tolerance, material, and initial process information. Geometric information is defined by referencing the geometry in the product data. The roughing process is defined by a set of adjacent removal volumes. Only the definition of extrusion volume is shown in the figure. It should be noted that the set of adjacent volumes does not indicate the removal volume decomposition (with respect to a specific process); it merely indicates the volumes that need to be removed and that may be combined.

Schema of the roughing process entity.

6. EXAMPLE RIOS CONSTRUCTION

This section illustrates the use of ULPN to generate RIOS graph for an example part given in Figure 10. Several pieces of information, which significantly affect the cost of making a product, are available at the early design stage. As shown in the list below, they can be used to sketch an OLG (next to each criterion is the value associated with the example product). Some of the parameters below are the results of another criteria, such as the small batch size regulates setup cost and setup time to be low in order to maintain an acceptable cost.

  • Batch size: 10
  • Overall shape and geometry: prismatic
  • Bounding box volume: 7.5 in.3
  • Material: hot-rolled carbon steel wrought medium carbon, 350 bhn
  • Minimum dimensional tolerance: 0.001 in.
  • Minimum surface roughness: 125 μin.
  • Minimum wall thickness: 0.25 in.
  • Per part cost: low
  • Setup cost: low
  • Setup time: low

An example part design of a laser positioning bracket.

For each node in an OLG, according to the RIOS_Operation_level_information schema in Figure 7, the first step is to identify whether a business or a manufacturing operation is required. If a manufacturing operation is required, then the type (material transformation or material transportation) must be selected. Because the material transportation is not in the scope, the OLG consists of solely the material transformation operations.

Proceeding to the next step, the type of material transformation must be selected; currently, only material removal and geometry changes are considered. The following subsections discuss these two types of operations with respect to the parameters listed above.

6.1. The geometry change operation

Casting, extrusion, forging, sheetmetal forming, and injection molding are among the common types of geometry change operations used in production. Although sheetmetal forming and extrusion operations may meet most geometry and accuracy requirements, sheetmetal forming requires ductile material and extrusion has a 2.5-D geometry limitation. The example part is a true 3-D part, requiring machining on top and bottom, and it is made from carbon steel, which does not have ductile properties. More importantly, most geometry change operations are meant for a very large batch production and high production rate due to the very high setup time and cost associated with the die and/or pattern. This is a major parameter determining that the geometry change operation is not a favorable choice for the example design and production requirements.

6.2. Material removal operation

There are four types of operations in the material-removal operation category: chemical, thermal, electrical, and mechanical. The kinematic capabilities of these operations make them applicable to a wide range of geometries, scales, materials, and precisions. The setup cost associated with these operations is low because setup equipment can be configured differently and reused. Setup time can vary considerably depending on the tolerance requirements and the geometric complexity of the workpiece. The example part will take only minutes to set up using a low cost and simple rectangular vise. One characteristic of the material removal operation that differentiates it from other types of material transformations is the relatively slow production rate. These characteristics make the material-removal operation suitable for the small to medium batch size production (1–500 pieces). After considering each of the four material-removal operation subtypes, we have selected the mechanical-removal operation for the example part. We justify this selection in the rest of this section.

Examples of chemical-removal operations are chemical etching and electrochemical machining. These operations are clearly not suitable for the example part, because they typically operate on silicon composite materials in the micro- to nanometer range of the overall part dimension.

Examples of common tools for thermal-removal operations are torch (or gas), plasma, and laser. This type of operation typically produces a very coarse surface finish, and it can only be used reliably to cut depths of 0.5 in. or less (Duane Jaworski & Associates, 2001). In addition, the underlying heat permeation makes it difficult to control final dimensions. Consequently, it is used only to remove stock material quickly. The only exception is laser cutting, which, although expensive, has several advantages over mechanical cutting including material independence, a high-quality surface finish, an oblique removal direction, and dimensional accuracy. Nevertheless, these capabilities are unnecessarily costly for the example part. We conclude that thermal removal is not a viable option.

Examples of electrical-removal operations are electric discharge machining and sputtering. These operations slowly remove a thin layer of material by using either electric sparks to boil the material or electron particles to collide with the material. This type of operation, which typically removes material in the micro- to nanolevel regime, may be used to cut special features into parts of varying sizes, materials, and geometries (Rajurkar, 1990). Although this type of operation can easily obtain nanometer precision, the underlying heat limits the surface quality to the same level as that of mechanical-removal operation. In addition, setup time is high and setup cost is moderate. Consequently, we conclude that these operations are not needed for the example part.

A mechanical-removal operation imparts a shear force through sharp cutting edges to remove material. This type of operation is versatile because of the sophisticated motion control to approach the workpiece from multiple directions and the variety of tool geometries that can remove material from the workpiece. Setup time depends on the workpiece geometry and the required rigidity. Setup cost is usually low, because the same set of tools can be reconfigured differently. The removal rate, which depends on the required tolerances, is considerably quicker, if not the quickest of all material-removal operations. Because of the moderate production rate, setup time, and setup cost, the processes in this category are generally suitable for a small to medium batch size from single to hundreds of pieces of production. The bounding box volume can range from 0.1 to 3000 in.3. Complex contours, free form surfaces, and gear shapes can be produced. Tolerances of ±0.005 in. can be reached easily, but ±0.001 in. requires more control. Tolerances in the four-digit range are achievable, but it is significantly more costly (Wright, 2000). Since 16-μin. surface finish is achievable, the required 125-μin. surface finish on the example part is considered easy to achieve. Thin-wall surfaces, however, are a limitation; 0.1-in. thickness over a minimum of 5-in. span can be machined. Once again, we have selected the mechanical-removal operation for the example part.

6.3. Constructing the OLG

The example part consists of a slot feature, two steps, one counterbored hole (consisting of a core hole and a c-bore hole), and a 4-hole pattern (see Fig. 11). The part needs at least two operations (setups) because the slot is on the opposite side from the other features; we will refer to the side on which the slot is as the bottom and the opposite side as the top. The first constraint in Section 4.3 deals with work-holding and tool-access directions; therefore, the first question is which side and which features to do first. Usually, the answers to these kinds of questions are based on economic rationalization, which is affected by the number of material-handling setups, machining operations, process accuracy, and total cost. In the example part, processing the bottom side first simplifies the material handling operations. On the other hand, processing the top side first allows the step to be processed before the hole pattern. This simplifies the cutting process, because there will be no interruption during the step machining. In addition, the tool chatter reduces, because the depth of the hole decreases. Therefore, regardless of the resource-specific data, the OLG will be constructed such that the operations on the topside precede those on the bottom side.

A tolerance chart of the example part.

During the first setup, the hole pattern, both steps, and the counterbored hole will be machined. The question is in which order. We already established that the steps will be done before the holes. Furthermore, the entire hole pattern must be processed in the same setup because relocating the part will adversely affect the positioning repeat-ability (the second constraint). To determine the remaining order, we must consider both datums and stack-up. The step (the boss's side face), which produces datum D, is positioned with respect to datum C. The core hole is positioned with respect to datum D, and the c-bore hole is then positioned with respect to the core hole. Therefore, the tolerance stack-up (Fig. 11) from the step processing to the core hole and the c-bore hole must be taken into account. The result of the tolerance stacking causes the process accuracy requirement of the steps (M20) to be one order of magnitude higher (0.0025 in.) than the regulated constraint (C20 = 0.02). Thus, an alternative path (an OR connection) should be given to process the steps and the hole pattern in a separate operation from the counterbored hole. This alternative allows 0.02-in. tolerance (M20) to process the steps and the 0.0025-in. tolerance allowance (if M32 and M42 are allocated equally) to process the counterbored hole, the same as the process in a single setup case. We note that the tolerance equations are associated with the Tolerance_equation entity as indicated in the operation schema in Figure 7. Figure 12 summarizes the OLG. Table 2 summarizes the data associated with operation 3. The surface id interlinks this process data with the design data.

Summary of data associated with OP3 node

The operation-level graph of the example part.

6.4. Constructing the PLG

There must be four PLGs associated with each of the four operations in the OLG; however, only the PLG associated with operation 3 (OP3) will be illustrated here. OP3 consists of only the counterbored hole with a different datum system from operations 1 and 2. Figure 13 illustrates the PLG (PLG3) for this operation. In this graph, two Hole_making_process nodes are grouped using the GROUP connection node representing the counterbored hole. The GROUP connection indicates that it is possible to combine the two processes into a single sequence by using a composite tool geometry. The GROUP connection also implies that the removal volumes of the process within the connection are adjacent. Table 3 provides a summary of the data associated with the core hole from PLG3. Notice that the variable M32 is associated with the true position in the Positioning_with_tolerance row. The value is assigned after the tolerance equations in the OLG are resolved by the RSPP module.

Summary of data associated with PLG3

The process-level graph (PLG3) of operation 3 (OP3).

6.5. Usage within a collaborative framework

Once completed, the RIOS data package can be shipped with the product data package to the manufacturing vendors. It can be used for collaborative activities such as request for quote or automatic vendor selection, as illustrated in Section 3. It should be noted that one important benefit of using RIOS to communicate engineering requirements is that it provides a language for negotiation. The manufacturability result can be directed toward specific processes and even specific process requirements, which cause trouble and cost money. The client (who requests the quote) can use the manufacturability and cost estimation result (which is also detailed for cost associated with each process and operation) to negotiate the cost he/she believes should be lower (an expected cost threshold might be set upfront). Although the original manufacturability result might be generated by minimizing the lead time, the manufacturer, when asked to lower the cost, may reevaluate the manufacturability by minimizing the cost. In other events, the manufacturer may try to change planning criteria and subcontract some operations to other manufacturers, whose capabilities match the requirements better and who can produce a lower cost.

7. CONCLUSION

In this paper we described the use of integrated product and process data for B2B collaborative product development. We argued that, because traditional process data are resource specific, a set of schemas and methodologies for representing resource-independent processes was needed. We called this data RIOS. RIOS not only facilitates the evaluation of manufacturability but also provides a set of vocabularies for business and manufacturing negotiation. We used an example part to illustrate the RIOS data that could be generated during the product development process, the proposed schemas, the process planning task decomposition, and the ULPN. Although the example part was for metal-removal machines, we believe that the developed schemas may be extended to other manufacturing processes. Another part of this work, which details the resource-specific process planning from the RIOS data, is in its final development stage and is showing much promise.

ACKNOWLEDGMENTS

This work was funded by the National Institute of Standards and Technology (NIST SB1341-01-W-0383).

Boonserm Kulvatunyou is currently a Guest Researcher at the National Institute of Standards and Technology (NIST) at Oak Ridge National Laboratory. He received his PhD from Pennsylvania State University, University Park, in 2001. He received his MS from Columbia University in 1997, and his BS from Chulalongkorn University, Bangkok, Thailand in 1995. He is a senior member of the Society of Manufacturing Engineers (SME) and Computer and Automated Systems Association (CASA) of SME. He is also a member of the American Association for Artificial Intelligence (AAAI). Dr. Kulvatunyou's research interests include computer-integrated manufacturing systems, simulation of manufacturing systems, enterprise and e-business integration, and information modeling.

Nenad Ivezic is a Guest Researcher at the National Institute of Standards and Technology at Oak Ridge National Laboratory. He received his MS and PhD degrees from Carnegie Mellon University and BS degree from University of Belgrade. His interests include artificial intelligence, distributed systems, supply chain management, and enterprise systems integration. Dr. Ivezic is currently working on developing a Manufacturing eBusiness Testbed. He actively participates in standards development for e-business technical specifications and explores advanced approaches for enterprise systems integration. At Oak Ridge, he was a Principal Investigator for agent-based systems development for Lockheed Martin and the Defense Logistics Agency and for the Collaborative Management Environment of the U.S. Department of Energy.

Richard A. Wysk currently holds the Leonhard Chair in Engineering at Pennsylvania 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. He has also served on the faculty of Virginia Polytechnic Institute and worked in industry as a research analyst for Caterpillar Tractor Co. and as production control manager for General Electric. He received his PhD in industrial engineering from Purdue University in 1977 and his BS and MS in industrial engineering and operations research from the University of Massachusetts (Amherst) in 1972 and 1973, respectively. 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 Engineering Award. His research interests include computer-integrated manufacturing, computer-automated manufacturing, computer-aided process planning, and concurrent engineering.

Albert Jones manages the Manufacturing Enterprise Integration Program at the National Institute of Standards and Technology (NIST). Prior to joining NIST, he led several projects to investigate the functional and integration requirements for next-generation simulation tools. He worked with Dr. Rabelo from Ohio University and Dr. Yih from Purdue University to develop an artificial intelligence based real-time and reactive scheduling system. Dr. Jones also spent several years as Deputy Director of the Automated Manufacturing Research Facility at NIST. His earlier research includes the development of system architectures for shop floor control, cell control, and distributed scheduling. He has published numerous articles on control systems, scheduling, and simulation. Before coming to NIST, Dr. Jones taught for several years at John Hopkins University and Loyola College of Baltimore. He received his MS in Mathematics and PhD in Industrial Engineering from Purdue University. Dr. Jones is currently on the Executive Boards for the Winter Simulation Conference and the Engineering School at Loyola College of Baltimore. He has chaired or cochaired several international conferences and has served on several proposal evaluation panels for the National Science Foundation, NIST, and the Defense Advance Research Agency.

References

REFERENCES

Ballard, C.W. (1991). Basics of Behavior Diagrams. San Jose, CA: Ascent Logic Corporation.
Catron, B.A. & Ray, S.R. (1991). ALPS: A language for process specification. International Journal for Computer Integrated Manufacturing 4(2), 105–113.Google Scholar
Chang, T.C. & Wysk, R.A. (1985). An Introduction to Automated Process Planning Systems. Englewood Cliffs, NJ: Prentice Hall.
Defense Systems Management College. (1986, December). Systems Engineering Management Guide. Available on-line at http://www.dan.mil/pubs/pubs%2Dmain.asp#Online
Duane Jaworski and Associates. (2001). Available on-line at http://www.djmetalrep.com
Elmaghraby, S.E. (1977). Activity Networks: Project Planning and Control by Network Models. New York: Wiley.
Erol, K., Hendler, J., & Nau, D.S. (1994). Semantics for Hierarchical Task Network Planning. Technical Report. College Park, MD: University of Maryland, Computer Science Dept., ISR, UMIACS.
Grady, J.O. (1993). System Requirements Analysis. New York: McGraw–Hill.
Gu, P.H. & Elmaraghy, H.A. (1989). A feature-based design description language. ASME Design Engineering Division 17, 53–63.Google Scholar
International Organization for Standardization. (1994). ISO 10303 Part 42: Industrial Automation Systems and Integration—Product Data Representation and Exchange—Part 42: Integrated Generic Resources: Geometric and Topological Representation. Geneva: International Organization for Standardization.
International Organization for Standardization. (1995a). ISO 10303 Part 49: Product Data Representation and Exchange: Part 49: Application Protocol: Integrated Generic Resources: Process Structure and Properties. Geneva: International Organization for Standardization.
International Organization for Standardization. (1995b). ISO 10303 Part 213: Product Data Representation and Exchange: Part 213: Application Protocol: Integrated Generic Resources: Process Structure and Properties. Geneva: International Organization for Standardization.
International Organization for Standardization. (2001). ISO 10303 Part 224: Industrial Automation Systems and Integration—Product Data Representation and Exchange—Part 224: Application Protocol: Mechanical Product Definition for Process Planning Using Machining Features. International Organization for Standardization.
Knowledge Based Systems, Inc. (2001a). The overview of IDEF0: Function modeling method. Available on-line at http://www.idef.com/overviews/idef0.htm
Knowledge Based Systems, Inc. (2001b). The IDEF3 Process Flow and Object State Description Capture Method Overview Process Description Capture Method. Available on-line at http://www.idef.com/overviews/idef3.htm
Knutilla, A., Schlenoff, C., Ray, S.R., Polyak, S.T., Tate, A., Cheah, S.C., & Anderson, R.C. (1998). Process Specification Language: An Analysis of Existing Representations. National Institute of Standards and Technology. Document 6160. Gaithersburg, MD: NIST.
Kulvatunyou, B. (2001). A resource independent process representation for enterprise-based engineering integration. PhD Thesis. Pennsylvania State University.
Kulvatunyou, B. & Wysk, R.A. (2000). A functional approach to enterprise-based engineering integration. Journal of Manufacturing Systems 19(3), 156–171.Google Scholar
Lee, J., Gruninger, M., Jin, Y., Malone, T., Tate, A., & Yost, G. (1996). The PIF Process Interchange Format and Framework Version 1.1. Technical Report Working Paper 194. MIT Center for Coordination Science.
Merriam–Webster. (2001). Merriam–Webster's Collegiate Dictionary. Available on-line at http://www.m-w.com
MI Standards Committee & Duncan, Bill (1996). A Guide to the Project Management Body of Knowledge. Upper Darby, PA: Project Management Institute. Available on-line at http://www.pmi.org/pmi.publictn/pmboktoc1.htm
Rajurkar, K.P. (1990). Technology and research in electrodischarge and electrochemical machining. Fundamental issues in machining. ASME PED 43, 309–336.Google Scholar
Ray, S.R. (1987). Process reasoning. Computers in Industry 9, 329–335.Google Scholar
Schenck, D. & Wilson, P. (1994). Information Modeling the EXPRESS Way. New York: Oxford University Press.
Shah, J.J. & Mantyla, M. (1995). Parametric and Feature-Based CAD/CAM. New York: Wiley.
Subrahmanyam, S. & Wozny, M. (1995). Overview of automatic feature recognition techniques for computer-aided process planning. Computers in Industry 26(1), 1–21.Google Scholar
Wright, P. Manufacturing Advisory Service. (2000). Berkeley, CA: University of California, Berkeley, Integrated Manufacturing Lab. Available on-line at http://cybercut.berkeley.edu/mas2/index.html
Wysk, R.A. (1977). An automated process planning and selection program: APPAS. PhD Thesis. Purdue University.
Wysk, R.A., Peters, B.A., & Smith, J.S. (1995). A formal process planning schema for shop floor control. Engineering Design and Automation 1(1), 3–19.Google Scholar
Figure 0

An example part design.

Figure 1

An example RIOS requirement specification.

Figure 2

Summary of RIOS characteristics versus the representational and functional requirements of process representation

Figure 3

The Web-based automatic vendor selection architecture.

Figure 4

The process hierarchy.

Figure 5

EXPRESS-G symbols.

Figure 6

Example entities in RIOS_support schema.

Figure 7

Example entities in RIOS operation-level information schema.

Figure 8

Example process entities in the RIOS process-level information schema.

Figure 9

Schema of the roughing process entity.

Figure 10

An example part design of a laser positioning bracket.

Figure 11

A tolerance chart of the example part.

Figure 12

Summary of data associated with OP3 node

Figure 13

The operation-level graph of the example part.

Figure 14

Summary of data associated with PLG3

Figure 15

The process-level graph (PLG3) of operation 3 (OP3).