RESEARCH Open Access Lifecycle scenario design for product ... · stages of lifecycle design, the requirements for product and process design need to be clarified. This require-ment

RESEARCH Open Access

Lifecycle scenario design for productend-of-life strategyShinichi Fukushige*, Kazuhiro Yamamoto and Yasushi Umeda

Abstract

This paper proposes a method for supporting the design of product lifecycles. The main approach involvessupporting designers in determining a lifecycle strategy by describing lifecycle scenarios at an early stage oflifecycle design. The authors define a representational scheme for the lifecycle scenario and outline a supportsystem based on the idea of the Cognitive Design Process model allowing the designers to examine variouspossibilities of lifecycle strategy. A number of alternative scenarios are managed by the Truth Maintenance Systemimplemented in this approach. Finally, in order to embody the strategy in the later stages, the system derivesrequirements for product and process design. This paper outlines the lifecycle scenario of a cellular phone as acase study, which indicates the system’s suitability for computer-aided description of scenarios and its facilitation oflifecycle strategy development.

Keywords: lifecycle design, end-of-life strategy, lifecycle scenario

1 IntroductionPromising approaches for sustainable developmentinvolve the construction of stable product lifecycle sys-tems that drastically reduce environmental loads,resource consumption and waste generation whileincreasing living standards and corporate profits. Thedesign of a product lifecycle includes the steps of mod-eling the lifecycle itself, evaluating it from various view-points, and pinpointing solutions to optimize thelifecycle as a whole [1]. We previously proposed the life-cycle design process [2] shown in Figure 1. First,designers analyze the current state of the product andits market, and determine the product concept, businessstrategies and environmental targets based on the resultsof this analysis. Second, the designers formulate a life-cycle strategy according to the product concept, busi-ness strategy and environmental targets. Third, thedesigners design the product and its various lifecycleprocesses in line with the strategy. Finally, the designersevaluate the whole lifecycle of the product to confirmthe feasibility of the strategy. In short, the lifecycle strat-egy is planned from the early stages, and the product isdesigned to realize the strategy.

To support the strategy planning stage, this paper pro-poses a method of describing product lifecycle scenariosby which designers can explicitly determine lifecyclestrategies. Here, the lifecycle strategy is defined as acombination of lifecycle options (e.g., maintenance, pro-duct reuse, component reuse, closed-loop recycling andcascade recycling) for a product and its components,and the lifecycle scenario is a description of theexpected product lifecycle. In other words, by describingthe lifecycle scenario, designers can easily identifyappropriate lifecycle options and requirements for pro-duct and process design in the later stages of lifecycledesign.Some studies have focused on support for lifecycle

strategy planning. Kobayashi [3] proposed a lifecycleplanning methodology that supports lifecycle optionselection on the part level through analysis based onQFD [4] and lifecycle assessment [5]. Kwak et al. pro-posed a method of evaluating end-of-life recovery profitby considering both product design and recovery net-work design [6]. Phang et al. proposed a design methodthat includes end-of-life strategy design by evaluatingthe product lifecycle in Distributed Object-orientedModeling and Environment (DOME) [7]. Rao et al. pro-posed an end-of-life scenario selection method to opti-mize multiple parameters related to a product lifecycle* Correspondence: [email protected]

Graduate School of Engineering, Osaka University, Osaka, Japan

Fukushige et al. Journal of Remanufacturing 2012, 2:1http://www.journalofremanufacturing.com/content/2/1/1

© 2012 Fukushige et al; licensee Springer. This is an Open Access article distributed under the terms of the Creative CommonsAttribution License (http://creativecommons.org/licenses/by/2.0), which permits unrestricted use, distribution, and reproduction inany medium, provided the original work is properly cited.

mailto:[email protected]

http://creativecommons.org/licenses/by/2.0

by utilizing a directed graph [8]. Rose et al. outlined anapproach for determining appropriate end-of-life strate-gies based on product characteristics such as a product’slife span and the rate of technological innovation in pro-ducts [9]. Ostlin et al. proposed the inclusion of productlifecycle consideration in remanufacturing strategies[10]. As these methods mainly focus on the selection ofoptimal processes and parameters from the specificaspect of product lifecycle, they are not ideal for exam-ining and comparing various lifecycle possibilities fromdifferent 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 life-cycle data are structured inside CAD models rather thanbeing scattered in different forms throughout the PLMdatabase. Although such product lifecycle data manage-ment and integration methods help to eliminate redun-dant documentation and increase product dataaccessibility, they do not focus on support for lifecycledesign. In other words, PLM systems do not provideproduct lifecycle models that enable explicit design.A number of studies have also addressed environmen-

tally conscious product design technologies; examplesinclude design for recycling [14,15], remanufacturing/reuse [16-18], maintenance [19,20] and ease of disas-sembly [21,22]. In this area, modular design methodshave been studied for ease of manufacture and assembly[23]. Modular design is also useful in enabling all life-cycle 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 anindispensable critical driver in the remanufacture of sin-gle-use cameras. However, the relationships and trade-offs between these design methods have not been clari-fied, and no design environment integrates these eco-design technologies based on end-of-life strategies. Sup-port for decision making in this area is also needed.Design methodologies for product service systems

have also been eagerly studied [26,27]. From the view-point of lifecycle design, servicizing is a strong enablerof lifecycle strategies, and describing lifecycle scenariosis also useful in setting targets for servicization. How-ever, no computational representation of lifecycle sce-narios has yet been established, meaning that there is nocomputational support tool for describing lifecycle sce-narios including product service system.The objectives of this study are to propose a scheme

for representing the lifecycle scenario and its descriptionprocess and to develop a description/management sup-port system for examining various lifecycle strategy pos-sibilities and clarifying requirements for product andprocess design. One of the main contributions of thestudy is its definition of scenarios as computational life-cycle models that enable the design, visualization andevaluation of the whole product lifecycle.

2 Requirements for the lifecycle scenario designsystemAs outlined above, environmentally conscious productdesign should be executed after an appropriate lifecycle

Figure 1 Lifecycle design process.


Page 2 of 15

strategy has been planned, and describing lifecycle sce-narios is a promising approach to clarifying such a strat-egy. In determining a lifecycle strategy, designers shouldconsider the business plan, environmental targets to bemet, and the product concept to provide value tocustomers.To support such design, we sought to formulate a

workspace that will allow designers to examine variousscenarios using a description support system. To thisend, we identified five requirements for the system:1. Support for the description and examination of var-

ious plausible lifecycle scenarios: As environmentalissues are typically poorly structured problems thatrequire lifecycle consideration from various viewpoints,the system should support designers in examining var-ious plausible scenarios. To this end, Sections 3 and 4propose a representational scheme for scenarios and therelated description process.2. Clarification of requirements for product and process

design: To embody the lifecycle strategy in the laterstages of lifecycle design, the requirements for productand process design need to be clarified. This require-ment is met in the representational scheme through theproduct structure model, lifecycle flow model and theprocess parameters detailed in Section 3.3. Explicit representation of the design rationale

throughout the scenario description process: The lack ofgeneral criteria for environmentally friendly productsmeans that manufacturers must declare why a productis promoted as having environmental merits. One wayof doing this is to express the rationale of decisionsmade by the designers during lifecycle design. Accord-ingly, the reasons behind the designers’ decisions arerecorded to clarify the design rationale, which is repre-sented using the cognitive design process model [28]described in Section 4.1. Moreover, as previously dis-cussed in relation to research on design rationale (e.g.,[29]), this approach is useful for reusing designknowledge.4. Management of alternatives: At each step in the

scenario description process, the designers generate andchoose alternatives. To support the design process, thesystem should therefore be capable of appropriatelymanaging these design alternatives. This managementmethod is outlined in Section 4.2.5. Integration of results from lifecycle design support

tools: The scenario description support system shouldnot be closed. Rather, it assumes that the designers gen-erate alternatives and make decisions using various life-cycle design support tools. Examples include evaluationmethods based on lifecycle cost [30,31], lifecycle optionselection 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 toimport the results of these external support tools.

3 Lifecycle scenario representationA lifecycle scenario represents all the scenes of a pro-duct lifecycle in terms of 5W1H expression (who,where, what, why, when and how). In this paper, thelifecycle scenario definition is based on the followingfive elements:1. Lifecycle objective: Declaring the objective of the life-

cycle is important in clarifying the targets and criteria forscenario evaluation. Here, the objective is represented inverbal form and by target parameter values. An examplewould be the objective statement ‘To keep the manufac-turer in profit and to halve CO2 emissions’ combinedwith 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 alifecycle scenario based on lifecycle objectives alone.Accordingly, we introduced the lifecycle concept, whichindicates the basic direction for the construction of ascenario (such as extending product life or increasingthe efficiency of recycling) as a bridge between theobjective and the selection of lifecycle options.3. Lifecycle options: The lifecycle options of a product

and its components determine the basic structure ofscenarios. In order to manage combinations of lifecycleoptions and product components, product structuremodel is introduced as shown in Figure 2. In thismodel, each node represents a product’s component andis related to its applied lifecycle option. For example,‘To be reused in the first life, then recycled in the sec-ond life’ might be used to describe the lifecycle optionsof a component, and the combination of options isrelated to the corresponding node of the product struc-ture model.

Productnode

Componentnode

CaseThermal recovery

MotorReuse & Recycling

Figure 2 Product structure model.


Page 3 of 15

4. Lifecycle flow: This is the central model of the lifecyclescenario, and represents the flow of products, components,materials, information and money in the form of a lifecycleprocess network. Each lifecycle process of the flow modelhas the inputs and outputs of the process (such as theincome and expenditure of the process stakeholder) toallow lifecycle evaluation from environmental and eco-nomic viewpoints using the LCS. Figure 3 shows an exam-ple of lifecycle flow, where component A is reused andcomponent B is recycled. It is also related to the productstructure model, as shown in Figure 4. The system man-ages the relationship between the component nodes of aproduct structure model and the process nodes of a life-cycle flow model. As a result, a flow model clarifies therequirements for the later stages of lifecycle design.5. Situation: Each lifecycle process is described as a

‘situation’ using 5W1H expression. The design require-ments for situations are also described, and the ‘How’part is represented in UML (Unified Modeling Lan-guage) [36] for formalization.

4 Scenario design process4.1 Representation of design rationaleTo represent the designer’s decisions explicitly, thispaper outlines the scenario description process throughextension of the cognitive design process model [28].

As shown in Figure 5, all information provided bythe designer is classified into the three categories ofdesign reasons, solution candidates and selected solu-tions. The nodes are related to each other by positive,negative or antinomy causality links. The design rea-son node includes the four subtypes of fact, assump-tion, result from an external tool (denoting anevaluation result obtained from an external tool asdescribed in Section 2) and requirement, which repre-sents a design aspect required for realization of thelifecycle scenario. The candidate nodes and solutionnodes have links to the scenario elements describedin Section 3, and the design reason nodes havedetailed descriptions or links to references and exter-nal tools.The description process here assumes that the

designer identifies problems to be solved (such as theselection of plausible lifecycle options) at each step ofthe process (the horizontal gray line in Figure 5), thenproposes solution candidates and gives design reasonsfor them. These reasons are derived from the designer’sknowledge, references and results from external tools,and are related to the candidate nodes by positive ornegative causality links. Next, the designer evaluates thecandidates, which also results in positive or negativelinks from the design reason nodes.

Component Amanufacturing Assembly Distribution Use

Collection

Disassembly

Inspection

RecyclingDisposal

Component Bmanufacturing

Lifecycle process

Flow of products, components and materials

Accept

Reject

Component A

Component B

Figure 3 Lifecycle flow model.


Page 4 of 15

Design reason nodes and solution candidate nodeshave either a valid or an invalid state. The state is chan-ged to invalid by negative causality links, and thus inva-lidated nodes cannot affect other nodes. In Figure 5, theinvalidated nodes are greyed out. The designer selectsone or more solutions from among the valid candidatenodes, and the selected candidates are changed to

selected solution nodes. The designer cannot select twonodes connected by antinomy link.Based on the selected solutions, the designer also pro-

poses solution candidates at the next step and choosessolutions from among them. The nodes are connectedby causality links from the previous step’s nodes. As aresult of these processes, the design rationale of the

Structure model Lifecycle flow modelFigure 4 Relationship between the structure and flow models.

Antinomy

Designreason

Solutioncandidate

Selectedsolution

Positive

Negative

Node type2 3

6

1

4

7 98

5 1st STEP

2nd STEP

Nth STEP

Link type

Figure 5 Design rationale network.


Page 5 of 15

scenario is represented as a network of these alternativenodes. Having the designer construct this network pro-vides a record of the thought processes and grounds onwhich the design is based.

4.2 Management of alternativesAs designers need to examine various tradeoffs indescribing a lifecycle scenario as detailed in Section 2, itis necessary to manage various alternatives (solutioncandidates) at each step of the process. To examine thevarious possibilities involved, the designer switches theselected solutions among the candidate nodes as shownin Figure 6. Such alternatives are associated with thealternatives of the former and later steps in the designrationale network.In this study, node relationship management was

based on the Truth Maintenance System (TMS) [37],which is a knowledge representation and managementmethod for maintaining both knowledge (propositions)and dependencies (Boolean constraints). In other words,it maintains logical consistency between current knowl-edge and old knowledge in a knowledge networkthrough revision.Each node in the TMS network has the state of In or

Out, representing the validity or invalidity of the knowl-edge in a certain context. In this research, we employeda simple justification-based TMS mechanism to manageall design alternatives. This maintains consistencyamong the solutions, candidates and design reasons inthe design rationale network defined in Section 4.1.In the context of decision support systems for engi-

neering design, gIBIS (graphical Issue-Based InformationSystem) [38] is used to represent dependencies among

problems and alternatives by creating a tree structure asan argumentation model. Schemebuilder [39] andDRIFT (Design Rationale Integration Framework ofThree layers) [40] also enable the management of awide range of engineering design alternatives using theTMS for computer-aided knowledge-based design.Our system mainly focuses on the construction of

lifecycle models, and provides a framework that inte-grates the lifecycle design support tools described inSection 2. In accordance with the manual construc-tion and revision of the design rationale network, aTMS structure is created and updated automaticallyin the background. Figure 7 shows a TMS structurecorresponding to a design rationale network. Networkconsistency is maintained by revising the state of thenodes in the logical structure. In other words, thevalid/invalid state of the nodes in this network corre-sponds to the In/Out state of the nodes in the TMSstructure. For example, the state of a node becomesOut when the node is supported by In-state nodes vianegative links. This structure further introduces thetwo node types of selection and contradiction. Aselection node represents a designer’s selection orrejection from among the solution candidate nodes,while a contradiction node corresponds to an anti-nomy link and disables the simultaneous selection oftwo nodes connected by such a link. When the stateis changed or a new node is added, the TMS mechan-ism backtracks through the causality connections, andif a contradiction is found, the node responsible isidentified and changed to an appropriate state. As aresult, a variety of alternatives can be managedeffectively.

Switching Justification

Alternative

Figure 6 Design rationale network and TMS structure.


Page 6 of 15

4.3 Process of lifecycle scenario descriptionHere we propose a process for lifecycle scenario descrip-tion. First, the designer analyses and describes the pro-duct’s characteristics and related market information ina workspace in the form of design reason nodes. Next,the designer step-wisely describes a lifecycle scenariofrom the lifecycle objectives to the lifecycle situationsdefined in Section 3. At each step, the designerdescribes the scenario with design reason nodes andsolution candidate nodes in the design rationale net-work, and may use external tools to validate or invali-date the nodes via positive or negative causality links. Insuch cases, results from external tools are representedas such in design reason nodes. For example, the suit-ability of material recycling may be evaluated using atool such as the Lifecycle Planner [3]. The proposedmethod places focus on providing the designer with aworkspace for examining various scenario alternativesby incorporating a range of external tools.

In this method, it is assumed that the designer evalu-ates the scenario using external tools after the lifecycleflow has been constructed. Here, we employ lifecyclesimulation, which enables lifecycle evaluation in termsof environmental loads, material balance and monetarybenefits. As the main simulation model for the lifecyclesimulator involves the lifecycle flow defined in Section3, the scenario can be evaluated directly and interac-tively after flow model creation. The designer shouldspecify situations for the simulation in each process ofthe lifecycle flow.The designer repeats this cycle until all lifecycle objec-

tives are achieved. If no such solution is found, thedesigner reviews the design of the scenario and its con-ditions (i.e., the lifecycle concepts, options, flow andrelated process parameters). Lifecycle objectives can alsobe targets of revision. Finally, the designer extracts therequirements and conditions from the requirementnodes in the design rationale network and the process

C

C

In

InOut

OutInOut

In In

InInOut

InOut

Out In Out

Selection

Contradiction

TMS node

c

CORRESPONDING

Figure 7 Management of alternatives.


Page 7 of 15

parameters in the lifecycle flow for product and processdesign in the later stages.

5 Prototype systemWe developed a prototype system based on the pro-posed method (see Figure 8 for an outline of the systemarchitecture). The designers describe a lifecycle scenariousing the individual sub-tools provided (objectivedescription tool, lifecycle concept description tool, life-cycle option selection tool, lifecycle flow modeler, pro-cess situation modeler and product structure modeler),and the lifecycle scenario manager integrates these sub-tools. The design rationale manager provides a work-space for constructing a design rationale network, andthe alternative manager maintains the consistency of thenetwork using TMS as described in Section 4. There arealso two databases to support the construction of life-cycle flow and product structure model. Figure 9shows a screenshot of the workspace in which theindividual scenario components (lifecycle objective,concepts, options, flow, process details and productstructure) are edited. These components are linked to

the corresponding nodes of the design rationale networkand the relationship of the components is managed inthe network. The lifecycle flow model is further relatedto the product structure model as described in Section3. In other words, the system integrates the two modelsto enable visualization and management of which pro-duct’s parts pass through which processes of the flowmodel. Figure 10 shows an example of the parameters ofa process in a flow model. Each process has given para-meters, input parameters, output parameters and proce-dures. Some input parameters are imported from aproduct structure model that holds information on theattributes of the product’s components, such as its con-stituent materials, weight, volume and lifetime.

6 Case study6.1 Describing a lifecycle scenario for a cell phoneHere we describe a lifecycle scenario for a cell phoneusing the prototype system as a case study. The phoneconsists of a printed circuit board (PCB), a CCD cameraunit, a vibrator, a speaker unit, a battery, cases, a micro-phone unit and a liquid crystal display (LCD) unit.

Lifecycle scenario description support system

Lifecycle scenariomanager

Lifecycle scenario editor

Lifecycle optionselection tool

Lifecycle conceptdescription tool

Process situationmodeler

Lifecycle flowmodeler

Lifecycle objectivedescription tool

Designrationalemanager

Alternativemanager

Product structuremodeler

Processdatabase

Objectdatabase

External lifecycle design support tools

Lifecycle designer

Figure 8 Prototype system architecture.


Page 8 of 15

First, we analyzed the current lifecycle of the phoneand constructed a lifecycle flow model to enable assess-ment of its environmental loads and profit through life-cycle simulation. Based on the results of this analysis,we described the product’s characteristics and marketinformation in the design reason nodes of the work-space. In addition to these fact nodes, we also includedassumption node notes such as ‘Higher-level CO2 reduc-tion will be required to comply with new regulationsthis year.’ Based on the design reasons, we set the life-cycle objective as ‘to reduce CO2 emissions withoutreducing current profit,’ and, as a parameter value forthe objective, the manufacturer’s profit was set as ‘morethan 100% of that of the current lifecycle.’ Here, inorder to examine several possibilities for achieving theobjective, two CO2 reduction rates of 20% and 10%were set, and the 20% rate was selected first. These twocandidates were connected with a contradictory link toavoid 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 lifecycleconcept based on the facts and assumptions described inthe workspace.Third, we selected lifecycle options. For the LCD, for

example, we examined reuse, cascade material recy-cling and appropriate disposal options as alternatives.From among them, we selected the reuse option inconsideration of longer physical life for the LCD inline with the results of the Disposal Cause Analysisexternal tool [32]. However, according to the marketanalysis performed in the first step, the size and func-tion of LCDs vary by cell phone type, making stablereuse difficult. This negated the reuse option, and cas-cade material recycling was therefore selected as thealternative lifecycle option for the LCD. DisposalCause Analysis also positively supported the reuseoption for the speaker, the vibrator and the CCD cam-era, but negated the reuse option for the battery andthe case because of their short lives. As a result, thespeaker was set to be reused in the first life and thencascade-recycled in the second life. Figure 11 partially

BodySpeaker Battery

VibratorCasesFixer

Camera

Cell phone

Use

Product structure model

Lifecycle flow

Lifecycle option

Lifecycle objective Lifecycle concept

Remanufacturing – No.2

Remanufacturing – No.2

CO2 reduction

Profit ratio of the manufactureReduction rate of LC CO2 emission

Remanufacturing oriented

Profit ratio of the manufactureReduction rate of LC CO2 emission

FixerCases

VibratorSpeakerLCDPCB

Figure 9 Screenshot of the workspace.


Page 9 of 15

depicts the design rationale network for the casedescribed in the workspace.Fourth, we evaluated this scenario (Scenario A) based

on lifecycle simulation. The lifecycle flow model con-structed in the first step was revised for adaptation tothe described scenario. The results of the evaluationindicated that, while the profit satisfies the objectivevalue of more than 100%, the reduction of CO2 emis-sions does not fulfill either of the objectives as shown inTable 1. Furthermore, the reuse option for the speakerand the CCD camera is not feasible due to the lack sec-ond-hand markets for such parts.To solve this problem, we modified the scenario to

create Scenario B, in which the reuse option is selectedfor the LCD and PCB instead of the cascade materialrecycling option because the lifecycle simulationrevealed that these components have higher CO2 reduc-tion potential in the manufacturing process. However,as noted in the design reasons, the functional diversityand frequent restyling of such parts eliminate the poten-tial for their stable reuse. To address this contradiction,we added the lifecycle concept of remanufacturing (inwhich cell phones are restored to as-new conditionthrough repair or replacement of cases and butteries)

and changed the lifecycle flow. As remanufacturedphones are not fully equivalent to original new products,we set their price and market size to 60% and 30% ofthose of a brand-new product, respectively. These rateswere taken as suppositions for trial calculation of profit.Additionally, Scenario B involves an attempt to improvethe collection rate of old cell phones to 80% by provid-ing customers with a data-backup service and a trade-inservice in the new business flow, which was noted inthe form of additional requirement nodes in the designrationale network. This network for Scenario B is par-tially depicted in Figure 12, which shows the change inselected lifecycle options and the additional requirementnodes (in yellow). These amendments remove the obsta-cles to remanufacturing concept. Figure 13 shows thelifecycle flow of this remanufacturing-oriented scenario.Table 1 compares the results of the lifecycle simula-

tion for Scenarios A and B. As Scenario B satisfies allthe objectives, we chose it as the final scenario andcompleted the scenario description process. Table 2summarizes the design requirements identified from thisprocess extracted from the requirement nodes in thedesign rationale network and the process parameters inthe lifecycle flow model.

Given parameter

Input parameter

Output parameter

Procedure

Figure 10 Process parameters of a disassembly process in a lifecycle flow model.


Page 10 of 15

6.2 Characteristics of the method: description of thescenario review processThe design rationale network constructed in the casestudy had more than 50 nodes, allowing the systemdeveloped to be used for the management of a numberof alternatives by structuring them into a single

Figure 11 Design rationale network for Scenario A.

Table 1 Scenario assessment

Profit CO2 emissions

Current scenario (recycling first) 100% 100%

Scenario A (reuse first) 101% 99%

Scenario B (remanufacturing first) 102% 79%


Page 11 of 15

network. These nodes corresponded to a wide range ofscenario components including lifecycle objectives, con-cepts, options, flows and situations. The mutual connec-tion of these components through causality linksfacilitates identification of the design reasons on whichthe selection of alternatives in the scenario was based. Itwas also possible to trace the origins (such as objectives,concepts and options) from which the lifecycle strategywas derived. The variations in the lifecycle flow modelwere recorded in individual nodes, and their revisionscould be compared easily. The flow model and its con-stituent processes were utilized to compose a simulationmodel with which the lifecycle simulator calculated theprofit of the manufacturer and the CO2 emissions for allprocesses in the lifecycle. Table 3 shows some of theprocess parameters used in the simulation model.

In the case study, we set the price and market size of theremanufactured phone, and these values were used as sup-positions for the calculation of profit in the simulation.Such relationships between suppositions and calculationresults in the design rationale network served as records oftrials for examining various lifecycle scenario possibilities.It is a characteristic of the system that evaluation resultsfrom external tools are recorded and related to conditionvalues for evaluation in each design reason node. AlthoughScenario B satisfied the all objectives, this result was basedon the supposition values described in the design reasonnodes and the process parameters. Accordingly, if it isfound that one of these values will be impossible to imple-ment at a later stage, the designer should return to thescenario design process and review/simulate the scenarioagain with another supposition.

Figure 12 Design rationale network for Scenario B.


Page 12 of 15

7 Summary and conclusionsThe case study showed that lifecycle scenarios can besuccessfully represented using the representationalscheme outlined in this paper, and that the proposedmethod supports the description process. As a result, itis confirmed that a designer can easily determine a life-cycle strategy by describing the lifecycle scenario, and

can derive design requirements for the later processes oflifecycle design.Section 2 identified five requirements for the system,

and requirements 1 and 2 are achieved by the proposedrepresentational scheme. We also proposed a processfor breaking down a lifecycle scenario from lifecycleobjectives to a lifecycle situation that can be assessed

Figure 13 Lifecycle flow for Scenario B.

Table 2 Design requirements

Lifecycle phase Design requirement

Assembly Manufacturing cost: less than 16,850 yen/product

Distribution Remanufactured phone price: 60% of new phone price

Disassembly Disassembly time: less than 10 min/productImprove manual disassemblability

Service Develop personal data protection and backup service

Collection Collection rate: more than 80%; new product service system required

Inspection Yield rate of components: more than 70% (average)


Page 13 of 15

with Lifecycle Simulation. This allows designers to sys-tematically detail plausible lifecycle strategies that satisfythe objectives by clarifying facts, assumptions, solutioncandidates, decisions and design requirements.In terms of requirement 3, the case study verified that

the system can be used to appropriately record the sce-nario description process to represent the design ratio-nale. As discussed in Section 2, reusing the designknowledge described in the design rationale network isa challenging issue. The DRed (Design Rationale Editor)system [41] is an option for reconstructing such rawdata to create design documents that explain thethought process.For requirement 4 (management of alternatives), we

developed a method of recording alternatives at eachstep with maintenance of logical consistency using theTMS and successfully supported the management of tra-deoffs among several alternatives.For requirement 5 (integration with external tools),

the system can be connected to external tools andimport 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 pro-posed method and integration with 3D-CAD system toeffectively link lifecycle scenarios with product design.

8 Competing interestsThe authors declare that they have no competinginterests.

9 Authors’ contributionsThe work presented here was carried out in collabora-tion between all authors. YU defined the research themeand designed the scenario description method for end-of-life strategic planning. SF co-designed the methodand case study, interpreted the result of the case study,and wrote the paper. KY 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.

Received: 16 January 2011 Accepted: 17 January 2012Published: 17 January 2012

References1. Alting L, Jorgensen J: The Life Cycle Concept as a Basis for Sustainable

Industrial Production. Annals of the CIRP 1993, 42(1):163-166.2. Fukushige S, Inoue Y, Tonoike K, Umeda Y: Design Methodology for

Modularity Based on Life Cycle Scenario. International Journal ofAutomation Technology 2009, 3(1):40-48.

3. Kobayashi H: Strategic Evolution of Ecoproducts: a Product Life CyclePlanning Methodology. Research in Engineering Design 2005, 16:1-16.

4. Akao Y: QFD: Quality Function Deployment-Integrating Customer Requirementsinto Product Design Productivity Press; 1990.

5. Wenzel H, Hauschild M, Alting L: Environmental Assessment of ProductsChapman & Hall, London; 1997.

6. Kwak M, Kim HM: Evaluating End-of-Life Recovery Profit by aSimultaneous Consideration of Product Design and Recovery NetworkDesign. Journal of Mechanical Design, ASME 2010, 132(7), 071001.

7. Phang KF, Senin N, Wallace DR: Distribution modeling and evaluation ofproduct design problems. Computer-Aided Design 1998, 30(6):411-423.

8. Rao RV, Padmanabhan KK: Selection of best product end-of-life scenariousing digraph and matrix methods. Journal of Engineering Design 2010,21(4):455-472.

9. Rose CM, Masui K, Ishii K: How product characteristics determine end-of-life strategies. Proceedings of the 1998 IEEE International Symposium onElectronics and the Environment 1998, 322-327.

10. Ostlin J, Sundin E, Bjorkman M: Product life-cycle implications forremanufacturing strategies. Journal of Cleaner Production 2009,17(11):999-1009.

11. Sudarsan R, Fenves SJ, Sriaram RD, Wang F: A product informationmodeling framework for product lifecycle management. Computer-aideddesign 2005, 37(13):1399-1411.

12. Srinvasan V: An integration framework for product lifecycle management.Computer-aided design 2008, 43(5):464-478.

13. Alemanni M, Destefanis F, Vezzetti E: Model-based definition design in theproduct lifecycle management scenario. The International Journal ofAdvanced Manufacturing Technology 2011, 52(1-4):1-14.

14. Zussman E, Kriwet A, Seliger G: Disassembly-Oriented AssessmentMethodology to Support Design for Recycling. Annals of the CIRP 1994,43(1):9-14.

15. Masanet E, Auer R, Tsuda D, Barillot T, Baynes A: An assessment andprioritization of “design for recycling” guidelines for plastic components.Proceedings of the 2002 IEEE International Symposium on Electronics and theEnvironment 2002, 5-10.

16. Steinhilper R: Remanufacturing-The Ultimate Form of Recycling FraunhoferIRB Verlag; 1998.

17. Bras B, Hammond R: Towards design for remanufacturing-metrics forassessing remanufacturing. Proceedings of the 1st International Workshopon Reuse 1996, 5-22.

18. Ijomah W, McMahon C, Hammond G, Newman S: Development of robustdesign-for-remanufacturing guidelines to further the aims of sustainabledevelopment. International Journal of Production Research 2007,45:4513-4536, Nos. 18 & 19.

19. Dhillon BS: Engineering Maintainability: How to Design for Reliability and EasyMaintenance Gulf Professional Publishing; 1999.

20. Desai A, Mital A: Design for maintenance: basic concepts and review ofliterature. International Journal of Product Development 2006, 3(1):77-121.

21. Hiroshige Y, Ohashi T, Aritomo S, Suzuki K: Development ofDisassemblability Evaluation Method. Proceedings of the 8th InternationalConference on Production Engineering 1997, 457-466.

22. Duflou JR, Seliger G, Kara S, Umeda Y, Ometto A, Willems B: Efficiency andfeasibility of product disassembly: A case-based study. Annals of the CIRP2008, 57(2):583-600.

23. Seliger G, Zettl M: Modularization as an enabler for cycle economy.Annals of the CIRP 2008, 57(1):133-136.

Table 3 Process parameters for simulation (excerpt)

Process Parameter Parameter value

Disassembly Labor cost 1,800 yen/hour

Assembly time 5 sec/connection

Inspection Inspection cost 50 yen/unit

Inspection CO2 emission 0.001 kg/unit

Case recycling Recycling cost 0.3 yen/kg

Recycling CO2 emission 0.09 kg-CO2/kg

Battery recycling Recycling cost 0.2 yen/kg


Board recycling Recycling cost 0.2 yen/kg


Landfill Landfill cost 78 yen/kg

Landfill CO2 emission 0.01 kg-CO2/kg


Page 14 of 15

24. Fukushige S, Tonoike K, Inoue Y, Umeda Y: Scenario Based Modularizationand Evaluation for Lifecycle Design. Proceedings of the ASME 2009International Design Engineering Technical Conference & the Computers andInformation in Engineering Conference (IDETC/CIE 2009) 2009, DETC2009/DFMLC-87394.

25. Duflou JR, Seliger G, Kara S, Umeda Y, Ometto A, Willems B: Efficiency andfeasibility of product disassembly: A case-based study. Annals of the CIRP2008, 57(2):583-600.

26. Shimomura Y, Hara T, Arai T: A Unified Representation Scheme forEffective PSS Development. Annals of the CIRP 2009, 58(1):379-382.

27. Meier H, Massberg W: Life Cycle-based Service Design for InnovativeBusiness Models. Annals of the CIRP 2004, 53(1):335-338.

28. Takeda H, Veerkamp P, Tomiyama T, Yoshikawa H: Modeling DesignProcesses. AI Magazine 1990, 11(4):37-48.

29. Moran TP, Carroll JM: Design Rationale: Concepts, Techniques, and Use CRCPress; 1996.

30. Janz D, Sihn W: Product Redesign Using Value-Oriented Life CycleCosting. Annals of the CIRP 2005, 54(1):9-12.

31. Sutherland JW, Gunter KL: A Model for Improving Economic Performanceof a Demanufacturing System for Reduced Product End-of-LifeEnvironmental Impact. Annals of the CIRP 2002, 51(1):45-48.

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 DisposalCause Analysis Matrix. Proceedings of the 14th International Conference onEngineering Design (ICED03) 2003.

33. Umeda Y, Daimon T, Kondoh S: Life cycle option selection based on thedifference 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 EvaluationMethod for Supporting Life Cycle Design. Proceedings of the 6thInternational Conference on EcoBalance 2004, 43-46.

35. Umeda Y, Nonomura A, Tomiyama T: Study on Life-cycle Design for thePost Mass Production Paradigm. AIEDAM 2000, 14(2):149-161.

36. Schmuller J: Sams Teach Yourself UML in 24 Hours Sams Publishing; 2004.37. Doyle J: A Truth Maintenance System. Artificial Intelligence 1979, 12:231-27.38. Conklin J, Begeman ML: gIBIS: A Hypertext Tool for Exploratory Policy

Discussion. ACM Transactions on Office Information Systems 1988,6(4):303-331.

39. Counsell J, Porter I, Dawson D, Duffy M: Schemebuilder: computer aidedknowledge based design of mechatronic systems. Assembly Automation1999, 19(2).

40. Nomaguchi Y, Fujita K: An Integrated Framework for AdvancedKnowledge-based Design Support-A Viewpoint of DRIFT Paradigm.Proceedings of the 7th IJCC Japan-Korea CAD/CAM Workshop 2007, 70-75.

41. Bracewell RH, Gourtovaia M, Moss M, Knott D, Wallace KM, Clarkson PJ:Dred 2.0: A method and tool for capture and communication of designknowledge deliberated in the creation of technical products. Proceedingsof the 17th International Conference on Engineering Design (ICED’09) 2009,223-234.

doi:10.1186/2210-4690-2-1Cite this article as: Fukushige et al.: Lifecycle scenario design forproduct end-of-life strategy. Journal of Remanufacturing 2012 2:1.

Submit your manuscript to a journal and benefi t from:

7 Convenient online submission

7 Rigorous peer review

7 Immediate publication on acceptance

7 Open access: articles freely available online

7 High visibility within the fi eld

7 Retaining the copyright to your article

Submit your next manuscript at 7 springeropen.com


Page 15 of 15

http://www.springeropen.com/

http://www.springeropen.com/

Documents

RESEARCH Open Access Lifecycle scenario design for product ... · stages of lifecycle design, the requirements for product and process design need to be clarified. This require-ment