Báo cáo toán học: " Lifecycle scenario design for product end-of-life strategy" potx

This Provisional PDF corresponds to the article as it appeared upon acceptance. Fully formatted
PDF and full text (HTML) versions will be made available soon.
Lifecycle scenario design for product end-of-life strategy
Journal of Remanufacturing 2012, 2:1 doi:10.1186/2210-4690-2-1
Shinichi Fukushige ()
Kazuhiro Yamamoto ()
Yasushi Umeda ()
ISSN 2210-4690
Article type Research
Submission date 16 January 2011
Acceptance date 17 January 2012
Publication date 17 January 2012
Article URL />This peer-reviewed article was published immediately upon acceptance. It can be downloaded,
printed and distributed freely for any purposes (see copyright notice below).
For information about publishing your research in Journal of Remanufacturing go to
/>For information about other SpringerOpen publications go to

Journal of Remanufacturing
© 2012 Fukushige et al. ; licensee Springer.
This is an open access article distributed under the terms of the Creative Commons Attribution License ( />which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.
1
Lifecycle scenario design for product end-of-life strategy


Shinichi Fukushige, Kazuhiro Yamamoto and Yasushi Umeda
Graduate School of Engineering, Osaka University, Osaka, Japan


Abstract
This paper proposes a method for supporting the design of product lifecycles. The main approach involves
supporting designers in determining a lifecycle strategy by describing lifecycle scenarios at an early stage of

lifecycle design. The authors define a representational scheme for the lifecycle scenario and outline a support
system based on the idea of the Cognitive Design Process model allowing the designers to examine various
possibilities of lifecycle strategy. A number of alternative scenarios are managed by the Truth Maintenance
System implemented in this approach. Finally, in order to embody the strategy in the later stages, the system
derives requirements for product and process design. This paper outlines the lifecycle scenario of a cellular
phone as a case study, which indicates the system’s suitability for computer-aided description of scenarios and
its facilitation of lifecycle strategy development.
Keywords: lifecycle design, end-of-life strategy, lifecycle scenario

1 Introduction
Promising approaches for sustainable development involve the construction of stable product lifecycle
systems that drastically reduce environmental loads, resource consumption and waste generation while
increasing living standards and corporate profits. The design of a product lifecycle includes the steps of
modeling the lifecycle itself, evaluating it from various viewpoints, and pinpointing solutions to optimize the
lifecycle as a whole [1]. We previously proposed the lifecycle design process [2] shown in Figure 1. First,
designers analyze the current state of the product and its market, and determine the product concept, business
strategies and environmental targets based on the results of this analysis. Second, the designers formulate a
lifecycle strategy according to the product concept, business strategy and environmental targets. Third, the
designers design the product and its various lifecycle processes in line with the strategy. Finally, the designers
evaluate the whole lifecycle of the product to confirm the feasibility of the strategy. In short, the lifecycle
strategy is planned from the early stages, and the product is designed to realize the strategy.
To support the strategy planning stage, this paper proposes a method of describing product lifecycle
scenarios by which designers can explicitly determine lifecycle strategies. Here, the lifecycle strategy is
defined as a combination of lifecycle options (e.g., maintenance, product reuse, component reuse, closed-loop
recycling and cascade recycling) for a product and its components, and the lifecycle scenario is a description
of the expected product lifecycle. In other words, by describing the lifecycle scenario, designers can easily
identify appropriate lifecycle options and requirements for product and process design in the later stages of
lifecycle design.
Some studies have focused on support for lifecycle strategy planning. Kobayashi [3] proposed a lifecycle
planning methodology that supports lifecycle option selection on the part level through analysis based on

QFD [4] and lifecycle assessment [5]. Kwak et al. proposed a method of evaluating end-of-life recovery profit
by considering both product design and recovery network design [6]. Phang et al. proposed a design method
that includes end-of-life strategy design by evaluating the product lifecycle in Distributed Object-oriented
Modeling and Environment (DOME) [7]. Rao et al. proposed an end-of-life scenario selection method to
optimize multiple parameters related to a product lifecycle by utilizing a directed graph [8]. Rose et al.
outlined an approach for determining appropriate end-of-life strategies based on product characteristics such
as a product’s life span and the rate of technological innovation in products [9]. Ostlin et al. proposed the
inclusion of product lifecycle consideration in remanufacturing strategies [10]. As these methods mainly focus
on the selection of optimal processes and parameters from the specific aspect of product lifecycle, they are not
ideal for examining and comparing various lifecycle possibilities from different viewpoints.
Product lifecycle management (PLM) is a challenging issue in this research field [11, 12]. As a recent
example, Alemanni et al. introduced model-based definition (MBD) [13] into PLM. With MBD, most product
lifecycle data are structured inside CAD models rather than being scattered in different forms throughout the
2

PLM database. Although such product lifecycle data management and integration methods help to eliminate
redundant documentation and increase product data accessibility, they do not focus on support for lifecycle
design. In other words, PLM systems do not provide product lifecycle models that enable explicit design.
A number of studies have also addressed environmentally conscious product design technologies;
examples include design for recycling [14, 15], remanufacturing/reuse [16, 17, 18], maintenance [19, 20] and
ease of disassembly [21, 22]. In this area, modular design methods have been studied for ease of manufacture
and assembly [23]. Modular design is also useful in enabling all lifecycle options such as remanufacturing,
maintenance, reuse and recycling (e.g., [24]). By way of example, Duflou et al. [25] pointed out that modular
design is an indispensable critical driver in the remanufacture of single-use cameras. However, the
relationships and trade-offs between these design methods have not been clarified, and no design environment
integrates these eco-design technologies based on end-of-life strategies. Support for decision making in this
area is also needed.
Design methodologies for product service systems have also been eagerly studied [26, 27]. From the
viewpoint of lifecycle design, servicizing is a strong enabler of lifecycle strategies, and describing lifecycle
scenarios is also useful in setting targets for servicization. However, no computational representation of

lifecycle scenarios has yet been established, meaning that there is no computational support tool for
describing lifecycle scenarios including product service system.
The objectives of this study are to propose a scheme for representing the lifecycle scenario and its
description process and to develop a description/management support system for examining various lifecycle
strategy possibilities and clarifying requirements for product and process design. One of the main
contributions of the study is its definition of scenarios as computational lifecycle models that enable the
design, visualization and evaluation of the whole product lifecycle.
2 Requirements for the lifecycle scenario design system
As outlined above, environmentally conscious product design should be executed after an appropriate
lifecycle strategy has been planned, and describing lifecycle scenarios is a promising approach to clarifying
such a strategy. In determining a lifecycle strategy, designers should consider the business plan,
environmental targets to be met, and the product concept to provide value to customers.
To support such design, we sought to formulate a workspace that will allow designers to examine various
scenarios using a description support system. To this end, we identified five requirements for the system:
1． Support for the description and examination of various plausible lifecycle scenarios: As environmental
issues are typically poorly structured problems that require lifecycle consideration from various
viewpoints, the system should support designers in examining various plausible scenarios. To this end,
Sections 3 and 4 propose a representational scheme for scenarios and the related description process.
2． Clarification of requirements for product and process design: To embody the lifecycle strategy in the later
stages of lifecycle design, the requirements for product and process design need to be clarified. This
requirement is met in the representational scheme through the product structure model, lifecycle flow
model and the process parameters detailed in Section 3.
3． Explicit representation of the design rationale throughout the scenario description process: The lack of
general criteria for environmentally friendly products means that manufacturers must declare why a
product is promoted as having environmental merits. One way of doing this is to express the rationale of
decisions made by the designers during lifecycle design. Accordingly, the reasons behind the designers’
decisions are recorded to clarify the design rationale, which is represented using the cognitive design
process model [28] described in Section 4.1. Moreover, as previously discussed in relation to research on
design rationale (e.g., [29]), this approach is useful for reusing design knowledge.
4． Management of alternatives: At each step in the scenario description process, the designers generate and

choose alternatives. To support the design process, the system should therefore be capable of
appropriately managing these design alternatives. This management method is outlined in Section 4.2.
5． Integration of results from lifecycle design support tools: The scenario description support system should
not be closed. Rather, it assumes that the designers generate alternatives and make decisions using
3

various lifecycle design support tools. Examples include evaluation methods based on lifecycle cost [30,
31], lifecycle option selection support tools (e.g., Disposal Cause Analysis [32] and the product lifetime
prediction method [33]), lifecycle assessment (LCA) [5] and lifecycle simulation (LCS) [34, 35].
Accordingly, the system should be able to import the results of these external support tools.
3 Lifecycle scenario representation
A lifecycle scenario represents all the scenes of a product lifecycle in terms of 5W1H expression (who, where,
what, why, when and how). In this paper, the lifecycle scenario definition is based on the following five
elements:
1． Lifecycle objective: Declaring the objective of the lifecycle is important in clarifying the targets and
criteria for scenario evaluation. Here, the objective is represented in verbal form and by target parameter
values. An example would be the objective statement ‘To keep the manufacturer in profit and to halve
CO
2
emissions’ combined with the parameter values of ‘profit: more than 100%’ and ‘CO
2
emissions:
reduction exceeding 50%.’
2． Lifecycle concept: Our preliminary study showed that it was difficult for designers to directly formulate a
lifecycle scenario based on lifecycle objectives alone. Accordingly, we introduced the lifecycle concept,
which indicates the basic direction for the construction of a scenario (such as extending product life or
increasing the efficiency of recycling) as a bridge between the objective and the selection of lifecycle
options.
3． Lifecycle options: The lifecycle options of a product and its components determine the basic structure of
scenarios. In order to manage combinations of lifecycle options and product components, product

structure model is introduced as shown in Figure 2. In this model, each node represents a product’s
component and is related to its applied lifecycle option. For example, ‘To be reused in the first life, then
recycled in the second life’ might be used to describe the lifecycle options of a component, and the
combination of options is related to the corresponding node of the product structure model.
4． Lifecycle flow: This is the central model of the lifecycle scenario, and represents the flow of products,
components, materials, information and money in the form of a lifecycle process network. Each lifecycle
process of the flow model has the inputs and outputs of the process (such as the income and expenditure
of the process stakeholder) to allow lifecycle evaluation from environmental and economic viewpoints
using the LCS. Figure 3 shows an example of lifecycle flow, where component A is reused and
component B is recycled. It is also related to the product structure model, as shown in Figure 4. The
system manages the relationship between the component nodes of a product structure model and the
process nodes of a lifecycle flow model. As a result, a flow model clarifies the requirements for the later
stages of lifecycle design.
5． Situation: Each lifecycle process is described as a ‘situation’ using 5W1H expression. The design
requirements for situations are also described, and the ‘How’ part is represented in UML (Unified
Modeling Language) [36] for formalization.
4 Scenario design process
4.1 Representation of design rationale
To represent the designer’s decisions explicitly, this paper outlines the scenario description process through
extension of the cognitive design process model [28].
As shown in Figure 5, all information provided by the designer is classified into the three categories of
design reasons, solution candidates and selected solutions. The nodes are related to each other by positive,
negative or antinomy causality links. The design reason node includes the four subtypes of fact, assumption,
result from an external tool (denoting an evaluation result obtained from an external tool as described in
Section 2) and requirement, which represents a design aspect required for realization of the lifecycle scenario.
The candidate nodes and solution nodes have links to the scenario elements described in Section 3, and the
design reason nodes have detailed descriptions or links to references and external tools.
The description process here assumes that the designer identifies problems to be solved (such as the
4

selection of plausible lifecycle options) at each step of the process (the horizontal gray line in Figure 5), then
proposes solution candidates and gives design reasons for them. These reasons are derived from the
designer’s knowledge, references and results from external tools, and are related to the candidate nodes by
positive or negative causality links. Next, the designer evaluates the candidates, which also results in positive
or negative links from the design reason nodes.
Design reason nodes and solution candidate nodes have either a valid or an invalid state. The state is
changed to invalid by negative causality links, and thus invalidated nodes cannot affect other nodes. In Figure
5, the invalidated nodes are greyed out. The designer selects one or more solutions from among the valid
candidate nodes, and the selected candidates are changed to selected solution nodes. The designer cannot
select two nodes connected by antinomy link.
Based on the selected solutions, the designer also proposes solution candidates at the next step and
chooses solutions from among them. The nodes are connected by causality links from the previous step’s
nodes. As a result of these processes, the design rationale of the scenario is represented as a network of these
alternative nodes. Having the designer construct this network provides a record of the thought processes and
grounds on which the design is based.
4.2 Management of alternatives
As designers need to examine various tradeoffs in describing a lifecycle scenario as detailed in Section 2, it is
necessary to manage various alternatives (solution candidates) at each step of the process. To examine the
various possibilities involved, the designer switches the selected solutions among the candidate nodes as
shown in Figure 6. Such alternatives are associated with the alternatives of the former and later steps in the
design rationale network.
In this study, node relationship management was based on the Truth Maintenance System (TMS) [37],
which is a knowledge representation and management method for maintaining both knowledge (propositions)
and dependencies (Boolean constraints). In other words, it maintains logical consistency between current
knowledge and old knowledge in a knowledge network through revision.
Each node in the TMS network has the state of In or Out, representing the validity or invalidity of the
knowledge in a certain context. In this research, we employed a simple justification-based TMS mechanism to
manage all design alternatives. This maintains consistency among the solutions, candidates and design
reasons in the design rationale network defined in Section 4.1.
In the context of decision support systems for engineering design, gIBIS (graphical Issue-Based

Information System) [38] is used to represent dependencies among problems and alternatives by creating a
tree structure as an argumentation model. Schemebuilder [39] and DRIFT (Design Rationale Integration
Framework of Three layers) [40] also enable the management of a wide range of engineering design
alternatives using the TMS for computer-aided knowledge-based design.
Our system mainly focuses on the construction of lifecycle models, and provides a framework that
integrates the lifecycle design support tools described in Section 2. In accordance with the manual
construction and revision of the design rationale network, a TMS structure is created and updated
automatically in the background. Figure 7 shows a TMS structure corresponding to a design rationale
network. Network consistency is maintained by revising the state of the nodes in the logical structure. In other
words, the valid/invalid state of the nodes in this network corresponds to the In/Out state of the nodes in the
TMS structure. For example, the state of a node becomes Out when the node is supported by In-state nodes
via negative links. This structure further introduces the two node types of selection and contradiction. A
selection node represents a designer’s selection or rejection from among the solution candidate nodes, while a
contradiction node corresponds to an antinomy link and disables the simultaneous selection of two nodes
connected by such a link. When the state is changed or a new node is added, the TMS mechanism backtracks
through the causality connections, and if a contradiction is found, the node responsible is identified and
changed to an appropriate state. As a result, a variety of alternatives can be managed effectively.

4.3 Process of lifecycle scenario description
Here we propose a process for lifecycle scenario description. First, the designer analyses and describes the
5

product’s characteristics and related market information in a workspace in the form of design reason nodes.
Next, the designer step-wisely describes a lifecycle scenario from the lifecycle objectives to the lifecycle
situations defined in Section 3. At each step, the designer describes the scenario with design reason nodes and
solution candidate nodes in the design rationale network, and may use external tools to validate or invalidate
the nodes via positive or negative causality links. In such cases, results from external tools are represented as
such in design reason nodes. For example, the suitability of material recycling may be evaluated using a tool
such as the Lifecycle Planner [3]. The proposed method places focus on providing the designer with a
workspace for examining various scenario alternatives by incorporating a range of external tools.

In this method, it is assumed that the designer evaluates the scenario using external tools after the
lifecycle flow has been constructed. Here, we employ lifecycle simulation, which enables lifecycle evaluation
in terms of environmental loads, material balance and monetary benefits. As the main simulation model for
the lifecycle simulator involves the lifecycle flow defined in Section 3, the scenario can be evaluated directly
and interactively after flow model creation. The designer should specify situations for the simulation in each
process of the lifecycle flow.
The designer repeats this cycle until all lifecycle objectives are achieved. If no such solution is found, the
designer reviews the design of the scenario and its conditions (i.e., the lifecycle concepts, options, flow and
related process parameters). Lifecycle objectives can also be targets of revision. Finally, the designer extracts
the requirements and conditions from the requirement nodes in the design rationale network and the process
parameters in the lifecycle flow for product and process design in the later stages.
5 Prototype system
We developed a prototype system based on the proposed method (see Figure 8 for an outline of the system
architecture). The designers describe a lifecycle scenario using the individual sub-tools provided (objective
description tool, lifecycle concept description tool, lifecycle option selection tool, lifecycle flow modeler,
process situation modeler and product structure modeler), and the lifecycle scenario manager integrates these
sub-tools. The design rationale manager provides a workspace for constructing a design rationale network,
and the alternative manager maintains the consistency of the network using TMS as described in Section 4.
There are also two databases to support the construction of lifecycle flow and product structure model. Figure
9 shows a screenshot of the workspace in which the individual scenario components (lifecycle objective,
concepts, options, flow, process details and product structure) are edited. These components are linked to the
corresponding nodes of the design rationale network and the relationship of the components is managed in the
network. The lifecycle flow model is further related to the product structure model as described in Section 3.
In other words, the system integrates the two models to enable visualization and management of which
product’s parts pass through which processes of the flow model. Figure 10 shows an example of the
parameters of a process in a flow model. Each process has given parameters, input parameters, output
parameters and procedures. Some input parameters are imported from a product structure model that holds
information on the attributes of the product’s components, such as its constituent materials, weight, volume
and lifetime.
6 Case study

6.1 Describing a lifecycle scenario for a cell phone
Here we describe a lifecycle scenario for a cell phone using the prototype system as a case study. The phone
consists of a printed circuit board (PCB), a CCD camera unit, a vibrator, a speaker unit, a battery, cases, a
microphone unit and a liquid crystal display (LCD) unit.
First, we analyzed the current lifecycle of the phone and constructed a lifecycle flow model to enable
assessment of its environmental loads and profit through lifecycle simulation. Based on the results of this
analysis, we described the product’s characteristics and market information in the design reason nodes of the
workspace. In addition to these fact nodes, we also included assumption node notes such as ‘Higher-level CO
2

reduction will be required to comply with new regulations this year.’ Based on the design reasons, we set the
lifecycle objective as ‘to reduce CO
2
emissions without reducing current profit,’ and, as a parameter value for
the objective, the manufacturer’s profit was set as ‘more than 100% of that of the current lifecycle.’ Here, in
6

order to examine several possibilities for achieving the objective, two CO
2
reduction rates of 20% and 10%
were set, and the 20% rate was selected first. These two candidates were connected with a contradictory link
to avoid selection of both nodes as a conclusion.
Second, we determined the lifecycle concepts. Here, we derived the four concepts of long life, reuse
business, waste reduction and the current recycling scenario as solution candidates. From among these
candidates, reuse business was selected as a solution for the lifecycle concept based on the facts and
assumptions described in the workspace.
Third, we selected lifecycle options. For the LCD, for example, we examined reuse, cascade material
recycling and appropriate disposal options as alternatives. From among them, we selected the reuse option in
consideration of longer physical life for the LCD in line with the results of the Disposal Cause Analysis
external tool [32]. However, according to the market analysis performed in the first step, the size and function

of LCDs vary by cell phone type, making stable reuse difficult. This negated the reuse option, and cascade
material recycling was therefore selected as the alternative lifecycle option for the LCD. Disposal Cause
Analysis also positively supported the reuse option for the speaker, the vibrator and the CCD camera, but
negated the reuse option for the battery and the case because of their short lives. As a result, the speaker was
set to be reused in the first life and then cascade-recycled in the second life. Figure 11 partially depicts the
design rationale network for the case described in the workspace.
Fourth, we evaluated this scenario (Scenario A) based on lifecycle simulation. The lifecycle flow model
constructed in the first step was revised for adaptation to the described scenario. The results of the evaluation
indicated that, while the profit satisfies the objective value of more than 100%, the reduction of CO
2

emissions does not fulfill either of the objectives as shown in Table 1. Furthermore, the reuse option for the
speaker and the CCD camera is not feasible due to the lack second-hand markets for such parts.
To solve this problem, we modified the scenario to create Scenario B, in which the reuse option is
selected for the LCD and PCB instead of the cascade material recycling option because the lifecycle
simulation revealed that these components have higher CO
2
reduction potential in the manufacturing process.
However, as noted in the design reasons, the functional diversity and frequent restyling of such parts eliminate
the potential for their stable reuse. To address this contradiction, we added the lifecycle concept of
remanufacturing (in which cell phones are restored to as-new condition through repair or replacement of cases
and butteries) and changed the lifecycle flow. As remanufactured phones are not fully equivalent to original
new products, we set their price and market size to 60% and 30% of those of a brand-new product,
respectively. These rates were taken as suppositions for trial calculation of profit. Additionally, Scenario B
involves an attempt to improve the collection rate of old cell phones to 80% by providing customers with a
data-backup service and a trade-in service in the new business flow, which was noted in the form of additional
requirement nodes in the design rationale network. This network for Scenario B is partially depicted in Figure
12, which shows the change in selected lifecycle options and the additional requirement nodes (in yellow).
These amendments remove the obstacles to remanufacturing concept. Figure 13 shows the lifecycle flow of
this remanufacturing-oriented scenario.

Table 1 compares the results of the lifecycle simulation for Scenarios A and B. As Scenario B satisfies all
the objectives, we chose it as the final scenario and completed the scenario description process. Table 2
summarizes the design requirements identified from this process extracted from the requirement nodes in the
design rationale network and the process parameters in the lifecycle flow model.
6.2 Characteristics of the method: description of the scenario review process
The design rationale network constructed in the case study had more than 50 nodes, allowing the system
developed to be used for the management of a number of alternatives by structuring them into a single
network. These nodes corresponded to a wide range of scenario components including lifecycle objectives,
concepts, options, flows and situations. The mutual connection of these components through causality links
facilitates identification of the design reasons on which the selection of alternatives in the scenario was based.
It was also possible to trace the origins (such as objectives, concepts and options) from which the lifecycle
strategy was derived. The variations in the lifecycle flow model were recorded in individual nodes, and their
revisions could be compared easily. The flow model and its constituent processes were utilized to compose a
simulation model with which the lifecycle simulator calculated the profit of the manufacturer and the CO
2

7

emissions for all processes in the lifecycle. Table 3 shows some of the process parameters used in the
simulation model.
In the case study, we set the price and market size of the remanufactured phone, and these values were
used as suppositions for the calculation of profit in the simulation. Such relationships between suppositions
and calculation results in the design rationale network served as records of trials for examining various
lifecycle scenario possibilities. It is a characteristic of the system that evaluation results from external tools
are recorded and related to condition values for evaluation in each design reason node. Although Scenario B
satisfied the all objectives, this result was based on the supposition values described in the design reason
nodes and the process parameters. Accordingly, if it is found that one of these values will be impossible to
implement at a later stage, the designer should return to the scenario design process and review/simulate the
scenario again with another supposition.

7 Summary and conclusions
The case study showed that lifecycle scenarios can be successfully represented using the representational
scheme outlined in this paper, and that the proposed method supports the description process. As a result, it is
confirmed that a designer can easily determine a lifecycle strategy by describing the lifecycle scenario, and
can derive design requirements for the later processes of lifecycle design.
Section 2 identified five requirements for the system, and requirements 1 and 2 are achieved by the
proposed representational scheme. We also proposed a process for breaking down a lifecycle scenario from
lifecycle objectives to a lifecycle situation that can be assessed with Lifecycle Simulation. This allows
designers to systematically detail plausible lifecycle strategies that satisfy the objectives by clarifying facts,
assumptions, solution candidates, decisions and design requirements.
In terms of requirement 3, the case study verified that the system can be used to appropriately record the
scenario description process to represent the design rationale. As discussed in Section 2, reusing the design
knowledge described in the design rationale network is a challenging issue. The DRed (Design Rationale
Editor) system [41] is an option for reconstructing such raw data to create design documents that explain the
thought process.
For requirement 4 (management of alternatives), we developed a method of recording alternatives at
each step with maintenance of logical consistency using the TMS and successfully supported the management
of tradeoffs among several alternatives.
For requirement 5 (integration with external tools), the system can be connected to external tools and
import their results into the external tool’s result node.
Future work will include the proposal of a reutilization mechanism for design rationale described in the
proposed method and integration with 3D-CAD system to effectively link lifecycle scenarios with product
design.

8 Competing interests
The authors declare that they have no competing interests.

9 Authors contributions
The work presented here was carried out in collaboration between all authors. Y.U defined the research theme
and designed the scenario description method for end-of-life strategic planning. S.F co-designed the method

and case study, interpreted the result of the case study, and wrote the paper. K.Y developed the scenario
description support system, carried out the case study, and analyzed the data. All authors have contributed to,
seen and approved the manuscript.

8

References
[1] Alting, L., Jorgensen, J., “The Life Cycle Concept as a Basis for Sustainable Industrial Production,”
Annals of the CIRP, Vol. 42, No. 1, pp. 163 – 166, 1993.
[2] Fukushige, S., Inoue, Y., Tonoike, K., Umeda, Y., “Design Methodology for Modularity Based on Life
Cycle Scenario,” International Journal of Automation Technology, Vol. 3, No. 1, pp. 40 – 48, 2009.
[3] Kobayashi, H., “Strategic Evolution of Ecoproducts: a Product Life Cycle Planning Methodology,”
Research in Engineering Design, Vol. 16, pp. 1 – 16, 2005.
[4] Akao, Y., QFD: Quality Function Deployment - Integrating Customer Requirements into Product Design,
Productivity Press, 1990.
[5] Wenzel, H., Hauschild, M., Alting, L., Environmental Assessment of Products, Chapman & Hall, London,
1997.
[6] Kwak, M., Kim, H. M., “Evaluating End-of-Life Recovery Profit by a Simultaneous Consideration of
Product Design and Recovery Network Design,” Journal of Mechanical Design, ASME, Vol. 132, No. 7,
071001, 2010.
[7] Phang, K. F., Senin, N., Wallace, D. R., “Distribution modeling and evaluation of product design
problems,” Computer-Aided Design, Vol. 30, No. 6, pp. 411 – 423, 1998.
[8] Rao, R. V., Padmanabhan, K. K., “Selection of best product end-of-life scenario using digraph and matrix
methods,” Journal of Engineering Design, Vol. 21, No. 4, pp. 455 – 472, 2010.
[9] Rose, C. M., Masui, K., Ishii, K., “How product characteristics determine end-of-life strategies,”
Proceedings of the 1998 IEEE International Symposium on Electronics and the Environment, pp. 322 –
327, 1998.
[10] Ostlin, J., Sundin, E., Bjorkman, M., “Product life-cycle implications for remanufacturing strategies,”
Journal of Cleaner Production, Vol. 17, No. 11, pp. 999 – 1009, 2009.
[11] Sudarsan, R., Fenves, S. J., Sriaram, R. D., Wang, F., “A product information modeling framework for

product lifecycle management,” Computer-aided design, Vol. 37, No. 13, pp. 1399 – 1411, 2005.
[12] Srinvasan, V., “An integration framework for product lifecycle management,” Computer-aided design,
Vol. 43, No. 5, pp. 464 – 478, 2008.
[13] Alemanni, M., Destefanis, F., Vezzetti, E., “Model-based definition design in the product lifecycle
management scenario,” The International Journal of Advanced Manufacturing Technology, Vol. 52, No.
1-4, pp. 1 – 14, 2011.
[14] Zussman, E., Kriwet, A., Seliger, G., “Disassembly-Oriented Assessment Methodology to Support
Design for Recycling,” Annals of the CIRP, Vol. 43, No. 1, pp. 9 – 14, 1994.
[15] Masanet, E., Auer, R., Tsuda, D., Barillot, T., Baynes, A., “An assessment and prioritization of "design
for recycling" guidelines for plastic components,” Proceedings of the 2002 IEEE International
Symposium on Electronics and the Environment, pp. 5 – 10, 2002.
[16] Steinhilper, R., Remanufacturing – The Ultimate Form of Recycling, Fraunhofer IRB Verlag, 1998.
[17] Bras, B., Hammond, R., “Towards design for remanufacturing-metrics for assessing remanufacturing,”
Proceedings of the 1st International Workshop on Reuse, pp. 5 – 22, 1996.
[18] Ijomah, W., McMahon, C., Hammond, G., Newman, S., “Development of robust design-for-
remanufacturing guidelines to further the aims of sustainable development,” International Journal of
Production Research, Vol. 45, Nos. 18 & 19, pp. 4513 – 4536, 2007.
[19] Dhillon, B. S., Engineering Maintainability: How to Design for Reliability and Easy Maintenance, Gulf
Professional Publishing, 1999.
[20] Desai, A., Mital, A., “Design for maintenance: basic concepts and review of literature,” International
Journal of Product Development, Vol. 3, No. 1, pp. 77 – 121, 2006.
[21] Hiroshige, Y., Ohashi, T., Aritomo, S., Suzuki, K., 1997, “Development of Disassemblability Evaluation
Method,” Proceedings of the 8th International Conference on Production Engineering, pp. 457 – 466.
[22] Duflou, J. R., Seliger, G., Kara, S., Umeda, Y., Ometto, A., Willems, B., 2008, “Efficiency and feasibility
of product disassembly: A case-based study,” Annals of the CIRP, Vol. 57 (2), pp. 583 – 600.
[23] Seliger, G., Zettl, M., “Modularization as an enabler for cycle economy,” Annals of the CIRP, Vol. 57,
No. 1, pp. 133 – 136, 2008.
[24] Fukushige, S., Tonoike, K., Inoue, Y., Umeda, Y., “Scenario Based Modularization and Evaluation for
9

Lifecycle Design,” Proceedings of the ASME 2009 International Design Engineering Technical
Conference & the Computers and Information in Engineering Conference (IDETC/CIE 2009),
DETC2009/DFMLC-87394, 2009.
[25] Duflou, J. R., Seliger, G., Kara, S., Umeda, Y., Ometto, A., Willems, B., “Efficiency and feasibility of
product disassembly: A case-based study,” Annals of the CIRP, Vol. 57, No. 2, pp. 583 – 600, 2008.
[26] Shimomura, Y., Hara, T., Arai, T., “A Unified Representation Scheme for Effective PSS Development,”
Annals of the CIRP, Vol. 58, No. 1, pp. 379 – 382, 2009.
[27] Meier, H., Massberg, W., “Life Cycle-based Service Design for Innovative Business Models,” Annals of
the CIRP, Vol. 53, No. 1, pp. 335 – 338, 2004.
[28] Takeda, H., Veerkamp, P., Tomiyama, T., Yoshikawa, H., “Modeling Design Processes,” AI Magazine,
Vol. 11, No. 4, pp. 37 – 48, 1990.
[29] Moran, T. P., Carroll, J. M., Design Rationale: Concepts, Techniques, and Use, CRC Press, 1996.
[30] Janz, D., Sihn, W., “Product Redesign Using Value-Oriented Life Cycle Costing,” Annals of the CIRP,
Vol. 54, No. 1, pp. 9 – 12, 2005.
[31] Sutherland, J. W., Gunter, K. L., “A Model for Improving Economic Performance of a Demanufacturing
System for Reduced Product End-of-Life Environmental Impact,” Annals of the CIRP, Vol. 51, No. 1,
pp. 45 – 48, 2002.
[32] Umeda, Y., Hijihara, K., Ono, M., Ogawa, Y., Kobayashi, H., Hattori, M., Masui, K., Fukano, A.,
“Proposal of Life Cycle Design Support Method using Disposal Cause Analysis Matrix,” Proceedings of
the 14th International Conference on Engineering Design (ICED03), 2003.
[33] Umeda, Y., Daimon, T., Kondoh, S., “Life cycle option selection based on the difference of value and
physical lifetimes for life cycle design,” Proceedings of the International Conference on Engineering
Design 2007, 2007.
[34] Inamura, T., Umeda, Y., Kondoh, S., Takata, S., “Proposal of Life Cycle Evaluation Method for
Supporting Life Cycle Design,” Proceedings of the 6th International Conference on EcoBalance, pp. 43
– 46, 2004.
[35] Umeda, Y., Nonomura, A., Tomiyama, T., “Study on Life-cycle Design for the Post Mass Production
Paradigm,” AIEDAM, Vol. 14 (2), pp. 149 – 161, 2000.
[36] Schmuller, J., Sams Teach Yourself UML in 24 Hours, Sams Publishing, 2004.
[37] Doyle, J., “A Truth Maintenance System,” Artificial Intelligence, Vol. 12, pp. 231 – 27, 1979.

[38] Conklin, J., Begeman, M. L., “gIBIS: A Hypertext Tool for Exploratory Policy Discussion,” ACM
Transactions on Office Information Systems, Vol. 6, No. 4, pp. 303 – 331, 1988.
[39] Counsell, J., Porter, I., Dawson, D., Duffy, M., “Schemebuilder: computer aided knowledge based design
of mechatronic systems,” Assembly Automation, Vol. 19, No. 2, 1999.
[40] Nomaguchi, Y., Fujita, K., “An Integrated Framework for Advanced Knowledge-based Design Support –
A Viewpoint of DRIFT Paradigm,” Proceedings of the 7th IJCC Japan-Korea CAD/CAM Workshop, pp.
70 – 75, 2007.
[41] Bracewell, R. H., Gourtovaia, M., Moss, M., Knott, D., Wallace, K. M., Clarkson, P. J., “Dred 2.0: A
method and tool for capture and communication of design knowledge deliberated in the creation of
technical products” Proceedings of the 17th International Conference on Engineering Design (ICED'09),
pp. 223 – 234, 2009.



10

Figure 1. Lifecycle design process
Figure 2. Product structure model
Figure 3. Lifecycle flow model
Figure 4. Relationship between the structure and flow models
Figure 5. Design rationale network
Figure 6. Design rationale network and TMS structure
Figure 7. Management of alternatives
Figure 8. Prototype system architecture
Figure 9. Screenshot of the workspace
Figure 10. Process parameters of a disassembly process in a lifecycle flow model
Figure 11. Design rationale network for Scenario A
Figure 12. Design rationale network for Scenario B
Figure 13. Lifecycle flow for Scenario B
Table 1. Scenario assessment

Profit CO
2
emissions
Current scenario (recycling first) 100% 100%
Scenario A (reuse first) 101% 99%
Scenario B (remanufacturing first) 102% 79%

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/product
Improve 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)

Table 3. Process parameters for simulation (excerpt)
Process Parameter Parameter value
Labor cost 1,800 yen/hour
Disassembly

Assembly time 5 sec/connection
Inspection cost 50 yen/unit
Inspection

Inspection CO
2
emission 0.001 kg/unit

Recycling cost 0.3 yen/kg
Case recycling

Recycling CO
2
emission 0.09 kg-CO
2
/kg
Recycling cost 0.2 yen/kg
Battery recycling

Recycling CO
2
emission 0.1 kg-CO
2
/kg
Recycling cost 0.2 yen/kg
Board recycling

Recycling CO
2
emission 0.3 kg-CO
2
/kg
Landfill cost 78 yen/kg
Landfill

Landfill CO
2
emission 0.01 kg-CO

2
/kg

11





Figure 1
"
"
"" "
Figure 2
" "
" "
"
" " " " "
"
"
Figure 3
" " "
Figure 4
"
"
Figure 5
Figure 6
Figure 7
" " " "
" " " "

" "
"
" "
"
" "
" "
" "
"
"
"
"
" "
"
"
"" " " "
"
Figure 8
"
" "
"
"
" "
"
"
"
" " " "
" " " ど "
"
" " " "
" " " ど "

Figure 9
"
"
"
Figure 10
Figure 11
Figure 12
Figure 13