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
Skip to main content
© 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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.