Published online by Cambridge University Press: 28 January 2005
One of the aspects of mass customization is to provide customers with products that are manufactured to their needs and requirements. To provide such support requires better integration of the customer into different stages of design and manufacturing. Expansion of the Internet provides an opportunity for such an integration, which will need to link design and manufacturing of the company with the customer. In current approaches, customers usually specify the options and get the price or simple pictures of the object. In this paper we present a framework in which customer options and size parameters are gathered using the Internet. It is used to automatically generate a 3-dimensional computer-aided design model of the product, estimate the price of the product, and generate assembly sequence information. The framework for mass customization of products necessitates information management among different segments of the company and the customer. The Internet-based system presented in this paper uses a graph grammar and templates to explicitly maintain correspondence among various types of product information from a module perspective. The system is demonstrated using a customizable coffeemaker product family.
The new shift in the current market has introduced the concept of product family design, in which variety and customization replace standardized products. As a business model, mass customization is a “win–win” strategy for the customer and producer. The customers benefit because they receive goods and services that embody their own tastes. Producers benefit because they operate with no inventory and deliver a product on demand. Designing a family of products starts with a good platform approach. “A product platform is a collection of the common elements, especially the underlying core technology, implemented across a range of products” (McGrath, 1995). In a product family and common platform approach, products must be designed around common parts, versatile modules, standardized interfaces, common fixture geometries, and standard processes to reduce the cost of variety.
Mass customization is a way of building and selling products such that the product features are broken down and offered to the consumer as choices. Providing customized products requires establishment of an information framework that can support product and process data exchange among different entities (design, manufacturing, procurement, etc.) of the enterprise. Information such as function, product structure, process, cost, supplier information, and so forth, need to be readily available to ensure proper execution of a mass customization framework (Siddique et al., 1998). Furthermore, to simplify the product portfolio architecture, it is essential to use a platform and modularity approach. Tools are required to explicitly maintain correspondence among various product information from a module perspective (Siddique & Rosen, 1999, 2001).
In mass customization, product specifications are decided and/or designed by customers using an on-line communication between customers or designers and manufacturers (Helander et al., 1998; Yen & Ng, 2000). The rapidly expanding World Wide Web resolves the problem of capturing the customer's specification economically to support mass customization. Internet facilitates mass customization by allowing the customers to go through the product offerings at their own pace. The Internet also enables customers to deliver their specifications (Eastwood, 1996) in a structured form, which can then be used to design and manufacture the product.
One suggested approach to provide customization through the Internet is by using an electronic catalog (Yen & Ng, 2000). To provide feedback to the customer, cost and a pictorial representation of the customized product is displayed to the user (Yen & Ng, 2000). In most cases the final user-preferred product is displayed in a 2-dimensional (2D) form for user feedback, which may not provide the capabilities for a comprehensive inspection of the product. A consumer can be more comfortable with a 3D view rather than a 2D view of the product (Rau–Chaplin et al., 1997; Elspass et al., 1999). Some companies are providing 3D views, but these 3D models/views are not true representations of the customized product; only cosmetic changes, such as color, texture, and so forth, are made to the 3D models (Dauner et al., 1998). Several Industries (Nook Industries, Kaydon Bearings, Samtec, Festo, etc.) have successfully used 3D catalogs to provide customers with computer-aided design (CAD) models, which have increased sales and reduced cost per sale (http://www.3dcontentcentral.com). Providing a complete model of the product to the customer can provide several benefits:
These benefits eventually increase customer satisfaction for the company.
Considering the present technology, the best way to see a virtually designed product is through CAD, which gives complete control over the product. Benefits of a CAD model include full control in viewing and regenerating the model by changing the design parameters and configuration. Kim et al. (1999) developed a Web-based distributed collaborative design environment, where STEP data of the CAD model was converted to B-Rep data and then sent to the client for visualization. Chen et al. (2001) developed a collaborative assembly environment by integrating the STEP format of the product's geometry with a Java3D interface. A Web-based collaborative system called webSPIFF has been developed for feature-based modeling by assuming that the client is able to specify the design parameters in terms of features and their entities (Bidarra et al., 2001). Xue and Xu (2001) developed a Web-based collaborative system for concurrent design. Zhang and Goldberg (2002) developed an Internet-based 2D CAD tool for automated designing of gripper jaws. Other researchers have developed Web-based design systems (Summers et al., 1999; Agrawal et al., 2002) and proposed a distributed service architecture (Han et al., 1999). Even though CAD models can be successfully embedded in a Web document by using VRML or Shockwave Player, they have not been utilized in e-customization because of the difficulty in regenerating the CAD model in a Web document. In this paper it is assumed that the company has already identified parameters and options that will allow the customer to customize the product. In addition, it is also assumed that the customer using the framework is a layman in CAD modeling. This work utilizes current commercial software to accurately generate the 3D model of the product from user specifications. The model is then displayed in a Web browser in VRML format. The research also defines mathematical foundations to convert user-specified information to generate cost and assembly sequence information for the customized product. The cost information is shown to the customer along with the solid model. The assembly information can be used to manufacture the customized product.
In the next section different elements of the proposed information framework are presented in detail. In Section 3, the framework is implemented for customization of a coffeemaker product family. Future work and concluding remarks are presented in the final section.
An information framework is essential in providing Web-based mass customization using product platforms. A general framework is shown in Figure 1 that can be implemented to facilitate information management to provide products manufactured to customer specifications. In general, activities and information flow for mass customized products can be summarized by the following description.
The flow of information in the proposed product family mass-customization framework.
This paper will focus only on the shaded area of the proposed product family mass-customization framework (Fig. 1). The focus will be on generating a product CAD model, cost information, and assembly process information from customer specifications to support Web-based mass customization. Generated CAD models and cost information are provided to the customer to assist in decision making. The structure and assembly information will assist in manufacturing the product.
The product family rule base, PF-CAD module, and providing feedback information to the user are some of the main components required to provide Web-based mass customization when configuration and parametric modifications are considered (Fig. 2). In this section we will provide details related to these components of the information framework.
The prototype system for Web-based product customization.
A product family rule base needs to be created to transform user-specified information into an appropriate function structure, product architecture, and assembly process information. We use constraint-based combinatorics to generate only feasible configurations of the product, instead of generation and then checking feasibility. Because constraints are applied, the combinatorial spaces for feasible configurations are reduced significantly, even for a large number of options (Siddique & Rosen, 2001). The user-specified choices are input to the system, which is used to invoke and generate appropriate information about the product. Transformation of user specifications needs to be performed in such a manner so that the integrity of the information transformed is maintained in both the structure cost and manufacturing. From an engineering perspective, to provide configuration customization, product constraints specifying which components/modules are in the product, relations among these components/modules, and assembly sequence information need to be captured explicitly. One way to ensure this integrity of information is by developing rules and syntaxes, which merge into a grammar, that will generate only meaningful and feasible transformations. In this paper we will utilize the concept of graph grammars to transform/add product functions of a product platform to other relevant and important product and process information.
A graph grammar is a graph rewriting system for a labeled graph. A grammar consists of a set of editing operations or productions (often called production rules) that can be applied to a graph. In this paper, development of three grammars are briefly presented; details of these graph grammars are presented in Siddique and Shao (2001). The first rule of all three grammars represent the common platform for the product family.
Customization of products involve specifying options, size, and other external characteristics of the product. Options are usually specified by addition/deletion of functions from the base product or the common product platform. Products in a family will perform similar tasks; hence, they will have a set of common functions that need to be performed. This set of common functions and relationships among them make the functional core of the product, whereas the optional functions will provide the variety. The common function structure or function structure for the platform can be represented using a graph (Production Rule 1, Fig. 3), and graph grammar can be used to specify interactions among the optional functions and the core (Production Rules 2–5, Fig. 3). From an engineering perspective, Grammar 1 will be used to specify the function structure (Ullman, 1992) for different members of the family from user input.
Grammar 1 for the coffeemaker product family.
Graph grammar 2 is used to transform function to the component viewpoint, maintaining module information, required to develop modular product configurations for the members of the family. The first set of production rules of this graph grammar transforms functions to structure (Production Rules 6–10; Fig. 4) while explicitly capturing module information based on the relation of functions, modules, and components. As an example, Rule 6 transforms the platform functions to a structure viewpoint, the right-hand side of the rule presents the components, and the connections among the components of the platform, whereas other rules (Production Rules 11–14; Fig. 4) explicitly specify the connections among the optional and platform components. As an example, Rule 11 specifies how the components of the Coffee Flow Stopper module are connected to the platform. The vertices of these graphs represent components, and an arc between two vertices represent a connection between the two components.
The structure grammar for the coffeemaker product family.
Grammar 3 is developed to transform the function graph to the assembly viewpoint and explicitly specify the assembly sequence among the components of the family member. The first set of rules in Grammar 3 (Rules 16–19; Fig. 5) transforms function to the assembly viewpoint for platform and optional functions, whereas the second set of rules (Rules 20–23, Fig. 5) specifies the assembly sequence relationship among the different components of the coffeemaker family. In our representation the circular nodes represent components and the triangular nodes represent assembly stations. The assembly sequence starts from the bottom; as an example, the assembly sequence represented by the right-hand side of Rule 15 is “upper body” and “tube carrying water” is assembled first; “condense cover” is then assembled to this subassembly. Applying Grammar 3 rules to the function structure, which is derived by applying Grammar 1 to the input of the user, an assembly sequence for a specific coffeemaker can be obtained.
The assembly grammar for the coffeemaker product family.
Using the grammar rules structure, an assembly sequence for different members of a product family can be generated from the platform, which is the start graph for the grammar. Generation of the members can be divided into two steps.
Step 1. Combine the optional functions with the functional core using specified grammar production rules. Generation of the product family member with all options can be accomplished by applying Grammar 1 rules to add optional functions to the core function structure.
Step 2. Use grammar production rules to transform the functions into the structure/assembly viewpoint for specific coffeemakers. In this step the function structure, obtained from the previous step, is transformed into a structure viewpoint or assembly viewpoint by applying grammar production rules of Grammar 2 or Grammar 3 respectively.
The product family rule base contains these grammar rules and uses them to generate structure, cost, and assembly sequence information from customer preferences. The product family rule base module of the prototype information system (Fig. 2) uses the Internet Information Server (IIS) as the http server. All server-side script is processed by IIS using Active Server Page (ASP) Technology. the database used for the prototype system is MS Access, and Information System accesses the database through Open Database Connector, which makes the Implementation of Information System independent of the database. Using ASP, all server scripts are transformed into HTML before being transmitted to clients. The prototype system is demonstrated by implementation of the coffeemaker product family, which is presented in Section 4.
One of the focuses of this paper is automated generation of CAD models of product family members from customer's requirements, when both scaling and modularity are allowed to provide varieties, and then utilizing the generated model to provide feedback to the user. To develop and specify CAD models of the product family, both platform and options have to be considered. The customization of product family members can be achieved through parameterization or modularity (Zhou & Siddique, 2002). Combining both parametric scaling and configuration design provides full control over the product for customization. In this research both scaling and configuration changes are considered when generating CAD models for members of a product family. To facilitate configuration reasoning the concept of modularity is applied, which is closely related to Grammar 1 (Section 4.1). To support scaling, parametric solid models of components are developed. The architecture of the PF-CAD module is shown in Figure 6.
The system architecture of the PF-CAD module.
Customer specifications, functions, and size parameters, are input to the PF-CAD module (Fig. 6). To automatically generate CAD models of the customized product, an Application Program Interface (API) programming language for CAD software is used. Using API programs, solid models of the components can be generated and assembled using capabilities of existing CAD systems. Product family templates are used to specify different relationships among components and modules to generate the CAD model.
At this point a PF-CAD module that interacts with Pro/E to generate solid models of product family members from a set of user input has been implemented. Details of the PF-CAD module for Pro/E are presented next.
Users can generate members of the product family by adding options to the platform from the range of available options determined by using the market segmentation grid and specified by the product rules. The user can also specify the size of the product through several dimensions.
Pro/Toolkit is the application program interface, which provides functions to be called by external programs. The C programming language is used to implement component and assembly creation.
The product family template is used to describe platform and options, modules inside the family, and components of every module. Assembly relations are also included in this template. Utilizing the template, designers have an overall view of the product family, which includes detailed parametric information. The general product family template is shown in Table 1.
Product family CAD template
In the product family template PF stands for product family and Pi is a member of the PF, which depends on the allowable combinations of the options with the platform. The elements of Pi include product platform (PP), product options (POs), and assembly constraints (AssemCon). It means a member of product family should embrace the PP and utilize PO to provide the variety and AssemCon to specify spatial relationships among them. In the template it is assumed that the PP is not a null or empty set. To provide varieties across the product family the PO set cannot be empty either. The AssemCon is the assembly constraint set. It includes the assembly method, such as mating assembly, orient assembly, aligning axes, aligning coordinate systems, and so forth, and assembly references, which correspond to the assembly methods. As an example, if the aligning axes method is utilized, assembly references should be two axes. Assembly of the components is performed at two levels: the first level involves assembling components that constitute modules. In this level, Option Components (CPO) are assembled together to get PO. Platform Components are assembled together to get PP. At the second level the modules (PO and PP) are assembled to generate the family members. The assembly method utilized depends on the capability of the CAD system. Mating relationships, coordinate systems, orientation, axis, and so forth, can be used. In a CAD system, assembly constraints are usually represented between two components. Because we will be using commercial CAD software to generate the solid models, the product family template represents assembly constraints to match CAD system input. As for PP and PO, they are the set of modules with component geometry, assembly relationships, and other information. Thus, inside the PP or POs, there are components and component-related characteristics, which include geometric, hierarchy, and parametric information.
Using Grammar 1 and Grammar 2, feasible combination of modules and components can be defined. This information is then be used by the product family. The CAD template is used to determine the size and shape of component geometry, and spatial relationships among components and modules of the customized product.
After running application programs, objects are automatically created using the capabilities of Pro/E.
In this paper, Pro/E's API was utilized to implement the PF-CAD module. In Pro/Engineer, any entity is a feature, for example, a section, an extrusion, a hole, a datum plane, a coordinate system, and so forth. For any feature, there is a feature tree in Pro/Engineer to represent this feature. In this feature tree, design information (including parametric information) is specified. These feature tree elements need to be instantiated to generate models from user specifications. The instantiation of the features is achieved using Pro/E APIs, C programming language, and running the program in Pro/Engineer.
The overall process of how a customer can select the provided options and view the results is shown in Figure 7. Server side scripting does the coordination to manage the work through different modules. A script containing Pro/Web.Link has been utilized to link the World Wide Web to Pro/Engineer. Pro/Web.Link allows building of custom Web-based applications that interact with Pro/Engineer through a Web browser. The Pro/Toolkit application that has been employed here does not need the client machine to have Pro/Engineer installed on it to view a solid model of the coffeemaker product family members. To execute this process it is enough if the server has Pro/Engineer installed on it. The Web-based framework, presented in this paper, invokes the Pro/Engineer application on the server to run and the generated CAD model of the coffeemaker product family is sent back to the client, which can be viewed in any browser by a VRML plug in. The customer specifications are also sent to the product family rule base to estimate the price of the product and to generate assembly sequence information, which is also shown to the user.
Automatic generation of CAD, cost, and assembly sequence information for customized products.
To illustrate some of the concepts related to generation of CAD models for a product family, a coffeemaker product family has been chosen. The functional breakdown of all coffeemakers is essentially the same.
These functions of the coffeemaker are common. Functions such as stopping the flow of coffee when the pot is empty, controlling coffee concentration, and so forth, are optional and are added to the platform to increase functionality and provide variety. The coffeemaker example presented in this section focuses on implementation of grammars (Section 3.1), solid modeling information of the coffeemaker family (Section 3.2), provision of geometrical and cost feedback to the user (Section 3.3), and customer interaction with the framework to generate customized the coffeemaker models and associated information (Section 4.4).
To implement the graph grammar for the coffeemaker family, first information representation for function, components, and assembly sequence needs to be specified, followed by representation of the grammar rules. Representation of the module, structure, and assembly information for the coffeemaker product family is presented in Figure 8.
The (a) module, (b) component, and (c) assembly tables.
The module information of Grammar 1 (Fig. 3) is represented in Figure 8a. Every module is described by three descriptors:
The component information is represented in Figure 8b. Every component is described by four descriptors: id and name record the identification number and the name of the component; module_id and group_id represent the module and group owning this component respectively. From the representation of the assembly process (Fig. 5) it can be observed that every component (represented by dots) is owned by one group (group is represented by the triangle). Every triangle is given a name, an identification number and an assembly sequence. This representation is presented in Figure 8c, which is derived from Grammar 3 (Fig. 5) of the coffeemaker. In Figure 8c, id represents the id of group; sequence represents the assembly sequence. To represent the tree relationships of the captured in Graph Grammar 3, sub_gid_count and sub_gid_X are provided. The descriptor of sub_gid_count records the number owned by one group and sub_gid_X records the id of the Xth child group node. Based on the information represented by above tables (Fig. 8), the graph grammar rules are implemented using VBScript in the server side.
A coffeemaker product family template was generated and implemented to represent geometry and spatial relationships among the different components and modules of the coffeemaker product family. The five modules in the coffeemaker product family are coffeemaker platform, concentration adjusting module, drip protection module, water level indicator and programmable module. Components for the coffeemaker product family is shown in Figure 9. Some of the components in the coffeemaker platform are upper body, lower body, upper cover, lower cover, tubes #1 and #2 carrying steam, tube carrying water, aluminum tube and heater, base heating plate, power switch, and wire. The concentration adjusting module consists of a knob that can be rotated to control the entrance area of vapor so the concentration of coffee can vary. The drip protection module has a small component, knob protecting flow, which has the following characteristics: when the coffee mug is not placed on the warming plate, it closes the outlet of the coffee filter cup to prevent dripping; when the coffee mug is on the warming plate, the outlet is opened to let hot coffee drip down to the coffee mug. The programmable module can automatically turn off the power if the heating time exceeds a preset value. The programmable module contains a PCB and some electrical wires. After determining components for all modules in the coffeemaker product family, varieties generated by changing the configurations are implemented. At the same time, parametric varieties are considered in generating CAD models. The objective of the parametric scaling is to satisfy the market segmentation for different size coffeemakers. The differentiating factor for the size of the coffeemaker, the size of the cup, can be related to the water storage. Because the upper body stores the water, the parametric variables of a coffeemaker should be based on upper body dimensions. As for the three optional modules, they can change with the scaling of uppercase, but they could have the same geometry and still implement the functions. Parametric relations among the different components of the coffeemaker exist for proper scaling to provide the appropriate size specified by the customer.
The coffeemaker platform parts.
There are several options for assembling using capabilities of Pro/Engineer, such as mate, align, orient, coordinate system, and so forth. For this example we choose “assembly by coordinate system” to assemble the components (Fig. 10). Assembly relationships among the coffeemaker product family are implemented using the template approach. With the implementation of the coffeemaker family template, the CAD models of the different members of the coffeemaker product family can be generated automatically, depending on the options and different parameters. The PF-CAD module utilizes user-specified option and size information to scale and assemble appropriate options to the coffeemaker.
The assembly relationships among coffeemaker components.
To display the generated CAD model to the customer, the final generated coffeemaker assembly from the PF-CAD module was exported in VRML from Pro/E. To perform this task automatically, a Make File was designed and executed to create a new executable Pro/Toolkit application file. Pro/Web.Link uses JavaScript to interact with Pro/Engineer. However, because JavaScript is a client side script, it tries to access the Pro/Engineer on the client machine with the Pro/Web.Link functions. Hence, the Web-based applications developed by using Pro/Web.Link would work if, and only if, the client machine has Pro/Engineer installed on it. To avoid this problem, a server side object was used to call the executable file of the browser from an ASP page on the server, and was given an HTML page as the parameter to open on the server, which contains the Pro/Web.Link functions by using JavaScript. Because the Web page containing the Pro/Web.Link functions is opened on the server, the JavaScript tries to invoke the Pro/Engineer on the server, and if the server has Pro/Engineer installed on it, the Pro/Toolkit application would execute successfully, resulting in the export of the coffeemaker product family in VRML format. As a result, it is enough if the server has Pro/Engineer installed on it to execute the proposed framework. As the final output sent back is only a VRML file, the client is just expected to have a VRML plug in to view the customized coffee maker family 3D model.
To generate the Web-supported CAD model for the customized coffeemaker (Fig. 11), the customer specifications are passed as design parameters or arguments to the Pro/E application for automatic execution. The step by step process of execution of the Pro/Toolkit application file is shown in Figure 7, where Pro/Engineer is invoked and the application is executed by the JavaScript on the server, which in turn, was invoked by the server side object through the ASP page. The 3D model that is exported as a VRML file is finally sent back to the client, which can be viewed in any standard browser as shown in Figure 11a. Different coffeemakers with different options and sizes are shown in Figure 12.
The information output for a customized coffeemaker with all options: (a) VRML model of the coffeemaker, (b) cost of components, and (c) assembly sequence.
Coffeemaker solid models with different options: (a) drip protector, (b) coffee concentration controller, and (c) digital controller.
Let us assume that a customer wants to order a coffeemaker with all options with specific dimensions in mind for the overall size. To place the order the customer first opens the coffeemaker product family Web page (Fig. 7), selects all options (Drip Protector, Concentration Adjustor, and Auto Shutdown) that are shown in the coffeemaker customization Web site, and then enters the length, height, and width for the coffeemaker.
These user-specified options are then transmitted to the rule base and the CAD template. To generate the structure, cost, and assembly information for the customized coffeemaker, grammar rules are applied. In this case, the coffeemaker with all options, Rules 1–5 of Grammar 1 are applied to generate the complete function structure of the customized coffeemaker. Grammar Rules 6–14 (Figs. 4, 8) are then applied on the generated function structure to convert it to coffeemaker structure information. The same process is applied for Grammar 3 (Figs. 5, 8) to generate the assembly process. The cost of the coffeemaker is generated using the price of the components. This generated cost information is then shown to the customer (Fig. 11b), whereas the assembly information (Fig. 11c) will assist in manufacturing the product.
The coffeemaker product family template is used with customer specified options (in this case all options) and parameters to first generate the appropriate size of the platform (Fig. 9) and optional components. In the next stage these components are assembled using the template. All assembly relationships for the coffeemaker with all options is pictorially represented in Figure 10. Once the coffeemaker is assembled it is exported into VRML format and shown to the customer (Fig. 11a).
In this paper we presented a Web-based mass customization information framework where customer specifications and size parameters are gathered by a simple form-based Web page and are passed as design parameters to the CAD tool for executing the product family application on the server to generate the 3D models of the product family members, estimate the cost for producing the customized product, and generate the assembly sequence for manufacturing. A coffeemaker product family case was studied and implemented to support the proposed framework by using various Application Programming Interfaces of CAD and Web-related tools. The presented system differs from current Web-based customization approaches by generating actual CAD models from customer specifications and showing it to the user in real time, instead of using a catalog approach and then modifying only the outside appearances of the product. The framework will allow companies to enhance interaction with their customers during customization of the product by providing a complete model of the product. The complete solid model of the product can increase customer confidence and educate the customer about the product they are ordering, which will increase customer satisfaction.
The proposed framework can be applied to other product families to allow Web-based customization with better integration of the customer. One of the limitations of this framework is the time consumption of the CAD Tool on the server for executing the Product Family application. The customer has to wait until the application on the server executes completely. Our future research will be focused on sending step by step 3D models of the products during the process of generating the product family members, which would give dynamic presentation of the product family generation to the customer. We will also concentrate on executing finite element analysis and other analyses on the server to determine the feasibility and performance of the customer-preferred product.
A set V of vertices and a set E of edges such that all the end points of edges in E are contained in V, denoted G = (V, E).
A subgraph of a graph G = (VG, EG) is a graph H = (VH, EH) whose vertex set and edge set are subsets of VG and EG, respectively, such that for each edge e in EH, the end points of e (as they occur in G) are in VH.
This graph is one in which each pair of vertices is joined by a path.
A tree is a connected graph with no cycles. It is denoted by T = (V, E, p), where p is the parent function that maps a vertex to its parent.
Ehrig (1978) formally defines a graph grammar (GG); it is expressed as a 4-tuple:
where [sum ]V is the alphabet of vertex labels, [sum ]E is the alphabet of edge labels, R is the set of graph productions, and S is the start graph.
Each production (or production rule) of a GG is defined as the triple (GL, GR, T), where graphs GL and GR are the left-hand side and right-hand side, respectively, and T is the embedding function. A production of GG is applied to G to change the structure of G. This is done by locating an isomorph of GL in G, removing GL from G, replacing GL with GR, and embedding it to G using T.
The flow of information in the proposed product family mass-customization framework.
The prototype system for Web-based product customization.
Grammar 1 for the coffeemaker product family.
The structure grammar for the coffeemaker product family.
The assembly grammar for the coffeemaker product family.
The system architecture of the PF-CAD module.
Product family CAD template
Automatic generation of CAD, cost, and assembly sequence information for customized products.
The (a) module, (b) component, and (c) assembly tables.
The coffeemaker platform parts.
The assembly relationships among coffeemaker components.
The information output for a customized coffeemaker with all options: (a) VRML model of the coffeemaker, (b) cost of components, and (c) assembly sequence.
Coffeemaker solid models with different options: (a) drip protector, (b) coffee concentration controller, and (c) digital controller.