This Provisional PDF corresponds to the article as it appeared upon acceptance. Fully formatted PDF and full text (HTML) versions will be made available soon. Lifecycle scenario design for product end-of-life strategy Journal of Remanufacturing 2012, 2:1 doi:10.1186/2210-4690-2-1 Shinichi Fukushige (fukushige@mech.eng.osaka-u.ac.jp) Kazuhiro Yamamoto (yamamoto@lce.mech.eng.osaka-u.ac.jp) Yasushi Umeda (umeda@mech.eng.osaka-u.ac.jp) ISSN 2210-4690 Article type Research Submission date 16 January 2011 Acceptance date 17 January 2012 Publication date 17 January 2012 Article URL http://www.journalofremanufacturing.com/content/2/1/1 This peer-reviewed article was published immediately upon acceptance. It can be downloaded, printed and distributed freely for any purposes (see copyright notice below). For information about publishing your research in Journal of Remanufacturing go to http://www.journalofremanufacturing.com/authors/instructions/ For information about other SpringerOpen publications go to http://www.springeropen.com Journal of Remanufacturing © 2012 Fukushige et al. ; licensee Springer. This is an open access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. 1 Lifecycle scenario design for product end-of-life strategy Shinichi Fukushige, Kazuhiro Yamamoto and Yasushi Umeda Graduate School of Engineering, Osaka University, Osaka, Japan Abstract This paper proposes a method for supporting the design of product lifecycles. The main approach involves supporting designers in determining a lifecycle strategy by describing lifecycle scenarios at an early stage of lifecycle design. The authors define a representational scheme for the lifecycle scenario and outline a support system based on the idea of the Cognitive Design Process model allowing the designers to examine various possibilities of lifecycle strategy. A number of alternative scenarios are managed by the Truth Maintenance System implemented in this approach. Finally, in order to embody the strategy in the later stages, the system derives requirements for product and process design. This paper outlines the lifecycle scenario of a cellular phone as a case study, which indicates the system’s suitability for computer-aided description of scenarios and its facilitation of lifecycle strategy development. Keywords: lifecycle design, end-of-life strategy, lifecycle scenario 1 Introduction Promising approaches for sustainable development involve the construction of stable product lifecycle systems that drastically reduce environmental loads, resource consumption and waste generation while increasing living standards and corporate profits. The design of a product lifecycle includes the steps of modeling the lifecycle itself, evaluating it from various viewpoints, and pinpointing solutions to optimize the lifecycle as a whole [1]. We previously proposed the lifecycle design process [2] shown in Figure 1. First, designers analyze the current state of the product and its market, and determine the product concept, business strategies and environmental targets based on the results of this analysis. Second, the designers formulate a lifecycle strategy according to the product concept, business strategy and environmental targets. Third, the designers design the product and its various lifecycle processes in line with the strategy. Finally, the designers evaluate the whole lifecycle of the product to confirm the feasibility of the strategy. In short, the lifecycle strategy is planned from the early stages, and the product is designed to realize the strategy. To support the strategy planning stage, this paper proposes a method of describing product lifecycle scenarios by which designers can explicitly determine lifecycle strategies. Here, the lifecycle strategy is defined as a combination of lifecycle options (e.g., maintenance, product reuse, component reuse, closed-loop recycling and cascade recycling) for a product and its components, and the lifecycle scenario is a description of the expected product lifecycle. In other words, by describing the lifecycle scenario, designers can easily identify appropriate lifecycle options and requirements for product and process design in the later stages of lifecycle design. Some studies have focused on support for lifecycle strategy planning. Kobayashi [3] proposed a lifecycle planning methodology that supports lifecycle option selection on the part level through analysis based on QFD [4] and lifecycle assessment [5]. Kwak et al. proposed a method of evaluating end-of-life recovery profit by considering both product design and recovery network design [6]. Phang et al. proposed a design method that includes end-of-life strategy design by evaluating the product lifecycle in Distributed Object-oriented Modeling and Environment (DOME) [7]. Rao et al. proposed an end-of-life scenario selection method to optimize multiple parameters related to a product lifecycle by utilizing a directed graph [8]. Rose et al. outlined an approach for determining appropriate end-of-life strategies based on product characteristics such as a product’s life span and the rate of technological innovation in products [9]. Ostlin et al. proposed the inclusion of product lifecycle consideration in remanufacturing strategies [10]. As these methods mainly focus on the selection of optimal processes and parameters from the specific aspect of product lifecycle, they are not ideal for examining and comparing various lifecycle possibilities from different viewpoints. Product lifecycle management (PLM) is a challenging issue in this research field [11, 12]. As a recent example, Alemanni et al. introduced model-based definition (MBD) [13] into PLM. With MBD, most product lifecycle data are structured inside CAD models rather than being scattered in different forms throughout the 2 PLM database. Although such product lifecycle data management and integration methods help to eliminate redundant documentation and increase product data accessibility, they do not focus on support for lifecycle design. In other words, PLM systems do not provide product lifecycle models that enable explicit design. A number of studies have also addressed environmentally conscious product design technologies; examples include design for recycling [14, 15], remanufacturing/reuse [16, 17, 18], maintenance [19, 20] and ease of disassembly [21, 22]. In this area, modular design methods have been studied for ease of manufacture and assembly [23]. Modular design is also useful in enabling all lifecycle options such as remanufacturing, maintenance, reuse and recycling (e.g., [24]). By way of example, Duflou et al. [25] pointed out that modular design is an indispensable critical driver in the remanufacture of single-use cameras. However, the relationships and trade-offs between these design methods have not been clarified, and no design environment integrates these eco-design technologies based on end-of-life strategies. Support for decision making in this area is also needed. Design methodologies for product service systems have also been eagerly studied [26, 27]. From the viewpoint of lifecycle design, servicizing is a strong enabler of lifecycle strategies, and describing lifecycle scenarios is also useful in setting targets for servicization. However, no computational representation of lifecycle scenarios has yet been established, meaning that there is no computational support tool for describing lifecycle scenarios including product service system. The objectives of this study are to propose a scheme for representing the lifecycle scenario and its description process and to develop a description/management support system for examining various lifecycle strategy possibilities and clarifying requirements for product and process design. One of the main contributions of the study is its definition of scenarios as computational lifecycle models that enable the design, visualization and evaluation of the whole product lifecycle. 2 Requirements for the lifecycle scenario design system As outlined above, environmentally conscious product design should be executed after an appropriate lifecycle strategy has been planned, and describing lifecycle scenarios is a promising approach to clarifying such a strategy. In determining a lifecycle strategy, designers should consider the business plan, environmental targets to be met, and the product concept to provide value to customers. To support such design, we sought to formulate a workspace that will allow designers to examine various scenarios using a description support system. To this end, we identified five requirements for the system: 1． Support for the description and examination of various plausible lifecycle scenarios: As environmental issues are typically poorly structured problems that require lifecycle consideration from various viewpoints, the system should support designers in examining various plausible scenarios. To this end, Sections 3 and 4 propose a representational scheme for scenarios and the related description process. 2． Clarification of requirements for product and process design: To embody the lifecycle strategy in the later stages of lifecycle design, the requirements for product and process design need to be clarified. This requirement is met in the representational scheme through the product structure model, lifecycle flow model and the process parameters detailed in Section 3. 3． Explicit representation of the design rationale throughout the scenario description process: The lack of general criteria for environmentally friendly products means that manufacturers must declare why a product is promoted as having environmental merits. One way of doing this is to express the rationale of decisions made by the designers during lifecycle design. Accordingly, the reasons behind the designers’ decisions are recorded to clarify the design rationale, which is represented using the cognitive design process model [28] described in Section 4.1. Moreover, as previously discussed in relation to research on design rationale (e.g., [29]), this approach is useful for reusing design knowledge. 4． Management of alternatives: At each step in the scenario description process, the designers generate and choose alternatives. To support the design process, the system should therefore be capable of appropriately managing these design alternatives. This management method is outlined in Section 4.2. 5． Integration of results from lifecycle design support tools: The scenario description support system should not be closed. Rather, it assumes that the designers generate alternatives and make decisions using 3 various lifecycle design support tools. Examples include evaluation methods based on lifecycle cost [30, 31], lifecycle option selection support tools (e.g., Disposal Cause Analysis [32] and the product lifetime prediction method [33]), lifecycle assessment (LCA) [5] and lifecycle simulation (LCS) [34, 35]. Accordingly, the system should be able to import the results of these external support tools. 3 Lifecycle scenario representation A lifecycle scenario represents all the scenes of a product lifecycle in terms of 5W1H expression (who, where, what, why, when and how). In this paper, the lifecycle scenario definition is based on the following five elements: 1． Lifecycle objective: Declaring the objective of the lifecycle is important in clarifying the targets and criteria for scenario evaluation. Here, the objective is represented in verbal form and by target parameter values. An example would be the objective statement ‘To keep the manufacturer in profit and to halve CO 2 emissions’ combined with the parameter values of ‘profit: more than 100%’ and ‘CO 2 emissions: reduction exceeding 50%.’ 2． Lifecycle concept: Our preliminary study showed that it was difficult for designers to directly formulate a lifecycle scenario based on lifecycle objectives alone. Accordingly, we introduced the lifecycle concept, which indicates the basic direction for the construction of a scenario (such as extending product life or increasing the efficiency of recycling) as a bridge between the objective and the selection of lifecycle options. 3． Lifecycle options: The lifecycle options of a product and its components determine the basic structure of scenarios. In order to manage combinations of lifecycle options and product components, product structure model is introduced as shown in Figure 2. In this model, each node represents a product’s component and is related to its applied lifecycle option. For example, ‘To be reused in the first life, then recycled in the second life’ might be used to describe the lifecycle options of a component, and the combination of options is related to the corresponding node of the product structure model. 4． Lifecycle flow: This is the central model of the lifecycle scenario, and represents the flow of products, components, materials, information and money in the form of a lifecycle process network. Each lifecycle process of the flow model has the inputs and outputs of the process (such as the income and expenditure of the process stakeholder) to allow lifecycle evaluation from environmental and economic viewpoints using the LCS. Figure 3 shows an example of lifecycle flow, where component A is reused and component B is recycled. It is also related to the product structure model, as shown in Figure 4. The system manages the relationship between the component nodes of a product structure model and the process nodes of a lifecycle flow model. As a result, a flow model clarifies the requirements for the later stages of lifecycle design. 5． Situation: Each lifecycle process is described as a ‘situation’ using 5W1H expression. The design requirements for situations are also described, and the ‘How’ part is represented in UML (Unified Modeling Language) [36] for formalization. 4 Scenario design process 4.1 Representation of design rationale To represent the designer’s decisions explicitly, this paper outlines the scenario description process through extension of the cognitive design process model [28]. As shown in Figure 5, all information provided by the designer is classified into the three categories of design reasons, solution candidates and selected solutions. The nodes are related to each other by positive, negative or antinomy causality links. The design reason node includes the four subtypes of fact, assumption, result from an external tool (denoting an evaluation result obtained from an external tool as described in Section 2) and requirement, which represents a design aspect required for realization of the lifecycle scenario. The candidate nodes and solution nodes have links to the scenario elements described in Section 3, and the design reason nodes have detailed descriptions or links to references and external tools. The description process here assumes that the designer identifies problems to be solved (such as the 4 selection of plausible lifecycle options) at each step of the process (the horizontal gray line in Figure 5), then proposes solution candidates and gives design reasons for them. These reasons are derived from the designer’s knowledge, references and results from external tools, and are related to the candidate nodes by positive or negative causality links. Next, the designer evaluates the candidates, which also results in positive or negative links from the design reason nodes. Design reason nodes and solution candidate nodes have either a valid or an invalid state. The state is changed to invalid by negative causality links, and thus invalidated nodes cannot affect other nodes. In Figure 5, the invalidated nodes are greyed out. The designer selects one or more solutions from among the valid candidate nodes, and the selected candidates are changed to selected solution nodes. The designer cannot select two nodes connected by antinomy link. Based on the selected solutions, the designer also proposes solution candidates at the next step and chooses solutions from among them. The nodes are connected by causality links from the previous step’s nodes. As a result of these processes, the design rationale of the scenario is represented as a network of these alternative nodes. Having the designer construct this network provides a record of the thought processes and grounds on which the design is based. 4.2 Management of alternatives As designers need to examine various tradeoffs in describing a lifecycle scenario as detailed in Section 2, it is necessary to manage various alternatives (solution candidates) at each step of the process. To examine the various possibilities involved, the designer switches the selected solutions among the candidate nodes as shown in Figure 6. Such alternatives are associated with the alternatives of the former and later steps in the design rationale network. In this study, node relationship management was based on the Truth Maintenance System (TMS) [37], which is a knowledge representation and management method for maintaining both knowledge (propositions) and dependencies (Boolean constraints). In other words, it maintains logical consistency between current knowledge and old knowledge in a knowledge network through revision. Each node in the TMS network has the state of In or Out, representing the validity or invalidity of the knowledge in a certain context. In this research, we employed a simple justification-based TMS mechanism to manage all design alternatives. This maintains consistency among the solutions, candidates and design reasons in the design rationale network defined in Section 4.1. In the context of decision support systems for engineering design, gIBIS (graphical Issue-Based Information System) [38] is used to represent dependencies among problems and alternatives by creating a tree structure as an argumentation model. Schemebuilder [39] and DRIFT (Design Rationale Integration Framework of Three layers) [40] also enable the management of a wide range of engineering design alternatives using the TMS for computer-aided knowledge-based design. Our system mainly focuses on the construction of lifecycle models, and provides a framework that integrates the lifecycle design support tools described in Section 2. In accordance with the manual construction and revision of the design rationale network, a TMS structure is created and updated automatically in the background. Figure 7 shows a TMS structure corresponding to a design rationale network. Network consistency is maintained by revising the state of the nodes in the logical structure. In other words, the valid/invalid state of the nodes in this network corresponds to the In/Out state of the nodes in the TMS structure. For example, the state of a node becomes Out when the node is supported by In-state nodes via negative links. This structure further introduces the two node types of selection and contradiction. A selection node represents a designer’s selection or rejection from among the solution candidate nodes, while a contradiction node corresponds to an antinomy link and disables the simultaneous selection of two nodes connected by such a link. When the state is changed or a new node is added, the TMS mechanism backtracks through the causality connections, and if a contradiction is found, the node responsible is identified and changed to an appropriate state. As a result, a variety of alternatives can be managed effectively. 4.3 Process of lifecycle scenario description Here we propose a process for lifecycle scenario description. First, the designer analyses and describes the 5 product’s characteristics and related market information in a workspace in the form of design reason nodes. Next, the designer step-wisely describes a lifecycle scenario from the lifecycle objectives to the lifecycle situations defined in Section 3. At each step, the designer describes the scenario with design reason nodes and solution candidate nodes in the design rationale network, and may use external tools to validate or invalidate the nodes via positive or negative causality links. In such cases, results from external tools are represented as such in design reason nodes. For example, the suitability of material recycling may be evaluated using a tool such as the Lifecycle Planner [3]. The proposed method places focus on providing the designer with a workspace for examining various scenario alternatives by incorporating a range of external tools. In this method, it is assumed that the designer evaluates the scenario using external tools after the lifecycle flow has been constructed. Here, we employ lifecycle simulation, which enables lifecycle evaluation in terms of environmental loads, material balance and monetary benefits. As the main simulation model for the lifecycle simulator involves the lifecycle flow defined in Section 3, the scenario can be evaluated directly and interactively after flow model creation. The designer should specify situations for the simulation in each process of the lifecycle flow. The designer repeats this cycle until all lifecycle objectives are achieved. If no such solution is found, the designer reviews the design of the scenario and its conditions (i.e., the lifecycle concepts, options, flow and related process parameters). Lifecycle objectives can also be targets of revision. Finally, the designer extracts the requirements and conditions from the requirement nodes in the design rationale network and the process parameters in the lifecycle flow for product and process design in the later stages. 5 Prototype system We developed a prototype system based on the proposed method (see Figure 8 for an outline of the system architecture). The designers describe a lifecycle scenario using the individual sub-tools provided (objective description tool, lifecycle concept description tool, lifecycle option selection tool, lifecycle flow modeler, process situation modeler and product structure modeler), and the lifecycle scenario manager integrates these sub-tools. The design rationale manager provides a workspace for constructing a design rationale network, and the alternative manager maintains the consistency of the network using TMS as described in Section 4. There are also two databases to support the construction of lifecycle flow and product structure model. Figure 9 shows a screenshot of the workspace in which the individual scenario components (lifecycle objective, concepts, options, flow, process details and product structure) are edited. These components are linked to the corresponding nodes of the design rationale network and the relationship of the components is managed in the network. The lifecycle flow model is further related to the product structure model as described in Section 3. In other words, the system integrates the two models to enable visualization and management of which product’s parts pass through which processes of the flow model. Figure 10 shows an example of the parameters of a process in a flow model. Each process has given parameters, input parameters, output parameters and procedures. Some input parameters are imported from a product structure model that holds information on the attributes of the product’s components, such as its constituent materials, weight, volume and lifetime. 6 Case study 6.1 Describing a lifecycle scenario for a cell phone Here we describe a lifecycle scenario for a cell phone using the prototype system as a case study. The phone consists of a printed circuit board (PCB), a CCD camera unit, a vibrator, a speaker unit, a battery, cases, a microphone unit and a liquid crystal display (LCD) unit. First, we analyzed the current lifecycle of the phone and constructed a lifecycle flow model to enable assessment of its environmental loads and profit through lifecycle simulation. Based on the results of this analysis, we described the product’s characteristics and market information in the design reason nodes of the workspace. In addition to these fact nodes, we also included assumption node notes such as ‘Higher-level CO 2 reduction will be required to comply with new regulations this year.’ Based on the design reasons, we set the lifecycle objective as ‘to reduce CO 2 emissions without reducing current profit,’ and, as a parameter value for the objective, the manufacturer’s profit was set as ‘more than 100% of that of the current lifecycle.’ Here, in 6 order to examine several possibilities for achieving the objective, two CO 2 reduction rates of 20% and 10% were set, and the 20% rate was selected first. These two candidates were connected with a contradictory link to avoid selection of both nodes as a conclusion. Second, we determined the lifecycle concepts. Here, we derived the four concepts of long life, reuse business, waste reduction and the current recycling scenario as solution candidates. From among these candidates, reuse business was selected as a solution for the lifecycle concept based on the facts and assumptions described in the workspace. Third, we selected lifecycle options. For the LCD, for example, we examined reuse, cascade material recycling and appropriate disposal options as alternatives. From among them, we selected the reuse option in consideration of longer physical life for the LCD in line with the results of the Disposal Cause Analysis external tool [32]. However, according to the market analysis performed in the first step, the size and function of LCDs vary by cell phone type, making stable reuse difficult. This negated the reuse option, and cascade material recycling was therefore selected as the alternative lifecycle option for the LCD. Disposal Cause Analysis also positively supported the reuse option for the speaker, the vibrator and the CCD camera, but negated the reuse option for the battery and the case because of their short lives. As a result, the speaker was set to be reused in the first life and then cascade-recycled in the second life. Figure 11 partially depicts the design rationale network for the case described in the workspace. Fourth, we evaluated this scenario (Scenario A) based on lifecycle simulation. The lifecycle flow model constructed in the first step was revised for adaptation to the described scenario. The results of the evaluation indicated that, while the profit satisfies the objective value of more than 100%, the reduction of CO 2 emissions does not fulfill either of the objectives as shown in Table 1. Furthermore, the reuse option for the speaker and the CCD camera is not feasible due to the lack second-hand markets for such parts. To solve this problem, we modified the scenario to create Scenario B, in which the reuse option is selected for the LCD and PCB instead of the cascade material recycling option because the lifecycle simulation revealed that these components have higher CO 2 reduction potential in the manufacturing process. However, as noted in the design reasons, the functional diversity and frequent restyling of such parts eliminate the potential for their stable reuse. To address this contradiction, we added the lifecycle concept of remanufacturing (in which cell phones are restored to as-new condition through repair or replacement of cases and butteries) and changed the lifecycle flow. As remanufactured phones are not fully equivalent to original new products, we set their price and market size to 60% and 30% of those of a brand-new product, respectively. These rates were taken as suppositions for trial calculation of profit. Additionally, Scenario B involves an attempt to improve the collection rate of old cell phones to 80% by providing customers with a data-backup service and a trade-in service in the new business flow, which was noted in the form of additional requirement nodes in the design rationale network. This network for Scenario B is partially depicted in Figure 12, which shows the change in selected lifecycle options and the additional requirement nodes (in yellow). These amendments remove the obstacles to remanufacturing concept. Figure 13 shows the lifecycle flow of this remanufacturing-oriented scenario. Table 1 compares the results of the lifecycle simulation for Scenarios A and B. As Scenario B satisfies all the objectives, we chose it as the final scenario and completed the scenario description process. Table 2 summarizes the design requirements identified from this process extracted from the requirement nodes in the design rationale network and the process parameters in the lifecycle flow model. 6.2 Characteristics of the method: description of the scenario review process The design rationale network constructed in the case study had more than 50 nodes, allowing the system developed to be used for the management of a number of alternatives by structuring them into a single network. These nodes corresponded to a wide range of scenario components including lifecycle objectives, concepts, options, flows and situations. The mutual connection of these components through causality links facilitates identification of the design reasons on which the selection of alternatives in the scenario was based. It was also possible to trace the origins (such as objectives, concepts and options) from which the lifecycle strategy was derived. The variations in the lifecycle flow model were recorded in individual nodes, and their revisions could be compared easily. The flow model and its constituent processes were utilized to compose a simulation model with which the lifecycle simulator calculated the profit of the manufacturer and the CO 2 7 emissions for all processes in the lifecycle. Table 3 shows some of the process parameters used in the simulation model. In the case study, we set the price and market size of the remanufactured phone, and these values were used as suppositions for the calculation of profit in the simulation. Such relationships between suppositions and calculation results in the design rationale network served as records of trials for examining various lifecycle scenario possibilities. It is a characteristic of the system that evaluation results from external tools are recorded and related to condition values for evaluation in each design reason node. Although Scenario B satisfied the all objectives, this result was based on the supposition values described in the design reason nodes and the process parameters. Accordingly, if it is found that one of these values will be impossible to implement at a later stage, the designer should return to the scenario design process and review/simulate the scenario again with another supposition. 7 Summary and conclusions The case study showed that lifecycle scenarios can be successfully represented using the representational scheme outlined in this paper, and that the proposed method supports the description process. As a result, it is confirmed that a designer can easily determine a lifecycle strategy by describing the lifecycle scenario, and can derive design requirements for the later processes of lifecycle design. Section 2 identified five requirements for the system, and requirements 1 and 2 are achieved by the proposed representational scheme. We also proposed a process for breaking down a lifecycle scenario from lifecycle objectives to a lifecycle situation that can be assessed with Lifecycle Simulation. This allows designers to systematically detail plausible lifecycle strategies that satisfy the objectives by clarifying facts, assumptions, solution candidates, decisions and design requirements. In terms of requirement 3, the case study verified that the system can be used to appropriately record the scenario description process to represent the design rationale. As discussed in Section 2, reusing the design knowledge described in the design rationale network is a challenging issue. The DRed (Design Rationale Editor) system [41] is an option for reconstructing such raw data to create design documents that explain the thought process. For requirement 4 (management of alternatives), we developed a method of recording alternatives at each step with maintenance of logical consistency using the TMS and successfully supported the management of tradeoffs among several alternatives. For requirement 5 (integration with external tools), the system can be connected to external tools and import their results into the external tool’s result node. Future work will include the proposal of a reutilization mechanism for design rationale described in the proposed method and integration with 3D-CAD system to effectively link lifecycle scenarios with product design. 8 Competing interests The authors declare that they have no competing interests. 9 Authors contributions The work presented here was carried out in collaboration between all authors. Y.U defined the research theme and designed the scenario description method for end-of-life strategic planning. S.F co-designed the method and case study, interpreted the result of the case study, and wrote the paper. K.Y developed the scenario description support system, carried out the case study, and analyzed the data. All authors have contributed to, seen and approved the manuscript. 8 References [1] Alting, L., Jorgensen, J., “The Life Cycle Concept as a Basis for Sustainable Industrial Production,” Annals of the CIRP, Vol. 42, No. 1, pp. 163 – 166, 1993. [2] Fukushige, S., Inoue, Y., Tonoike, K., Umeda, Y., “Design Methodology for Modularity Based on Life Cycle Scenario,” International Journal of Automation Technology, Vol. 3, No. 1, pp. 40 – 48, 2009. [3] Kobayashi, H., “Strategic Evolution of Ecoproducts: a Product Life Cycle Planning Methodology,” Research in Engineering Design, Vol. 16, pp. 1 – 16, 2005. [4] Akao, Y., QFD: Quality Function Deployment - Integrating Customer Requirements into Product Design, Productivity Press, 1990. [5] Wenzel, H., Hauschild, M., Alting, L., Environmental Assessment of Products, Chapman & Hall, London, 1997. [6] Kwak, M., Kim, H. M., “Evaluating End-of-Life Recovery Profit by a Simultaneous Consideration of Product Design and Recovery Network Design,” Journal of Mechanical Design, ASME, Vol. 132, No. 7, 071001, 2010. [7] Phang, K. F., Senin, N., Wallace, D. R., “Distribution modeling and evaluation of product design problems,” Computer-Aided Design, Vol. 30, No. 6, pp. 411 – 423, 1998. [8] Rao, R. V., Padmanabhan, K. K., “Selection of best product end-of-life scenario using digraph and matrix methods,” Journal of Engineering Design, Vol. 21, No. 4, pp. 455 – 472, 2010. [9] Rose, C. M., Masui, K., Ishii, K., “How product characteristics determine end-of-life strategies,” Proceedings of the 1998 IEEE International Symposium on Electronics and the Environment, pp. 322 – 327, 1998. [10] Ostlin, J., Sundin, E., Bjorkman, M., “Product life-cycle implications for remanufacturing strategies,” Journal of Cleaner Production, Vol. 17, No. 11, pp. 999 – 1009, 2009. [11] Sudarsan, R., Fenves, S. J., Sriaram, R. D., Wang, F., “A product information modeling framework for product lifecycle management,” Computer-aided design, Vol. 37, No. 13, pp. 1399 – 1411, 2005. [12] Srinvasan, V., “An integration framework for product lifecycle management,” Computer-aided design, Vol. 43, No. 5, pp. 464 – 478, 2008. [13] Alemanni, M., Destefanis, F., Vezzetti, E., “Model-based definition design in the product lifecycle management scenario,” The International Journal of Advanced Manufacturing Technology, Vol. 52, No. 1-4, pp. 1 – 14, 2011. [14] Zussman, E., Kriwet, A., Seliger, G., “Disassembly-Oriented Assessment Methodology to Support Design for Recycling,” Annals of the CIRP, Vol. 43, No. 1, pp. 9 – 14, 1994. [15] Masanet, E., Auer, R., Tsuda, D., Barillot, T., Baynes, A., “An assessment and prioritization of "design for recycling" guidelines for plastic components,” Proceedings of the 2002 IEEE International Symposium on Electronics and the Environment, pp. 5 – 10, 2002. [16] Steinhilper, R., Remanufacturing – The Ultimate Form of Recycling, Fraunhofer IRB Verlag, 1998. [17] Bras, B., Hammond, R., “Towards design for remanufacturing-metrics for assessing remanufacturing,” Proceedings of the 1st International Workshop on Reuse, pp. 5 – 22, 1996. [18] Ijomah, W., McMahon, C., Hammond, G., Newman, S., “Development of robust design-for- remanufacturing guidelines to further the aims of sustainable development,” International Journal of Production Research, Vol. 45, Nos. 18 & 19, pp. 4513 – 4536, 2007. [19] Dhillon, B. S., Engineering Maintainability: How to Design for Reliability and Easy Maintenance, Gulf Professional Publishing, 1999. [20] Desai, A., Mital, A., “Design for maintenance: basic concepts and review of literature,” International Journal of Product Development, Vol. 3, No. 1, pp. 77 – 121, 2006. [21] Hiroshige, Y., Ohashi, T., Aritomo, S., Suzuki, K., 1997, “Development of Disassemblability Evaluation Method,” Proceedings of the 8th International Conference on Production Engineering, pp. 457 – 466. [22] Duflou, J. R., Seliger, G., Kara, S., Umeda, Y., Ometto, A., Willems, B., 2008, “Efficiency and feasibility of product disassembly: A case-based study,” Annals of the CIRP, Vol. 57 (2), pp. 583 – 600. [23] Seliger, G., Zettl, M., “Modularization as an enabler for cycle economy,” Annals of the CIRP, Vol. 57, No. 1, pp. 133 – 136, 2008. [24] Fukushige, S., Tonoike, K., Inoue, Y., Umeda, Y., “Scenario Based Modularization and Evaluation for 9 Lifecycle Design,” Proceedings of the ASME 2009 International Design Engineering Technical Conference & the Computers and Information in Engineering Conference (IDETC/CIE 2009), DETC2009/DFMLC-87394, 2009. [25] Duflou, J. R., Seliger, G., Kara, S., Umeda, Y., Ometto, A., Willems, B., “Efficiency and feasibility of product disassembly: A case-based study,” Annals of the CIRP, Vol. 57, No. 2, pp. 583 – 600, 2008. [26] Shimomura, Y., Hara, T., Arai, T., “A Unified Representation Scheme for Effective PSS Development,” Annals of the CIRP, Vol. 58, No. 1, pp. 379 – 382, 2009. [27] Meier, H., Massberg, W., “Life Cycle-based Service Design for Innovative Business Models,” Annals of the CIRP, Vol. 53, No. 1, pp. 335 – 338, 2004. [28] Takeda, H., Veerkamp, P., Tomiyama, T., Yoshikawa, H., “Modeling Design Processes,” AI Magazine, Vol. 11, No. 4, pp. 37 – 48, 1990. [29] Moran, T. P., Carroll, J. M., Design Rationale: Concepts, Techniques, and Use, CRC Press, 1996. [30] Janz, D., Sihn, W., “Product Redesign Using Value-Oriented Life Cycle Costing,” Annals of the CIRP, Vol. 54, No. 1, pp. 9 – 12, 2005. [31] Sutherland, J. W., Gunter, K. L., “A Model for Improving Economic Performance of a Demanufacturing System for Reduced Product End-of-Life Environmental Impact,” Annals of the CIRP, Vol. 51, No. 1, pp. 45 – 48, 2002. [32] Umeda, Y., Hijihara, K., Ono, M., Ogawa, Y., Kobayashi, H., Hattori, M., Masui, K., Fukano, A., “Proposal of Life Cycle Design Support Method using Disposal Cause Analysis Matrix,” Proceedings of the 14th International Conference on Engineering Design (ICED03), 2003. [33] Umeda, Y., Daimon, T., Kondoh, S., “Life cycle option selection based on the difference of value and physical lifetimes for life cycle design,” Proceedings of the International Conference on Engineering Design 2007, 2007. [34] Inamura, T., Umeda, Y., Kondoh, S., Takata, S., “Proposal of Life Cycle Evaluation Method for Supporting Life Cycle Design,” Proceedings of the 6th International Conference on EcoBalance, pp. 43 – 46, 2004. [35] Umeda, Y., Nonomura, A., Tomiyama, T., “Study on Life-cycle Design for the Post Mass Production Paradigm,” AIEDAM, Vol. 14 (2), pp. 149 – 161, 2000. [36] Schmuller, J., Sams Teach Yourself UML in 24 Hours, Sams Publishing, 2004. [37] Doyle, J., “A Truth Maintenance System,” Artificial Intelligence, Vol. 12, pp. 231 – 27, 1979. [38] Conklin, J., Begeman, M. L., “gIBIS: A Hypertext Tool for Exploratory Policy Discussion,” ACM Transactions on Office Information Systems, Vol. 6, No. 4, pp. 303 – 331, 1988. [39] Counsell, J., Porter, I., Dawson, D., Duffy, M., “Schemebuilder: computer aided knowledge based design of mechatronic systems,” Assembly Automation, Vol. 19, No. 2, 1999. [40] Nomaguchi, Y., Fujita, K., “An Integrated Framework for Advanced Knowledge-based Design Support – A Viewpoint of DRIFT Paradigm,” Proceedings of the 7th IJCC Japan-Korea CAD/CAM Workshop, pp. 70 – 75, 2007. [41] Bracewell, R. H., Gourtovaia, M., Moss, M., Knott, D., Wallace, K. M., Clarkson, P. J., “Dred 2.0: A method and tool for capture and communication of design knowledge deliberated in the creation of technical products” Proceedings of the 17th International Conference on Engineering Design (ICED'09), pp. 223 – 234, 2009. [...]... Process parameters of a disassembly process in a lifecycle flow model Figure 11 Design rationale network for Scenario A Figure 12 Design rationale network for Scenario B Figure 13 Lifecycle flow for Scenario B Table 1 Scenario assessment Profit CO2 emissions Current scenario (recycling first) Scenario A (reuse first) Scenario B (remanufacturing first) Lifecycle phase Assembly Distribution Disassembly...Figure 1 Lifecycle design process Figure 2 Product structure model Figure 3 Lifecycle flow model Figure 4 Relationship between the structure and flow models Figure 5 Design rationale network Figure 6 Design rationale network and TMS structure Figure 7 Management of alternatives Figure 8 Prototype system... Inspection Table 3 100% 101% 102% 100% 99% 79% Table 2 Design requirements Design requirement Manufacturing cost: less than 16,850 yen /product Remanufactured phone price: 60% of new phone price Disassembly time: less than 10 min /product Improve manual disassemblability Develop personal data protection and backup service Collection rate: more than 80%; new product service system required Yield rate of components:... disassemblability Develop personal data protection and backup service Collection rate: more than 80%; new product service system required Yield rate of components: more than 70% (average) Process Process parameters for simulation (excerpt) Parameter Parameter value Disassembly Labor cost 1,800 yen/hour Assembly time Inspection cost Inspection CO2 emission Recycling cost Recycling CO2 emission Recycling cost Recycling . process in a lifecycle flow model Figure 11. Design rationale network for Scenario A Figure 12. Design rationale network for Scenario B Figure 13. Lifecycle flow for Scenario B Table 1. Scenario. describing the lifecycle scenario, designers can easily identify appropriate lifecycle options and requirements for product and process design in the later stages of lifecycle design. Some. whole product lifecycle. 2 Requirements for the lifecycle scenario design system As outlined above, environmentally conscious product design should be executed after an appropriate lifecycle