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 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.
- 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).
- 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.
- 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.
- Process representation for information interchanging: The process
representations classified into this category are STEP AP2131
Process planning representation for numerical
control machining.
Process planning representation,
structure, and properties.
- 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 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.
- precedence constraints due to geometric constraints: tool access
direction and work holding orientation;
- precedence constraints due to relocating the part adversely
affecting the repeatability requirement of a part, for example,
refixturing resulting in loss of positioning accuracy;
- precedence constraints due to geometric tolerance requiring extreme
repeatability, for example, reference surfaces must be machined before
the specified surface (Wysk, 1977);
- 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;
- 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;
- technological constraints: resource availability including
available tools, fixtures, and machines (e.g., machine criteria may
include acceptable part size, power, kinematic capability; and
- 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.
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).
