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.

Figure 1
figure 1

Lifecycle design process.

Full size image

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 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 [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 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 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.

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.

Figure 2
figure 2

Product structure model.

Full size image

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.

Figure 3
figure 3

Lifecycle flow model.

Full size image
Figure 4
figure 4

Relationship between the structure and flow models.

Full size image

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.

Figure 5
figure 5

Design rationale network.

Full size image

The description process here assumes that the designer identifies problems to be solved (such as the selection of plausible lifecycle options) at each step of the process (the horizontal gray line in Figure 5), then proposes solution candidates and gives design reasons for them. These reasons are derived from the designer's knowledge, references and results from external tools, and are related to the candidate nodes by positive or negative causality links. Next, the designer evaluates the candidates, which also results in positive or negative links from the design reason nodes.

Design reason nodes and solution candidate nodes have either a valid or an invalid state. The state is changed to invalid by negative causality links, and thus invalidated nodes cannot affect other nodes. In Figure 5, the invalidated nodes are greyed out. The designer selects one or more solutions from among the valid candidate nodes, and the selected candidates are changed to selected solution nodes. The designer cannot select two nodes connected by antinomy link.

Based on the selected solutions, the designer also proposes solution candidates at the next step and chooses solutions from among them. The nodes are connected by causality links from the previous step's nodes. As a result of these processes, the design rationale of the scenario is represented as a network of these alternative nodes. Having the designer construct this network provides a record of the thought processes and grounds on which the design is based.

4.2 Management of alternatives

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.

Figure 6
figure 6

Design rationale network and TMS structure.

Full size image

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.

Figure 7
figure 7

Management of alternatives.

Full size image

4.3 Process of lifecycle scenario description

Here we propose a process for lifecycle scenario description. First, the designer analyses and describes the product's characteristics and related market information in a workspace in the form of design reason nodes. Next, the designer step-wisely describes a lifecycle scenario from the lifecycle objectives to the lifecycle situations defined in Section 3. At each step, the designer describes the scenario with design reason nodes and solution candidate nodes in the design rationale network, and may use external tools to validate or invalidate the nodes via positive or negative causality links. In such cases, results from external tools are represented as such in design reason nodes. For example, the suitability of material recycling may be evaluated using a tool such as the Lifecycle Planner [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.

Figure 8
figure 8

Prototype system architecture.

Full size image
Figure 9
figure 9

Screenshot of the workspace.

Full size image
Figure 10
figure 10

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

Full size image

6 Case study

6.1 Describing a lifecycle scenario for a cell phone

Here we describe a lifecycle scenario for a cell phone using the prototype system as a case study. The phone consists of a printed circuit board (PCB), a CCD camera unit, a vibrator, a speaker unit, a battery, cases, a microphone unit and a liquid crystal display (LCD) unit.

First, we analyzed the current lifecycle of the phone and constructed a lifecycle flow model to enable assessment of its environmental loads and profit through lifecycle simulation. Based on the results of this analysis, we described the product's characteristics and market information in the design reason nodes of the workspace. In addition to these fact nodes, we also included assumption node notes such as 'Higher-level CO2 reduction will be required to comply with new regulations this year.' Based on the design reasons, we set the lifecycle objective as 'to reduce CO2 emissions without reducing current profit,' and, as a parameter value for the objective, the manufacturer's profit was set as 'more than 100% of that of the current lifecycle.' Here, in order to examine several possibilities for achieving the objective, two CO2 reduction rates of 20% and 10% were set, and the 20% rate was selected first. These two candidates were connected with a contradictory link to avoid selection of both nodes as a conclusion.

Second, we determined the lifecycle concepts. Here, we derived the four concepts of long life, reuse business, waste reduction and the current recycling scenario as solution candidates. From among these candidates, reuse business was selected as a solution for the lifecycle concept based on the facts and assumptions described in the workspace.

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.

Figure 11
figure 11

Design rationale network for Scenario A.

Full size image

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 CO2 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.

Table 1 Scenario assessment
Full size table

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 CO2 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.

Figure 12
figure 12

Design rationale network for Scenario B.

Full size image
Figure 13
figure 13

Lifecycle flow for Scenario B.

Full size image

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.

Table 2 Design requirements
Full size table

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 CO2 emissions for all processes in the lifecycle. Table 3 shows some of the process parameters used in the simulation model.

Table 3 Process parameters for simulation (excerpt)
Full size table

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.