Lifecycle scenario design for product end-of-life strategy
© Fukushige et al; licensee Springer. 2012
Received: 16 January 2011
Accepted: 17 January 2012
Published: 17 January 2012
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.
Keywordslifecycle design end-of-life strategy lifecycle scenario
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  proposed a lifecycle planning methodology that supports lifecycle option selection on the part level through analysis based on QFD  and lifecycle assessment . Kwak et al. proposed a method of evaluating end-of-life recovery profit by considering both product design and recovery network design . 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) . 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 . 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 . Ostlin et al. proposed the inclusion of product lifecycle consideration in remanufacturing strategies . 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)  into PLM. With MBD, most product lifecycle data are structured inside CAD models rather than being scattered in different forms throughout the 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–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 . Modular design is also useful in enabling all lifecycle options such as remanufacturing, maintenance, reuse and recycling (e.g., ). By way of example, Duflou et al.  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  described in Section 4.1. Moreover, as previously discussed in relation to research on design rationale (e.g., ), 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 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  and the product lifetime prediction method ), lifecycle assessment (LCA)  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 CO2 emissions' combined with the parameter values of 'profit: more than 100%' and 'CO2 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.
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)  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 .
The description process here assumes that the designer identifies problems to be solved (such as the 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
In this study, node relationship management was based on the Truth Maintenance System (TMS) , 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)  is used to represent dependencies among problems and alternatives by creating a tree structure as an argumentation model. Schemebuilder  and DRIFT (Design Rationale Integration Framework of Three layers)  also enable the management of a wide range of engineering design alternatives using the TMS for computer-aided knowledge-based design.
4.3 Process of lifecycle scenario description
Here we propose a process for lifecycle scenario description. First, the designer analyses and describes the 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 . 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
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 CO2 reduction will be required to comply with new regulations this year.' Based on the design reasons, we set the lifecycle objective as 'to reduce CO2 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 order to examine several possibilities for achieving the objective, two CO2 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.
Current scenario (recycling first)
Scenario A (reuse first)
Scenario B (remanufacturing first)
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: more than 70% (average)
6.2 Characteristics of the method: description of the scenario review process
Process parameters for simulation (excerpt)
Inspection CO2 emission
Recycling CO2 emission
Recycling CO2 emission
Recycling CO2 emission
Landfill CO2 emission
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  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.
- Alting L, Jorgensen J: The Life Cycle Concept as a Basis for Sustainable Industrial Production. Annals of the CIRP 1993,42(1):163–166. 10.1016/S0007-8506(07)62417-2View ArticleGoogle Scholar
- Fukushige S, Inoue Y, Tonoike K, Umeda Y: Design Methodology for Modularity Based on Life Cycle Scenario. International Journal of Automation Technology 2009,3(1):40–48.Google Scholar
- Kobayashi H: Strategic Evolution of Ecoproducts: a Product Life Cycle Planning Methodology. Research in Engineering Design 2005, 16: 1–16. 10.1007/s00163-005-0001-3View ArticleGoogle Scholar
- Akao Y: QFD: Quality Function Deployment-Integrating Customer Requirements into Product Design. Productivity Press; 1990.Google Scholar
- Wenzel H, Hauschild M, Alting L: Environmental Assessment of Products. Chapman & Hall, London; 1997.View ArticleGoogle Scholar
- Kwak M, Kim HM: Evaluating End-of-Life Recovery Profit by a Simultaneous Consideration of Product Design and Recovery Network Design. Journal of Mechanical Design, ASME 2010.,132(7): 071001Google Scholar
- Phang KF, Senin N, Wallace DR: Distribution modeling and evaluation of product design problems. Computer-Aided Design 1998,30(6):411–423. 10.1016/S0010-4485(98)00005-0View ArticleGoogle Scholar
- Rao RV, Padmanabhan KK: Selection of best product end-of-life scenario using digraph and matrix methods. Journal of Engineering Design 2010,21(4):455–472. 10.1080/09544820802406129View ArticleGoogle Scholar
- Rose CM, Masui K, Ishii K: How product characteristics determine end-of-life strategies. Proceedings of the 1998 IEEE International Symposium on Electronics and the Environment 1998, 322–327.Google Scholar
- Ostlin J, Sundin E, Bjorkman M: Product life-cycle implications for remanufacturing strategies. Journal of Cleaner Production 2009,17(11):999–1009. 10.1016/j.jclepro.2009.02.021View ArticleGoogle Scholar
- Sudarsan R, Fenves SJ, Sriaram RD, Wang F: A product information modeling framework for product lifecycle management. Computer-aided design 2005,37(13):1399–1411. 10.1016/j.cad.2005.02.010View ArticleGoogle Scholar
- Srinvasan V: An integration framework for product lifecycle management. Computer-aided design 2008,43(5):464–478.View ArticleGoogle Scholar
- Alemanni M, Destefanis F, Vezzetti E: Model-based definition design in the product lifecycle management scenario. The International Journal of Advanced Manufacturing Technology 2011,52(1–4):1–14. 10.1007/s00170-010-2699-yView ArticleGoogle Scholar
- Zussman E, Kriwet A, Seliger G: Disassembly-Oriented Assessment Methodology to Support Design for Recycling. Annals of the CIRP 1994,43(1):9–14. 10.1016/S0007-8506(07)62152-0View ArticleGoogle Scholar
- 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 2002, 5–10.Google Scholar
- Steinhilper R: Remanufacturing-The Ultimate Form of Recycling. Fraunhofer IRB Verlag; 1998.Google Scholar
- Bras B, Hammond R: Towards design for remanufacturing-metrics for assessing remanufacturing. Proceedings of the 1st International Workshop on Reuse 1996, 5–22.Google Scholar
- 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 2007, 45: 4513–4536. Nos. 18 & 19 10.1080/00207540701450138View ArticleGoogle Scholar
- Dhillon BS: Engineering Maintainability: How to Design for Reliability and Easy Maintenance. Gulf Professional Publishing; 1999.Google Scholar
- Desai A, Mital A: Design for maintenance: basic concepts and review of literature. International Journal of Product Development 2006,3(1):77–121.View ArticleGoogle Scholar
- Hiroshige Y, Ohashi T, Aritomo S, Suzuki K: Development of Disassemblability Evaluation Method. Proceedings of the 8th International Conference on Production Engineering 1997, 457–466.Google Scholar
- Duflou JR, Seliger G, Kara S, Umeda Y, Ometto A, Willems B: Efficiency and feasibility of product disassembly: A case-based study. Annals of the CIRP 2008,57(2):583–600. 10.1016/j.cirp.2008.09.009View ArticleGoogle Scholar
- Seliger G, Zettl M: Modularization as an enabler for cycle economy. Annals of the CIRP 2008,57(1):133–136. 10.1016/j.cirp.2008.03.031View ArticleGoogle Scholar
- Fukushige S, Tonoike K, Inoue Y, Umeda Y: Scenario Based Modularization and Evaluation for Lifecycle Design. Proceedings of the ASME 2009 International Design Engineering Technical Conference & the Computers and Information in Engineering Conference (IDETC/CIE 2009) 2009. DETC2009/DFMLC-87394Google Scholar
- Duflou JR, Seliger G, Kara S, Umeda Y, Ometto A, Willems B: Efficiency and feasibility of product disassembly: A case-based study. Annals of the CIRP 2008,57(2):583–600. 10.1016/j.cirp.2008.09.009View ArticleGoogle Scholar
- Shimomura Y, Hara T, Arai T: A Unified Representation Scheme for Effective PSS Development. Annals of the CIRP 2009,58(1):379–382. 10.1016/j.cirp.2009.03.025View ArticleGoogle Scholar
- Meier H, Massberg W: Life Cycle-based Service Design for Innovative Business Models. Annals of the CIRP 2004,53(1):335–338.View ArticleGoogle Scholar
- Takeda H, Veerkamp P, Tomiyama T, Yoshikawa H: Modeling Design Processes. AI Magazine 1990,11(4):37–48.Google Scholar
- Moran TP, Carroll JM: Design Rationale: Concepts, Techniques, and Use. CRC Press; 1996.Google Scholar
- Janz D, Sihn W: Product Redesign Using Value-Oriented Life Cycle Costing. Annals of the CIRP 2005,54(1):9–12. 10.1016/S0007-8506(07)60038-9View ArticleGoogle Scholar
- Sutherland JW, Gunter KL: A Model for Improving Economic Performance of a Demanufacturing System for Reduced Product End-of-Life Environmental Impact. Annals of the CIRP 2002,51(1):45–48. 10.1016/S0007-8506(07)61462-0View ArticleGoogle Scholar
- 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.Google Scholar
- 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. 2007Google Scholar
- 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 2004, 43–46.Google Scholar
- Umeda Y, Nonomura A, Tomiyama T: Study on Life-cycle Design for the Post Mass Production Paradigm. AIEDAM 2000,14(2):149–161. 10.1017/S0890060400142040View ArticleGoogle Scholar
- Schmuller J: Sams Teach Yourself UML in 24 Hours. Sams Publishing; 2004.Google Scholar
- Doyle J: A Truth Maintenance System. Artificial Intelligence 1979, 12: 231–27. 10.1016/0004-3702(79)90008-0MathSciNetView ArticleGoogle Scholar
- Conklin J, Begeman ML: gIBIS: A Hypertext Tool for Exploratory Policy Discussion. ACM Transactions on Office Information Systems 1988,6(4):303–331. 10.1145/58566.59297View ArticleGoogle Scholar
- Counsell J, Porter I, Dawson D, Duffy M: Schemebuilder: computer aided knowledge based design of mechatronic systems. Assembly Automation 1999.,19(2):Google Scholar
- 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 2007, 70–75.Google Scholar
- Bracewell RH, Gourtovaia M, Moss M, Knott D, Wallace KM, Clarkson PJ: 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) 2009, 223–234.Google Scholar
This article is published under license to BioMed Central Ltd. 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.