No CrossRef data available.
Development of design methodology for upgradable products based on function–behavior–state modeling
Published online by Cambridge University Press: 07 October 2005
Abstract
Extending product life is one of the hopeful approaches to reduce the environmental issue, which is one of the most critical issues of today. However, many products are thrown away because of obsolescence of functions and their performance. Therefore, we should design products to be functionally upgradable. Moreover, such upgradable products may create business chances at later stages of product life cycles. The objective of this research is to propose a design methodology for upgradability. This methodology employs a functional modeling scheme, FBS modeling, because upgrade design is a distinctive application of functional design that aims at maximizing functional flexibility with minimal structural changes after the product is manufactured. Here, the functional flexibility refers to an ability of a product to adapt its functions to changes of user needs. This paper proposes and models design processes and design operations in the upgrade design. Especially, the methodology supports finding out candidates of modifications of the function structure and configuration of a platform, which is common structure of a product among several generations, and upgrade modules. One of its central issues of upgrade design is treatment of future uncertainty. For this purpose, we propose two design strategies: delayed selection of components, and expanding and shrinking platform. A prototype system and a case study of upgrade design for a vacuum cleaner are also illustrated. The case study indicates that the system succeeded in systematically supporting a designer to execute the design methodology. Regarding the functional design, as an extension of FBS modeling, this paper proposes a method to relate abstract entity concepts in FBS modeling to concrete components through a quantitative behavior model and range calculation, in addition to deployment of FBS modeling for the design methodology.
Keywords
Information
- Type
- Research Article
- Information
- Copyright
- © 2005 Cambridge University Press
1. INTRODUCTION
The environmental issue is one of the most critical issues in the present time. This problem is mainly caused by the current mass production of artifacts. The mass production inevitably makes products' lifetimes shorter to increase product sales, and this results in excessive consumption of natural resources and generation of wastes (Tomiyama, 1997). Design plays a crucial role in solving the environmental issues, because design can determine most properties of a product life and, therefore, a designer can design a product that drastically reduces emissions, natural resource consumption, and waste amount throughout a product life cycle. For example, although it is difficult and expensive to recycle a product that is not designed to be recycled, design for recyclability significantly eases recycling of a product. For this purpose, various design methodologies have been proposed; examples include design for disassembly (Jovane & Alting, 1993), design for recyclability (Hiroshige et al., 2001), end of life design (Ishii, 1999), and life-cycle planning (Kobayashi, 2001).
Extending product life is one of the hopeful approaches to reduce the environmental issues. This has been the central topic of maintenance engineering and design for reliability. However, there is not only physical lifetime, which the reliability theory deals with, but also value lifetime that terminates the life of a product; a product is thrown away because of obsolescence of functions and performance (e.g., computers and cellular phones), although the product might work well. Therefore, to extend product life, we should design products that have functional upgradability in addition to physically longer life. This will result in reducing both resource (material and energy) consumption and waste generation. At the same time, such upgradable products may create new business chances at later stages of a product life cycle, such as upgrading services, reuse of products, and remanufacturing of products (Tomiyama, 1997).
Upgrading is commonly practiced in software and highly modularized machines (e.g., computers). In the domain of machine tools, “retrofit,” which is a kind of upgrading, is practiced. However, design methodology for such upgradable products (let us call it upgrade design) has hardly been discussed, while similar ideas have been intensively discussed in the research area of product platform design (e.g., Fujita et al., 1999; Martin & Ishii, 2002). We will discuss the difference between upgrade design and product platform design in Section 3. Some advanced companies in manufacturing environmentally conscious products (e.g., Fuji Xerox, Japan) actually have general guidelines that include requirements for upgradability, such as to extend parts' life, to use standard parts, and to make parts replaceable. However, because designers design them in a trial and error manner, based on these guidelines, a systematized design methodology for upgradable products is strongly needed, especially in these companies.
The objective of this research is to propose a design methodology for upgradable products and to develop a design support system for upgradability. Here, because “upgrading” means changes of functions and their performance of a product after the product is shipped, upgrade design is a subproblem of functional design, of which the objective is to maximize functional flexibility with minimal structural changes. Here, functional flexibility refers to an ability of a product to adapt its functions to changes of user needs, because the manufacturing flexibility refers to the ability of a manufacturing system to adapt to changes of manufacturing needs. Therefore, this paper discusses the design methodology for upgradability as an engineering application and a methodological extension of the functional design, focusing on representation and manipulation of functions.
The rest of this paper is organized as follows. Section 2 briefly introduces a functional modeling scheme, function–behavior–state (FBS) modeling (Umeda et al., 1996), which we employ as the functional modeling infrastructure. Section 3 clarifies framework of the design methodology, with comparison of the product platform design, and introduces some basic approaches to develop the design methodology. Section 4 proposes and formalizes the process of the design methodology for upgradability based on the discussions in Section 3. Section 5 describes a prototype system and illustrates a case study, which makes a vacuum cleaner upgradable by using the prototype system. Section 6 discusses feasibility and issues of the proposed design methodology, and Section 7 concludes the paper.
2. FBS MODELING
For supporting upgrade design, representing and manipulating functions are essential, as discussed in the previous section. In this section, as a preparation for discussing the design methodology for upgradability, we briefly introduce FBS modeling (Umeda et al., 1996), which we employ as the functional modeling infrastructure.
Various approaches for supporting functional design have been proposed (Umeda & Tomiyama, 1997). Sembugamoorthy and Chandrasekaran (1986) are pioneers in functional modeling. Prabhakar and Goel (1998) proposed a structure–behavior–function (SBF) model and applied it to analogical design. Qian and Gero (1996) also proposed a functional modeling method applied to analogical design. They extended their approach to the “function–behavior–structure” framework1
Note that FBS modeling is different from their “function–behavior–structure” framework.
2.1. Representation of function in FBS modeling
FBS modeling defines a function as “a description of behavior abstracted by human through recognition of the behavior in order to utilize it” (Umeda et al., 1990), and represents it as an association of two concepts: symbol of human intention represented in the form of to do something, and behavior that can exhibit the function. Although the symbol is meaningful only to designers, this information, associated with its behavior, is essential for supporting design such as reuse of design results. Figure 1 represents the relationship among function, behavior, and state. In this figure, a function–behavior (F-B) relation, which associates a function symbol with a set of behaviors, represents a function. These F-B relations are subjective and many–many correspondent. This feature of F-B relations is essential for making upgrade design flexible. In contrast, behavior is defined as a transition of states along time and a behavior–state (B-S) relation relates a behavior to states by using physical knowledge. Here, a state is represented by entities, their attributes, and their structure.
The relationship among function, behavior, and state (adapted from Umeda et al., 1996).
2.2. FBS modeler
A functional design support system called “FBS modeler” (Umeda et al., 1996) implements the framework described in Section 2.1. Figure 2 illustrates a part of a design object model in the FBS modeler, of which the main function is “to charge drum,” which often appears in the design of photocopiers. The upper half of this figure represents a function hierarchy of this design object; for instance, the main function “to charge drum” is decomposed into functions “to rotate drum” and “to discharge voltage to drum.” The lower half of this figure represents behavior and states of the design object; for example, the function “to discharge voltage to drum” is performed by behaviors “electrical charging” and “electrical discharging” that occur on two entities “Drum” and “Discharger,” which are related with each other by a relation “Connection With A Space.” Although the function hierarchy is subjectively constructed by a designer, the representation of the behavior network, the lower half of the figure, is based on a Qualitative Process Theory (Forbus, 1984), and its consistency is managed by a computer environment, Knowledge Intensive Engineering Framework (KIEF; Yoshioka et al., 2004). Please refer to Yoshioka et al. (2004) for the representation and reasoning of the behavior network.
The FBS modeler (adapted from Umeda et al., 1996).
To support functional design in the FBS modeler, the modeler has two kinds of knowledge bases: a function prototype knowledge base, and a physical feature knowledge base. We have verified that these knowledge bases can be constructed reasonably (Umeda et al., 1996; Yoshioka et al., 2004). A function prototype in the former knowledge base represents a typical pattern of functions that often appears in a certain domain. Table 1 shows the scheme of the function prototype. Name is the symbol for representing the designer's intention. Decomposition describes feasible candidates for decomposing the function in the form of networks of subfunctions. The F-B Relations describe candidate embodiments of the function in the form of physical features to be described below.
Definition of function prototype
A physical feature is a building block consisting of entities and physical phenomena occurring on the entities (Tomiyama et al., 1992). An FBS modeler represents a physical feature as a network of three kinds of elements (we call them behavior nodes); entities, relations among entities, and physical phenomena (Yoshioka et al., 2004). Each physical feature is constructed by the designer in order to be a meaningful block for representing a function. For example, Figure 3 shows an example of the physical feature in which a phenomenon “Electrical Discharging” occurs between a discharger and a nonconductor related by the relation “Connection With A Space.”
An example of a physical feature (adapted from Umeda et al., 1996).
3. FRAMEWORK OF DESIGN METHODOLOGY FOR UPGRADABILITY
In this section, we clarify the framework of the design methodology for upgradability proposed in this paper and introduce some basic approaches to develop the design methodology.
Upgrading means manipulating a functional configuration of a product after the product is sold to a customer in order to adapt to changes of customer's needs. Manipulation of the functional configuration includes adding, removing, and replacing functions (e.g., adding a two-sided copying function to a photocopier), and increasing and decreasing performance of particular functions (e.g., increasing copying speed). Such upgrade manipulation might be executed as a part of maintenance of a product or remanufacturing of a disposed product. Upgrade design is to design a product in order to add upgradability. Some products could be upgraded even though they are not designed to be so. However, upgrade design is expected to realize more flexible and more systematic upgradability of products.
3.1. Two assumptions for the design methodology for upgradability
To formalize upgrade design, we introduce two assumptions. Although there might be some other upgrade design methodologies that have no upgrade plan or no platform, this paper deals with a methodology with these assumptions.
First, the design methodology only deals with functions specified to be upgraded at the time of design. Without this assumption, the design methodology has to be able to design a product that can perform functions unknown at the time of design; namely, an almighty machine. This is impossible. For this purpose, we assume that a designer should determine a long-term plan (let us call it an upgrade plan) of upgrading among several generations (e.g., three generations) at the very beginning of upgrade design. As discussed later, the upgrade plan inevitably includes uncertainty, and its treatment is one of the central issues of the design methodology.
Second, we assume that upgrading of a product is executed by changing values of attributes in the product or exchanging modules (we call these upgrade modules). Although there might be other measures, such as remodeling a product, we do not take them into account. Therefore, a design solution of the design methodology, which represents several generations of a product, consists of a platform, which is a common structure of the product that does not change throughout all generations, and upgrade modules (see Fig. 4). Therefore, determining size of the platform is another central issue of the design methodology.
The framework of design of upgradability.
Based on these assumptions, the design methodology for upgradability is modeled as a mapping from an upgrade plan to a series of several generations of a product (see Fig. 4). In other words, the design methodology is to design a series of products that realizes a given upgrade plan with minimum total costs (environmental and monetary) of the series as a whole and maximum flexibility against uncertainty of the upgrade plan. In this sense, the design methodology essentially contains a trade-off problem (costs vs. flexibility) and strategic decisions of a designer are indispensable; in other words, the design methodology aims at providing a design workspace to embody the upgrade plan according to his or her decisions.
The second assumption immediately recalls various studies of product platform design and design for variety. Ulrich (1995) is one of the pioneers in product architecture design. In his definition, the product architecture includes arrangement of functional elements, mapping from functional elements to physical components, and specification of interfaces among components. Fujita et al. (1998, 1999; Fujita, 2002) proposed optimization methods for finding out modules to be commonized among multiple products in order to minimize the total costs. Martin and Ishii (2002) proposed a quality function deployment based methodology for guiding construction of a product family by introducing a generational variety index and a coupling index with guiding rules to reduce values of these indices. Simpson et al. (2001) proposed a design methodology for scalable product platforms. They extend this method to select common and scaling parameters by introducing product family penalty function (Messac et al., 2002). Li and Azarm (2002) evaluated advantages of product line design in the context of customers' preferences, market competition, and multiple business goals when uncertainties of these factors exist.
Upgrade design can be viewed as a variant of platform design; we can point out three issues inherent in upgrade design. First, in many existing studies, function structure is fixed and common among a product family. In contrast, each generation, which corresponds to a product in a product family, has different function structure in upgrade design. This requires explicit representation and manipulation of functions in the design methodology. Second, alternatives for a module are given or the units of modules are predetermined in many studies. However, changes of function structure among generations inevitably require determination of boundaries of modules and alternatives for each module in the design methodology. This paper assumes that a module consists of one or more components and a lot of alternatives for each kind of components are stored in a component database. In comparison with Ulrich's definition of product architecture (Ulrich, 1995), our design methodology tries to solve, in the context of upgrade design, the problems of the arrangement of functional elements and the mapping from functional elements to physical components. These processes were not addressed well in the existing studies. Under this problem setting, we especially focus on candidate generation processes of changes of function structure and configurations of a platform and modules rather than evaluation and optimization of given candidates, because candidate generation itself is an issue essential for design; then, various existing evaluation and optimization methods (e.g., Fujita et al., 1999; Umeda et al., 2000; Li & Azarm, 2002) can be employed.
3.2. Upgrade plan
As shown in Figure 4, a designer should first determine a long-term upgrade plan. To make the upgrade plan the designer should consider technological trends, trends of customers' needs, trends of competitors, the company's policy, and so on, during several generations of the target product. The plan should include functions to be upgraded, basic specification, rough price of each generation, and the time when each generation will be shipped to the market. Candidates of target functions to be upgraded include functions that will be technically obsolete and appearance that will be out of fashion.
Of course, because the upgrade plan forecasts future trends of the target product, it includes uncertainty as shown in Figure 4. If the plan will not fit the actual trends after designing, the company may suffer a great loss. This is one of the main issues of the design methodology and our approach to this issue is described in Section 3.3. Moreover, we believe that there are product categories, including photocopiers, personal computers, and machine tools, for which upgrade plans can be determined with some certainty.
Although upgrade planning is a difficult task, this paper does not support the upgrade planning process. We are currently developing methods for supporting this process, including a method for identifying functions to be upgraded based on reasons why a product is thrown away (Umeda et al., 2003), a method for estimating when a function will be obsolete (Daimon et al., 2004), and a method for determining value ranges of upgrading parameters based on technological trends of components (Matsuda et al., 2003). Because these methods are not mature yet, let us assume that an upgrade plan with some uncertainty is given.
3.3. Basic approaches to design methodology for upgradability
For supporting the upgrade design process that starts from a given upgrade plan and a given design object model of the first generation of a target product, we take the following approaches.
3.3.1. Two guiding principles for incorporating upgrading functions
We have proposed two guiding principles for incorporating upgrading functions into a product; making functions independent and making functions insensitive. We derived them from our analyses of practical design data and experimental upgrade design (Umeda et al., 1999).
Making functions independent means to localize structural changes necessary for upgrading functions. Modularization of related components and exchanging modules is a hopeful approach for implementing this principle. For example, to increase copying speed of a photocopier, modularization of the main motor and replacement of motors is a practical solution. Making functions insensitive means absorbing the difference between before and after upgrading without structural changes by adding margins to components. It suggests using components of which functionality and performance are excessive to the first generation but indispensable for subsequent generations. This strategy tries to add flexibility of performance without replacing components by adding margins to components in advance. In the above example of the photocopier, if the designer uses a better motor in the previous generation, copying speed can be increased just by controlling the motor in the next generation. This is a typical example of this principle.
3.3.2. Functional upgrading and parametric upgrading
The upgrading operation can be classified into two kinds: functional upgrading, which adds or removes functions such as adding the two-sided copying function to a photocopier, and parametric upgrading, which changes the performance of a product such as increasing copying speed. Although functional upgrading results in changes of the function structure and physical configuration of a product, parametric upgrading does not change them to a large extent. We propose different design procedures for them.
We model functional upgrading as the task to find the embodiment of each upgrading function (viz., function structure, behavior, and physical structure) and to merge this embodiment into the target product. Here, this additional embodiment does not always become an upgrade module; that is, a part of embodiment might be installed into the platform at the time when the product is manufactured as a result of the making functions insensitive principle and the rest becomes an upgrade module. Therefore, determining boundaries of the platform and upgrade modules is an important issue in functional upgrading as this affects costs and flexibility of upgradable products.
Parametric upgrading consists of the determination of parametric changes and selection of components. The task of determination of parametric changes is to find out an appropriate set of value changes of design parameters that can realize required performance changes such as copying speed in the previous example. Here, a design parameter denotes a parameter that a designer can directly determine such as speed of a motor and dimensions of a part. Next, a designer should decide how to realize the changes. Replacing components (e.g., replacing a motor with another high speed motor) is one way to realize such changes and using a controllable component (e.g., variable resistance) is another way. The task of selection of components is to find a set of replaceable components or a controllable component that realizes derived value changes of design parameters. For this purpose, we prepare a database of components. In this way, we solve the problem of parametric upgrading by using a similar technique to those of the existing platform design.
Table 2 summarizes the correspondence between the two types of upgrade design discussed here and the two guiding principles discussed in Section 3.3.1.
Upgrade design operations and guiding principles
3.3.3. Dealing with future uncertainty
One of the central issues of upgrade design is how to deal with the future uncertainty that upgrade plans inevitably include. Our objective here is to provide a design methodology that supports a designer to systematically make a design object as flexible as possible against the uncertainty specified in the upgrade plan. We employ two approaches to solve this problem: expanding and shrinking platform and delayed selection of components.
For dealing with the uncertainty in the functional upgrading, we represent this uncertainty as plausibility (viz., high, medium, and low) of each upgrading function in the upgrade plan. In other words, a designer believes firmly that customers require an upgrading function with high plausibility in subsequent generations, but he or she is not sure whether the one with low plausibility is required or not. Our strategy here is to determine boundaries between a platform and upgrade modules according to this plausibility (let us call this operation expanding and shrinking platform). Namely, components that perform upgrading functions with high plausibility should be integrated into the platform as much as possible, to ease upgrading operation. Conversely, components for functions with low plausibility should be isolated from the platform as upgrade modules, in order to avoid the risk that those functions are not required in subsequent generations.
For parametric upgrading, we represent uncertainty in an upgrade plan as ranges of performance values of a function; namely, we assume that a designer does not know an exact value of performance in the next generation, but knows a certain range within which required upgrade performance resides. The parametric upgrading in this research converts these required ranges into a set of components, which are the same kind but different in performance, and/or a controllable component that can cover the required ranges. At the time of designing, a designer just selects the set of components, and when upgrading is executed, he or she chooses the most appropriate performance value from the designed range and this results in selecting a component from the set of components. Therefore, we call this operation delayed selection of components. This idea is quite similar to the postponement in the area of supply chain management (e.g., Johnson & Anderson, 2000), and this indicates that the idea of postponement can be applied to the upgrade design.
4. PROCESS OF DESIGN METHODOLOGY FOR UPGRADABILITY
Based on the discussion in Section 3, we here propose the process of the design methodology (see Fig. 5). Note that actual design is not as straight forward as this and includes a lot of trial and error, but such local loops are ignored here for the sake of simplicity.
The design process for upgradability.
The process shown in Figure 5 assumes an upgrade plan and an initial model of a target product, which has no upgradability, as inputs. An upgrade plan includes requirements of the functional upgrading and the parametric upgrading. An initial model consists of an FBS model of the design object, described in Section 2, a list of components in the design object, and a set of simultaneous equations representing quantitative behavior of the design object, which are used in the parametric upgrade design described below. Note that this methodology focuses on deriving candidates of the following three items, which will be evaluated with existing methodologies of, for example, platform design; namely, changes of function structure for realizing the functional upgrade, configurations of a platform and upgrade modules, and sets of concrete components materializing entities, which represent classes of components in the FBS model.
Let us take an example of a vacuum cleaner for explaining the design process, of which component configuration and simultaneous equations of the initial model are shown in Figure 6. In addition, let us assume an upgrade plan shown in Table 3 is given. For explaining the following process, we mainly focus on the upgrading function “to brush out dust” in the plan, which should be added with high plausibility in the second generation.
The initial model of the vacuum cleaner.
Example of upgrade plan
4.1. Constructing FBS fragments
As the first step of the process, a designer should find the embodiment (function structure and its physical realization) of each upgrading function in each generation. This task is almost the same as the main task of the traditional functional design; namely, the embodiment process of required functions. However, the designer should determine candidates of embodiments by referring to the initial FBS model (let us call it main body) in order to be easily integrated. Because the FBS modeler supports the embodiment process, we employ the FBS modeler. As an extension of the modeler, the system supports to construct a partial FBS model that realizes a required upgrading function (let us call this partial FBS model an FBS fragment), rather than a complete FBS model. An FBS fragment is different from the complete FBS model in the point that the FBS fragment may lack some subfunctions, behaviors, or entities by assuming that the fragment will be connected to the main body of the design object. Let us call them void functions, void behaviors, and void entities. Void nodes store pointers to the corresponding nodes in the main body.
In other words, this step is formalized as Eq. (1):
where fu is the target upgrading function, Ffr is a set of functions composing an FBS fragment, and fu ∈ Ffr, some of which might be void functions; Bfr is a set of behaviors composing an FBS fragment and some of them might be void behaviors; Efr is a set of entities composing an FBS fragment, some of which might be void entities; and Rfr is a set of relations composing an FBS fragment.
The methodology supports the designer to construct FBS fragments as described in the following sections.
4.1.1. Function decomposition
The designer breaks down the upgrading function into subfunctions repeatedly by referring to the function prototype knowledge base of the FBS modeler. Different from construction of the complete FBS model, the designer may specify a subfunction as a void function, if he or she finds the same kind of function in the main body and judges that the FBS fragment can be embodied by using this existing function. The prototype system, described in Section 5.1, supports this task by searching for the same kind of functions throughout the main body. A void function is not further decomposed nor embodied.
Figure 7 illustrates an example of function decomposition of an FBS fragment for the function “to brush out dust.” In this example, the designer decomposes this function into two subfunctions and then decomposes a subfunction “to rotate object” into three by choosing a decomposition method “electrical power rotation method,” which is prepared in the knowledge of function prototype “to rotate object.” Here, the designer sets a subfunction “to supply electricity” as a void function and, therefore, this function is not further decomposed nor embodied.
The function decomposition for an upgrading function “to brush out dust.”
4.1.2. Selection of physical features
After decomposing the upgrading function into element functions, the designer determines the physical embodiment that can realize each elementary function by selecting appropriate physical features, introduced in Section 2.2. The system supports this process by searching through the function prototype knowledge base. Similar to the void functions, the designer can select void behaviors and entities in the fragment if the main body has usable behaviors and entities. Although the system searches for the same kinds of behaviors and entities in the main body, the designer should judge their usability in the FBS fragment.
For example, Figure 8 shows the FBS fragment of Figure 7 after adding physical features. In this case2
Of course, the entity “dust” does not appear in the function prototype and physical feature knowledge bases, because they store general knowledge. For easier understanding, the designer rewrote a general entity “object” to be “dust” in this fragment and this is a normal operation in the FBS modeler.
The physical embodiment for an upgrading function “to brush out dust.”
In this way, the designer can construct various FBS fragments from one upgrading function.
4.2. Adding and removing FBS fragments
Next, the designer applies the constructed FBS fragments to the FBS model of the initial product, the main body. As the result of this step, the designer determines tentative boundaries among platform and upgrade modules. Here, we call them tentative boundaries because they might change later on and will be finalized in Section 4.4. This step is formalized as the following equations.
where FBSi is the FBS model of the ith generation of the target product, consisting of functions Fi, behaviors Bi, entities Ei, and relations Ri. Especially, let us call the model in the previous generation the main body of the product. In addition, FR+i+1, FR−i+1 are sets of additional and removal FBS fragments for constructing i + 1th generation of the product and FR+i+1, FR−i+1 are added to and removed from FBSi, respectively. Although FBS fragments in FR+i+1 are constructed from required upgrading functions in Section 4.1, those in FR−i+1 are selected by the first operation in Table 4. In Eq. (6), pi is the platform of the ith generation tentatively determined by the designer and UM+i+1, UM−i+1 are sets of additional and removal upgrade modules for the i + 1th generation, respectively. These tentative upgrade modules are also determined in this step.
Operations for adding and removing FBS fragments
Equation (9) denotes that functions included in the ith model but not included in the removal FBS fragments and functions in the set of additional FBS fragments are reorganized into the platform and the upgrade modules. The same operation is applied to behaviors and entities as shown in Eqs. (10) and (11). As shown in Eq. (12), the designer might add some relations to connect FBS fragments to the main body. In determining the removal upgrade modules, the proposed methodology assumes that each removal module is equivalent to each removal FBS fragment as shown in Eq. (13), for the sake of simplicity.
Based on the “expanding and shrinking platform” strategy, plausibility of upgrading functions should be reflected in the size of the platform. Although FBS fragments for upgrading functions with high plausibility can be integrated into the platform, fragments for functions with low plausibility should be isolated as upgrade modules. To do so, the procedure for adding and removing fragments proceeds as follows:
1. Removing all upgrading functions, which are designated to be removed in the upgrade plan, from the main body, by applying the first operation defined in Table 4.
2. Adding all FBS fragments for upgrading functions with high plausibility by applying the second operation defined in Table 4. For example, in Figure 9, the fragment for the upgrading function “to brush out dust” is connected to the main body by using its void nodes and the designer added a new relation “electric connect” between entities “electrical lead” and “power source,” which is not shown in this figure.
3. Determining the tentative platform in order to extend it as much as possible. For supporting this decision, the prototype system, described in Section 5.1, indicates the following three kinds of information to the designer. The designer determines the boundary between the smallest and the largest platform by considering, for example, costs, technological trends, and connectability.
a. Smallest platform: apparently, the smallest platform psmalli+1 is equal to the ith platform after removing all removing fragments FR−i+1 created by the operation (i) in Table 4 [see Eq. (14)].
b. Largest platform: obviously, the largest platform is the FBS model that includes the smallest platform psmalli+1 and all additional FBS fragments FR+i+1. However, it is infeasible to assume such a large platform that needs no additional upgrade module. Therefore, as an indicator, assuming n generations as the target of the upgrade plan, we define the largest platform plarge as follows, where, FRhi (FRhi ⊆ FR+i) denotes a set of all additional fragments with high plausibility for ith generation (2 ≤ i ≤ n).
c. Entity commonality rate: as the third indicator, for representing the size of platform, we calculate entity commonality ratio (CR) of the platform, which indicates the ratio of entities in the platform to all entities in all generations [see Eq. (17)], where Ep denotes an entity set of the platform and |E| denotes the number of entity sets.
The idea of commonality is a very popular concept (e.g., see Fujita, 2002) and this indicator is a simplified representation of this concept.
For example, Figure 9 shows a part of boundaries of the smallest and the largest platform focusing on the upgrading function “to brush out dust.” In this figure, three candidates of the boundaries are shown between the smallest and the largest platform.
4. Adding FBS fragments for upgrading functions with middle and low plausibility in order not to extend the platform by applying the second operation in Table 4.
5. Determining upgrade modules by applying the third operation defined in Table 4.
An example of the addition of an FBS fragment.
In this way, at this step “adding and removing FBS fragments,” the designer applies additional and removing FBS fragments to the initial FBS model, which results in the FBS model of the second generation, and determines tentative platform and upgrade modules. With this procedure, the designer can systematically implement the “expanding and shrinking platform” strategy.
4.3. Parametric upgrade design
Next, the designer executes parametric upgrade design, focusing on the FBS model of the second generation; namely, he or she adds parametric upgradability to the target generation and then selects concrete components of the product in this generation by using the component database, considering the “delayed selection of components” strategy. The input of this step consists of a parametric upgrade plan (see the upper part of Table 3), which represents uncertainty as ranges of parameter values, a list of components in the first generation, each of which is related to an entity node in the FBS model of the first generation, and a quantitative behavior model represented as simultaneous equations (see the upper part of Fig. 6). Here, because the behavior model of the second generation may be different from the initial one because of addition and removal of fragments, the designer should manually construct the model of the second generation by modifying the initial one. Although the behavior model can theoretically be derived from the FBS model with the KIEF system (Yoshioka et al., 2004) and we are currently studying, this issue is one of our future works.
Although a detailed algorithm is described in another paper (Umemori et al., 2001), this step proceeds as in following subsections.
4.3.1. Construction of causal relation graph
Initially, we classify parameters in the quantitative behavior model into three kinds; function parameters, design parameters, and others (see Suh, 1990). Function parameters represent overall performance of the target product (e.g., suction power and power consumption of a vacuum cleaner) and, therefore, all parameters that appear in the upgrade plan are function parameters. Design parameters are attributes of components the designer can directly determine such as dimensions of a component and torque of a motor. After the designer specifies function and design parameters in the behavior model, the system relates them according to causalities. For example, given a tiny behavior model shown in the left side of Figure 10, the system creates a causal relation graph shown in the right side of Figure 10, where fi and di denote function and design parameters, respectively. In this figure, each arrow denotes that a value change of a design parameter causes a value change of a function parameter. By changing values of design parameters and calculating their effects on function parameters, the system creates the causal relation graph.
The extraction of a causal relation graph.
4.3.2. Searching for design parameters
Next, the system finds candidates of appropriate design parameters for changing values of each function parameter, that is, parametric upgrading. To avoid side effects that might be caused by design parameter changes, we here employ the Independence axiom of Axiomatic Design Theory (Suh, 1990). By classifying causal relations into three types as shown in the lower part of Figure 10, type I should be selected as much as possible. Here, type I is the relation where a value change of a design parameter affects only one function parameter, type C is the relation where a value change of a design parameter affects more than one function parameter, and type SI is a special kind of type C. In the lower right of Figure 10, a design parameter (d2) affects both function parameters f1 and f2. However, because a value change of f1 can be adjusted by controlling d1, the relation f2–d2 can be spuriously considered as type I. Based on this idea, the system reasons out all possible sets of causal relations for controlling function parameters, which preferably consist only of types I and SI. In the example of Figure 10, a set of derived causal relations consists of f2–d1 (I type), f1–d2 (SI type), and f3–d3 (SI type). If such a set of I and SI types cannot be found, the designer should modify the behavior model by adding, removing, or replacing components and this modification is included in the upgrade modules. Conversely, the designer should select the set of relations that has minimum number of C types for avoiding unwanted changes of function parameters.
4.3.3. Range calculation using set-based theory
By using the derived sets of causal relations, the system calculates ranges of design parameters needed for the required ranges of upgrading function parameters. For this calculation, we employ the Set-Based Theory (Finch & Ward, 1995), which provides mathematical operations for calculating ranges of parameter values. The system also calculates parametric changes of function parameters other than upgrading parameters as potential side effects. Among derived sets of changes of design parameters, the designer should choose the most appropriate set that realizes all parametric upgrading and has minimum potential side effects.
4.3.4. Components selection
To realize the specified ranges of design parameters, the system finds components by searching through the component database, which stores components that might be used in the target product and their specifications. For each design parameter's range, several components, which might be variable or not, are selected in order to cover the range.
At the same time, the designer should select components corresponding to entity nodes in the additional FBS fragments determined in Section 4.2. Here, whereas an entity node specifies only a class of a component such as a motor, a component in the database represents a specific component, such as a Toshiba AC Motor 1234, with all attributive values of the component. Therefore, because an entity node in a fragment does not know its quantitative attributes, a component should be selected for each entity node in this step by using the result of the set based quantitative calculation.
As a result, the parametric upgrading is integrated into the design object model as sets of candidate components, and entity nodes in the additional FBS fragments are also embodied into components. Using the “delayed selection of components” strategy, uncertainty of the parametric upgrading results in a set of candidate components corresponding to an entity node and a specific component should be selected among them when the upgrading is executed. Therefore, the step in Section 4.3 is formalized as the following equations:
where PUGi is the parametric upgrades for the ith generation specified in the upgrade plan, Ci is the component list for the ith generation, c can be a component or a set of components, CDB(e) is a subset of components that belong to the component class e in the component database, and EQi is the quantitative behavior model of the ith generation.
4.4. Determining platform
According to the results of Section 4.3, the platform and upgrade modules are adjusted. In the component list derived in Section 4.3, an entity related to a set of components, rather than to a component, cannot be included in the platform because its corresponding component is not determined at the time of manufacturing. Therefore, if the platform includes such entities, they are moved to the upgrade modules. In this way, platform and upgrade modules for the second generation are decided. However, the final platform will be determined only after all generations have been designed.
4.5. End of design for a generation
In this way, the upgrade design process for the second generation finishes and the designer should repeat the steps in Sections 4.1–4.4 for all generations specified in the upgrade plan. When the final generation is designed in this cycle, the final platform and upgrade modules are determined as the output of the design process.
5. PROTOTYPE SYSTEM AND CASE STUDY
To verify feasibility and to clarify issues of the proposed design methodology, we developed a prototype upgrade design support system and conducted an experimental upgrade design of a vacuum cleaner by using the system.
5.1. Prototype system
Figure 11 depicts the architecture of the prototype system, and Figure 12 illustrates an example of a screen dump of the prototype system. Although we employ the existing FBS modeler described in Section 2.2 and some subsystems have not been implemented yet, the main subsystems are the following:
- UG Manager guides the designer to execute the design for upgradability.
- FBS Manager supports construction of the FBS models and the FBS fragments and to add/remove fragments to/from the FBS model, in cooperation with FBS Modeler, FBS Knowledge Bases, and FBS Fragment Modeler.
- PUG Manager supports execution of the parametric upgrading. The Causal Relation Graph Modeler constructs the causal relation graph from the quantitative behavior model and searches for appropriate sets of causal relations to control required function parameters. The Set-Based Theory Calculator calculates parameter ranges based on the Set-Based Theory, and the Components Selector finds appropriate sets of components by searching through the Components Database.
- Platform Designer supports the designer to determine a platform and upgrade modules by using the FBS model, the FBS fragments, and results of the parametric upgrading.
The architecture of the prototype system. SBT, Set-Based Theory.
An example of a screen dump of the prototype system.
The prototype system represents various models and knowledge discussed in Section 4, such as the FBS model, the FBS fragment, the behavior model, and the component list, and supports user's operations for them. Especially, the system supports the following tasks:
- Construction of the FBS model and the FBS fragment are supported by using the FBS Knowledge Bases.
- FBS fragments to be removed are created from specified removing functions by searching through the FBS model.
- Additional FBS fragments are integrated into the FBS model.
- For a specified additional fragment, the system suggests the smallest and the largest boundaries of the platform and, after the designer determines the boundary, the system indicates an upgrade module.
- To support the parametric upgrading, the system constructs the causal relation graph from a given quantitative behavior model, reasons out candidates of design parameters for controlling given upgrading parameters, calculates value ranges of design parameters, and finds appropriate component sets by searching through the component database.
- To determine the platform, the system indicates components that are included in the platform but are designated to be replaced as the result of the parametric upgrade design. Such components should move to upgrade modules.
5.2. Case study
We executed an experimental upgrade design with the example of a vacuum cleaner (see the lower part of Fig. 6). The data for this case study were acquired from our analyses of some commercial vacuum cleaners and from interviews to engineers. The inputs for this case study consist of an upgrade plan (Table 3), the initial FBS model (Fig. 13), a quantitative behavior model (Fig. 6), and a list of components (Table 5).
A part of the FBS model of the first generation in the FBS modeler.
Derived component list
Although the design results may differ according to the designer's decisions, upgrade design in this case study proceeded as follows. The upgrading function “to brush out dust” in the second generation is embodied by adding a motor and a rotational brush at the head of the cleaner as described in Figures 7, 8, and 9. In the third generation, additional function “to charge electricity” and removal function “to store electric cord” aim at making the cleaner wireless and are realized by replacing the electric cord with a battery, a charger, an electric converter, and an electric inverter.
As a result, we derived four candidates for the platform and, among them, the largest platform (entity commonality rate = 56%3
In this case, 27 different components are used in total among the three generations and 13 components out of 27 are included in the platform. Thus, 13/27 = 56%.
In this case, 11 components out of 27 are included in the platform. Thus, 11/27 = 41%.
Derived candidates of the platform.
Initial configuration in the largest platform
Upgrade modules
6. DISCUSSION
As described in Section 5, we succeeded in designing an upgradable vacuum cleaner based on the proposed methodology and the prototype system. Although the design result should be evaluated by experts, the proposed methodology, at least, systematically guided us in designing an upgradable product. The quality of the design result depends on the designer's ability and the sufficiency of related information. One of the main features of the proposed methodology is to guide a designer in designing upgradable products that can flexibly adapt to the uncertainty specified in a given upgrade plan by appropriately configuring platform and upgrade modules. This feature is verified by the case study because several candidates of platforms different in the size are indicated and sets of alternative components are derived. Therefore, we conclude that the design methodology proposed in this paper has feasibility and rationality.
As discussed in Section 3.1, the proposed methodology has some similarity to the existing various research works about the platform design. Certainly, most of them are quite sophisticated and mature. However, the main emphasis we wanted to address in this paper is to provide a design workspace that supports a designer to find candidates of functional changes in long-term usage of a single product, as opposed to a variety of different products, and candidates of configurations of a platform and modules by representing them explicitly. According to Ulrich's definition of the product architecture (1995), the proposed methodology succeeded in supporting arrangement of functional elements and mapping from functional elements to physical components in a flexible manner. The functional representation and the function design are obviously the most effective in solving these issues, while the representation might be inevitably too abstract. In much of the literature, including Fujita et al. (1999), Li and Azarm (2002), Martin and Ishii (2002), and Messac et al. (2002), function structure is fixed and common among multiple products. However, function structure differs in each generation in this paper, and candidates of functional modification are given by the library of FBS fragments and function prototypes. In Fujita et al. (1999), without discussing changes of sizes of modules, alternatives of modules are given a priori. In Li and Azarm (2002), the process for finding out design alternatives is not supported. Although product structure is also given in Messac et al. (2002), this method gives a good suggestion to the parametric upgrading in this paper. Martin and Ishii (2002) also do not support the process of finding design modifications, and leaves this process to a designer by suggesting some rules. In this sense, their methodology is quite practical. Moreover, future requirements, which correspond to the upgrade plan in this paper, are not clarified but represented only as likelihood of future change. However, rules for design modification (viz., approaches reducing generational variety and coupling indexes) in their work have considerable similarity to our methodology. “1a. rearrange the mapping of functionality to components,” of which process was not shown in their work, is the process we have solved in this paper. “2b. increase the ‘headroom’ of the specification” is the “making functions insensitive” principle in this paper, and we have shown how to realize this principle. Needless to say, these methodologies are indispensable for evaluating and optimizing design alternatives generated by the methodology proposed in this paper. However, without doubt, the process for ascertaining design alternatives should also be supported.
These features of our methodology are indispensable for supporting upgrade design in general. In addition, the way to deploy the above-mentioned methodologies for the platform design toward upgrade design, which is an important issue in ecodesign, has not been shown well. Therefore, this design methodology may have impact on the ecodesign research community.
In contrast, upgrade design, as a general term, has not been practiced well. This issue mainly comes from two reasons: one is the future uncertainty we mentioned several times in this paper, and the other is the business strategy, where a company makes profits by providing upgrading services rather than just by selling products. Although this paper focuses on formalization of the design methodology for upgradability, these issues require development of business strategies, including upgrade planning, for upgrade design as an important future work. At least there should be some product categories suitable for upgrade design. Examples include facsimiles (Fujimoto et al., 2003), photocopiers, and printers. Conditions of such suitable products include the following:
- products that have short value lifetimes;
- products of which functions and their performance in some generations can be specified with some certainty; perhaps, it is desirable that their lifetimes are less than 5 years and, in this case, product development cycle, namely generation, might be shorter; and
- preferably, the company can control trends of products according to their upgrade plans. This might be possible in oligopolistic markets.
Although designing upgradable products is a challenging issue, it is worth challenging as a hopeful option of environmentally conscious life cycle design, because it will realize “servicification” of the manufacturing industry (Tomiyama, 1997) as well as mitigation of environmental issues. Using appropriately designed upgradable products for a long time will have higher environmental efficiency than replacing whole existing products. At the same time, they can provide higher additional value than the value provided just by replacing software. In fact, Nakamura and Kondoh (2001) clarified economic and environmental advantages of such products.
In contrast, because the objective of this paper focused on formalizing the upgrade design process, there are several issues to be solved, besides the above-mentioned issues of upgrade planning and business strategy:
- Because the FBS model symbolically represents the physical structure of a design object, it is difficult to deal with geometry of components and spatial constraints among them. This is one of the drawbacks to the symbolic representation of function in general. Although this kind of information is critical for determining configuration of modules, bridging symbolic functional representation with geometric information is too large an issue in general to solve in this paper. This is one of our future issues.
- In the current implementation, the platform is determined progressively by considering each FBS fragment in each generation. Therefore, although the candidates of the platform derived in the case study are acceptable as far as our investigation, there might be a need for some extensions of the methodology for determining the platform from the viewpoint of overall generations.
Finally, let us discuss the impact of the proposed methodology to the functional representation and reasoning community. “Upgrade design” is a distinctive application of functional design because it inevitably requires representation and manipulation of functions. In contrast, in traditional design, the role of functions and advantages of functional representation and manipulation are often unclear to researchers outside of the community. Therefore, we believe that it is important for the community to excavate various applications to which functional representation and reasoning are indispensable, such as upgrade design. Various modeling methodologies for functions have been proposed in this community and FBS modeling is one of them. In terms of supporting the design methodology for upgradability, the required features of functional modeling are summarized as follows and FBS modeling satisfies them. Then, other functional modeling methodologies might also be available if they satisfy these conditions.
- To clearly represent a relationship between required functions and realizing structure is indispensable for determining a platform and upgrade modules. In FBS modeling, they are related via behavioral concepts. Although we could not make full use of functional and behavioral reasoning facility of FBS modeling and KIEF (Yoshioka et al., 2004), this facility is useful for discovering side effects of designer's operations for adding upgradability and checking consistency of design results.
- To support a process to find physical embodiment from a required function is also indispensable. Although this feature is generally important in traditional design, FBS modeling has a high ability to support this process, constructing FBS fragments considering existing structure of the previous generation, in the design methodology for upgradability.
As an extension of FBS modeling, this paper discussed, at the step “parametric upgrade design” in Section 4, a method to relate abstract entity nodes in FBS modeling to concrete components through the range calculation and search through a component database. Because one of the drawbacks of symbolic representation of function is the difficulty to embody its abstract representation into concrete physical structure, this extension of FBS modeling provides a way to do this.
7. CONCLUSIONS
In this paper, we proposed a design methodology for upgradable products. Development of upgradable products is an important issue for solving environmental problems, especially reduction of resource consumption and waste amount, while extending business chances of manufacturing industries. Because future uncertainty is inevitable in planning the upgrading of a product, dealing with it is one of the main issues in upgrade design. The proposed methodology supports a designer to find an upgradable design solution that can flexibly adapt to the uncertainty specified as an upgrade plan by employing a functional modeling scheme, FBS modeling, and based on two strategies; delayed selection of components and enlarging and shrinking platform. The main features of the methodology include to support a designer for finding candidates of functional changes in a long-term usage of a single product and candidates of configurations of a platform and modules by representing these two kinds of candidates explicitly. In contrast, limitations include upgrade planning, evaluation of design results, and treatment of geometric constraints.
This paper mainly focused on formalization of the upgrade design process and modeling of upgrade design operations. The prototype system and a case study using the system verified feasibility of the proposed design methodology. However, this prototype system is developed just for verifying the methodology; we are planning to develop a more practical design support system by, for instance, introducing functional and behavioral reasoning facility embedded in the KIEF system.
Upgrade design is an application of functional design in which functional representation and manipulation are obviously indispensable. Therefore, it is important for the functional design community to develop such applications as the upgrade design.
Future works include the following:
- introducing information about value and physical lifetimes of components to decide platform and upgrade modules more practically;
- developing representation of interfaces between a platform and upgrade modules, which has not been discussed enough in this paper;
- introducing advanced modularization methodologies to decide upgrade modules more rationally; and
- developing a method for evaluating design results in terms of upgradability, flexibility against uncertainty, environmental consciousness, and profitability.
ACKNOWLEDGMENTS
A part of this work was financially supported by Inverse Manufacturing Forum, Japan, and Tokyo Metropolitan University. We thank Y. Umemori, H. Yagi, Y. Ishigami, and A. Matsuda for their contributions to the theoretical development and implementation of the prototype system.
References
REFERENCES
Bracewell, R.H. &
Sharpe, J.E.E.
(1996).
Functional descriptions used in computer support for qualitative
scheme generation—Schemebuilder.
Artificial Intelligence for Engineering Design, Analysis and
Manufacturing
10(4),
333–346.Google Scholar
Chakrabarti, A. &
Bligh, T.P.
(2001).
A scheme for functional reasoning in mechanical conceptual
design.
Design Studies
22(6),
493–517.Google Scholar
Daimon, T.,
Kondoh, S., &
Umeda, Y.
(2004).
Proposal of decision support method for life cycle strategy by
estimating value and physical lifetimes.
Proc. 11th Int. CIRP Life Cycle Engineering Seminar,
pp.
49–56.
Finch, W.W. &
Ward, A.C.
(1995).
Generalized set-propagation operations over relations of more than
three variables.
Artificial Intelligence for Engineering Design, Analysis and
Manufacturing
9(3),
231–242.Google Scholar
Fujimoto, J.,
Umeda, Y.,
Tamura, T.,
Tomiyama, T., &
Kimura, F.
(2003).
Development of service-oriented products based on the inverse
manufacturing concept.
Environmental Science & Technology
37(23),
5398–5406.Google Scholar
Fujita, K.,
Akagi, S.,
Yoneda, T., &
Ishikawa, M.
(1998).
Simultaneous optimization of product family sharing system structure
and configuration.
Proc. ASME 1998 Design Engineering Technical Conf.,
Paper No. DETC98/DFM-5722.
Fujita, K.,
Sakaguchi, H., &
Akagi, S.
(1999).
Product variety development and its optimization under modular
architecture and module commonization.
Proc. ASME 1999 Design Engineering Technical Conf.,
Paper No. DETC99/DFM-8923.
Fujita, K.
(2002).
Product variety optimization under modular architecture.
Computer-Aided Design
34(12),
953–965.Google Scholar
Gero, J.S. &
Kannengiesser, U.
(2004).
The situated function–behaviour–structure
framework.
Design Studies
25(4),
373–391.Google Scholar
Hiroshige, Y.,
Nishi, T., &
Ohashi, T.
(2001).
Recyclability evaluation method (REM) and its application.
Proc. EcoDesign 2001, pp.
315–320.
Los Alamitos, CA:
IEEE Computer Society.
Ishii, K.
(1999).
Incorporating end-of-life strategy in product definition.
Proc. EcoDesign'99, pp.
364–369.
Los Alamitos, CA:
IEEE Computer Society.
Johnson, M.E. &
Anderson, E.
(2000).
Postponement strategies for channel derivatives.
International Journal of Logistics Management
11(1),
19–35.Google Scholar
Jovane, F. &
Alting, L.
(1993).
A key issue in product life cycle: disassembly.
Annals of CIRP'93
42(2),
651–658.Google Scholar
Kobayashi, H.
(2001).
Life cycle planning for strategic evolution of eco-products.
Proc. 12th Int. Conf. Engineering Design (ICED01),
pp.
757–763.
Li, H. &
Azarm, S.
(2002).
An approach for product line design selection under uncertainty and
competition.
Journal of Mechanical Design
124,
385–392.Google Scholar
Martin, M.V. &
Ishii, K.
(2002).
Design for variety: Developing standardized and modularized product
platform architectures.
Research in Engineering Design
13(4),
213–235.Google Scholar
Matsuda, A.,
Shimomura, Y.,
Kondoh, S., &
Umeda, Y.
(2003).
Upgrade planning for upgradable product design.
Proc. EcoDesign 2003, pp.
231–234.
Los Alamitos, CA:
IEEE Computer Society.
Messac, A.,
Martinez, M. P., &
Simpson, T. W.
(2002).
Introduction of a product family penalty function using physical
programming.
Journal of Mechanical Design
124,
164–172.Google Scholar
Nakamura, S. &
Kondoh, Y.
(2001).
Waste input–output analysis of disposal, recycling, and
extended life of electric home appliances.
Proc. EcoDesign 2001, pp.
814–819.
Los Alamitos, CA:
IEEE Computer Society.
Prabhakar, S. &
Goel, A.K.
(1998).
Functional modeling for enabling adaptive design of devices for new
environments.
Artificial Intelligence in Engineering
12(4),
417–444.Google Scholar
Qian, L. &
Gero, J.S.
(1996).
Function–behavior–structure paths and their role in
analogy-based design.
Artificial Intelligence for Engineering Design, Analysis and
Manufacturing
10(4),
289–312.Google Scholar
Sembugamoorthy, V. &
Chandrasekaran, B.
(1986).
Functional representation of devices and compilation of diagnostic
problem-solving systems. In
Experience, Memory, and Reasoning
(Riesbeck, C.K., Ed.).
Hillsdale, NJ:
Erlbaum.
Simpson, T.W.,
Maier, J.R.A., &
Mistree, F.
(2001).
Product platform design: method and application.
Research in Engineering Design
13(1),
2–22.Google Scholar
Suh, N.P.
(1990).
The Principles of Design.
New York:
Oxford University Press.
Suwa, M.,
Gero, J.S., &
Purcell, T.
(1999).
Unexpected discoveries and s-inventions of design requirements: a
key to creative designs. In
Computational Models of Creative Design IV
(Gero, J.S. &
Maher, M.L., Eds.), pp.
297–320.
Sydney, Australia:
Key Centre of Design Computing and Cognition, University of
Sydney.
Tomiyama, T.
(1997).
A manufacturing paradigm toward the 21st century.
Integrated Computer Aided Engineering
4,
159–178.Google Scholar
Tomiyama, T.,
Kiriyama, T., &
Yoshikawa, H.
(1992).
Conceptual design of mechanisms: A qualitative physics
approach. In
Concurrent Engineering: Automation, Tools, and Techniques
(Kusiak, A., Ed.), pp.
131–152,
New York:
Wiley.
Ulrich, K.T.
(1995).
The role of product architecture in the manufacturing firm.
Research Policy
24,
419–440.Google Scholar
Umeda, Y.,
Hijihara, K.,
Oono, M.,
Ogawa, Y.,
Kobayashi, H.,
Hattori, M.,
Masui, K., &
Fukano, A.
(2003).
Proposal of life cycle design support method using disposal cause
analysis matrix.
Proc. 14th Int. Conf. Engineering Design (ICED03).
Umeda, Y.,
Ishii, M.,
Yoshioka, M., &
Tomiyama, T.
(1996).
Supporting conceptual design based on the
function–behavior–state modeler.
Artificial Intelligence for Engineering Design, Analysis and
Manufacturing
10(4),
275–288.Google Scholar
Umeda, Y.,
Nonomura, A., &
Tomiyama, T.
(2000).
Study on life-cycle design for the post mass production
paradigm.
Artificial Intelligence for Engineering Design, Analysis and
Manufacturing
14(2),
149–161.Google Scholar
Umeda, Y.,
Shimomura, Y.,
Yoshioka, M., &
Tomiyama, T.
(1999).
A proposal of design methodology for upgradable products.
Proc. ASME 1999 Design Engineering Technical Conf.,
Paper No. DETC99/DFM-8969.
Umeda, Y.,
Takeda, H.,
Tomiyama, T., &
Yoshikawa, H.
(1990).
Function, behaviour, and structure. In
Applications of Artificial Intelligence in Engineering V
(Gero, J.S., Ed.), pp.
177–193.
Southampton/Berlin:
Computational Mechanics
Publications/Springer–Verlag.
Umeda, Y. &
Tomiyama, T.
(1997).
Functional reasoning in design.
IEEE Expert: Intelligent Systems and Their Applications
12(2),
42–48.Google Scholar
Umemori, Y.,
Kondoh, S.,
Umeda, Y.,
Shimomura, Y., &
Yoshioka, M.
(2001).
Design for upgradable products considering future
uncertainty.
Proc. EcoDesign 2001, pp.
87–92.
Los Alamitos, CA:
IEEE Computer Society.
Yoshioka, M.,
Umeda, Y.,
Takeda, H.,
Shimomura, Y.,
Nomaguchi, Y., &
Tomiyama, T.
(2004).
Physical concept ontology for the knowledge intensive engineering
framework.
Advanced Engineering Informatics
18,
95–113.Google Scholar
The relationship among function, behavior, and state (adapted from Umeda et al., 1996).
The FBS modeler (adapted from Umeda et al., 1996).
Definition of function prototype
An example of a physical feature (adapted from Umeda et al., 1996).
The framework of design of upgradability.
Upgrade design operations and guiding principles
The design process for upgradability.
The initial model of the vacuum cleaner.
Example of upgrade plan
The function decomposition for an upgrading function “to brush out dust.”
The physical embodiment for an upgrading function “to brush out dust.”
Operations for adding and removing FBS fragments
An example of the addition of an FBS fragment.
The extraction of a causal relation graph.
The architecture of the prototype system. SBT, Set-Based Theory.
An example of a screen dump of the prototype system.
A part of the FBS model of the first generation in the FBS modeler.
Derived component list
Derived candidates of the platform.
Initial configuration in the largest platform
Upgrade modules
You have
Access
- 59
- Cited by