3.1. A function-based structure for product representation

The function-based model adopted into this study is inspired to a multilevel framework (Germani et al., Reference Germani, Mengoni and Raffaeli2007). It consists of three domains, namely, the functional structure, the modular structure, and the product architecture (Fig. 1).

Fig. 1.

Three-tiered representation of the product: functional level, modular level, and product structure.

It uses graph networks to model inner relations and propagation of changes’ effects (Raffaeli et al., Reference Raffaeli, Mengoni and Germani2010). In the context of product families, such representation allows a shared functional representation, which is linked to several implementations of the product (Raffaeli et al., Reference Raffaeli, Malatesta, Marilungo and Germani2013). The framework introduces multiple views on the product itself, and allows the designer to focus on the functional definition of the product, as well as its implementation by its main constitutive modules. It also provides a breakdown of the structure until it reaches low-level implementation details, with different levels of granularity. The complexity and completeness of the formalization allows effective analysis to manage a modification of an existing product or the addition of new variants.

The first domain concerns FM and functions’ representation according to the renowned concepts fixed by Pahl et al. (Reference Pahl, Beitz, Feldhusen and Grote2007). In the proposed approach, a function-based structure is defined as the decomposition of the product functions and the flows established between them, represented by block diagrams. The functional structure represents what the product (in all its parts) is intended to do, as well as the input/output relationships, at different levels of granularity. A pair of a verb and a noun expresses each function, while flows split in the three categories (i.e., energy, material, and signal). Since 2001, Hirtz et al. (Reference Hirtz, Stone, McAdams, Szykman and Wood2001) have fixed a shared terminology to standardize functional analysis representations, which can be optionally employed by the user. The main characteristic of a functional analysis is the abstraction of the description, which should not include any perspective on technical solutions. From an overall function representing the product as a black box, the functional analysis is performed splitting into subfunctions of lower complexity. The process stops when the further subdivision in subfunctions leads to more specific concepts linked to the physical implementation of the product and its behavior. For its nature and purpose, the functional analysis should be devoid of outlooks on the product implementation, which is the scope of the third level of the introduced representation.

The second tier is represented by module configuration, which is defined from the most detailed function-based structure. A module aims to represent a reusable standard unit, which minimizes relationships with other part of a product, facilitating the configuration of variants. Given that the modular configuration is derived only from the functional structure, it is almost independent from geometrical or physical implementations of the modules themselves. Modules are identified by DSM and MFD methods. In particular, DSM provides a map of the relations among the product modules, as identified in the previous step, and MFD provides a systematic evaluation of the defined product solutions, based on the functional product structure, as suggested by Stjepandić et al. (Reference Stjepandić, Ostrosi, Fougères, Kurth, Stjepandić, Wognum and Verhagen2015).

The last tier refers to the definition of the product architecture, which represents how the above-mentioned modules and their functions are embodied in physical solutions. The product structure has a computer-aided design (CAD)-like form, being a tree of subassemblies of blocks. A block is intended as a component or an assembly that may appear in several variants. A block stores geometrical and nongeometrical attributes. It contains a name, a set of properties, the implemented functions, and links to the related documentation files. Each property represents an attribute of the block, such as a geometrical parameter, a material, a specification, or a characteristic. The base property represents the block as a whole and enumerates its variants if they exist. For instance, parts such as motors, actuators, or sensors have several alternatives that may be chosen from catalogs. In particular, the base property of the block contains the part code used by the enterprise resource planning or project life cycle management system for unique identification of the variant.

3.2. Block dependencies and variants representation

Variants representation is fundamental when a product family has to be designed, as all products belonging to the same family share a set of common parts. In the proposed model, the product is represented as a metaproduct made up of such common parts and all the parts that are used by the specific instances of the family. Family members are then formed by indicating which components are in use and, if necessary, in which variants. The functional structure is extended to encompass all the family functions. Similarly, relations are defined among all the parts of the metaproduct definition. In this way, a specific family instance corresponds to a subset of such relations. For each part, a specific block variant is specified. If any variant is indicated, it means that the block is not included in the specific product and it is discarded. Each block variant shares the same inner structure in terms of properties but differs for the assumed values. In this way, variants of a block can be easily replaced, maintaining consistency in the relation graph. As a certain block is excluded from a family member, the relations associated with its properties are disabled.

Moreover, as components are linked to the functional level thanks to the three-tiered model, parts exclusion is reflected on functions that are consequently turned off. Conversely, new family members can be instantiated starting from a new functional structure. The needed components are then selected on the basis of the connection with the active functions. In this way, variant configuration is very easy and directly connected with the required functions. By extending the concept of relationship to the multilevel product representation, the product structure can be represented as an articulated graph-tree structure.

A relation is a dependency between a property on one side and one or more properties on the other. In this context, block relations can capture both design choices and design constrains between product parts, and can be distinguished between standard and auxiliary. While the former is intentionally defined by designers to express explicit dependencies, the latter is implicitly introduced to capture the linkages with the product structure. A relation can consist of three kinds: internal relation, assembly relation, and functional relation. The first one (internal relation) connects the base property with the other properties within a block. If a base property of a block changes, other properties are also likely to change. The second one (assembly relation) links a component base property to the one of its parent assembly. Here, the aim is to capture the implicit link among an assembly and its parts. Finally, the third one (functional relation) links properties of different blocks when they implement functions that are connected by a functional flow. This relation links the product architecture to its function-based decomposition and vice versa (Fig. 2).

Fig. 2.

The function-based auxiliary relation is automatically introduced between components implementing functions connected by a flow.

3.3. The adoption of the function-based model for variant configuration

New product variant design generally involves a multidisciplinary design team, made of designers, engineers, people from marketing departments, and people from commercial or purchasing departments. Data are gathered from market analysis, and product specifications for a new product variant are expressed in terms of functionalities and performances. Such specifications could conflict with each other and should not be selected at the same time, so that conflicting constraints require a technical evaluation from the design department. Once a set of requirements is validated, a preliminary bill of material (BOM) is validated and an estimated cost in terms of bought parts, manufactured parts, and assembly activities is provided. Numerous iterations are generally needed to have an acceptable solution. Furthermore, modifying the so-defined product is rather more complex and strongly depends on the nature of the change and on the available time to perform it (the so-called EC). Assessing the change feasibility is crucial for the company. Therefore, depending on time limits, it is reasonable to think that some redesign activities must be done simultaneously even if the logical procedure would have preferred a serial execution. Figure 3 shows an exemplificative EC process in manufacturing companies.

Fig. 3.

Representation of engineering changes process in manufacturing companies under time constraint (adapted from Malatesta et al., Reference Malatesta, Raffaeli, Mengoni and Germani2013).

The proposed model adopts an agent-based approach to handle complex product configuration, as it allows dealing with uncertain problems where global knowledge is distributed and shared, with the aim to achieve a consensual solution in a collaborative way. The optimal configuration emerges from fuzzy consensual solution agents and their affinities. During this phase, the consensual solution agents through their interactions and using their affinities are structured into modules. Nevertheless, configuration conflicts may occur if too strict requirements are given or strict external constraints, and thus any configuration cannot be found. In this case, corrective actions are suggested to solve configuration conflicts and to define the “closer” solution. In the model proposed in this paper, the contrast pulse sequencing technique (Yang & Dong, Reference Yang and Dong2012) is adopted considering that the customer requirements are described by the product functions, as defined in the first tier, and the structural needs and constraints, as defined in the third tier. When the costumers’ requirements are clearly identified and the solution can be generated easily, an automatic batch configuration process is executed. When some configuration conflicts occur and the system is not capable of automatically retrieving a solution, an iterative configuration process is carried out. The designer can intervene and manually define the optimal configuration.

The quality and efficiency of the redesign process can be evaluated through the number of iterations needed to reach a correct product and the related production facilities, the time taken to execute the redesign process, the number of identified components involved in the modification, and the amount of resources employed for tests. Moreover, for any company, it is a common practice to check the EC process when part of the time to perform the test, almost 30%, has elapsed. If something is going wrong, the problem is analyzed again and the design has to be corrected. In this context, adopting the proposed function-based model could help managers, designers, and technicians to have more information during EC processes, to validly predict how much, what, and where a change will impact and how many components would need a change. It would also increase the awareness of what a modification could lead to, avoiding neglecting something important or reducing the work field initially thought. According to the proposed model, the prediction and management of any change impact can be built on the three levels of the product representation: changing a part of the product means modifying the properties of components or subassembly of the product structure. The perspective under which a product change is evaluated refers to classifications of the requirements (e.g., performance, cost, assembling, sustainability, and usability). The correlation between the requirements and change impact is provided to quantify and store the effect of changing a specific property.

3.4. Benchmark of the proposed modeling scheme with the literature

The proposed model aims at providing an efficient and concrete design tool for industry to face the competitive and unstable current market, where customers ask for new functionalities, standard constraints are more and more strict, and the design team has to reduce the time to market while managing an increasing amount of data. Dedicated approaches are then required to support stakeholders in their job of designing and evaluating new product instances. With respect to previous models, the proposed model allows making available function-based product representation for product configuration of industrial complex products, also by offering a proper IT tool to support the design team in its effective use.

Following the path traced by Summers et al. (Reference Summers, Eckert and Goal2013), the modeling approach has been analyzed in terms of representational characteristics and expressive power, supported cognitive dimensions, and reasoning inferencing capacity. Table 1 reports a synthesis of the analysis and a comparison with modeling approaches from the literature, where appropriate.

Table 1.

Analysis of the proposed modelling approach and benchmarking

The most significant characteristics of the proposed model can be summarized in the following points:

• • Multilevel product representation: The three-tiered model allows contemporary generation of the functional, technical, and architectural model of the new solutions. By acting on one level, the other two are automatically defined by the system thanks to proper knowledge formalization. Furthermore, the graphical visualization of the relations among blocks makes the design team aware of the underpinning data flow representation among modules and functions, and the inner relations among product requirements, product physical parts, and obtained impacts (i.e., costs, etc.).

• • Implicit dependencies elicitation: The three-tiered representation allows finding connections moving among the different layers. It is possible to easily understand how functions and subfunctions are implemented by the product physical components as well as how the design intent has been elicited in terms of functions.

• • Low level of abstraction: The experimental work has shown that the functional decomposition is positively accepted by the designers if they are free to use verbs and nouns close to their background. The functional basis terms are generally perceived as too generic and far from the functional concept as present in the designer's mind. Moreover, an additional degree of freedom is required in the representation of lower detailed levels of the functional decomposition making concessions on behavioral aspects. However, the lack of a standardized abstract lexicon causes some drawbacks such as inconsistency of the models and scarce similarity between models of the same system produced by different users.

• • Multiuser approach: The model allows different actors of the design team to work together, each of them considering the more familiar product representation, and to represent data with different level of details according to the design phase, product life cycle, and the purposes of the analysis. It improves the product technical quality and the evaluation quality as well as reduces the time spent for finding the best design solution.

• • Enhancement of methods and tools from the literature: Methods for data search and a retrieval engine in configuration generation (i.e., agent-based models), tools for the configuration of conflict management (i.e., contrast pulse sequencing), and change management (CM) impact computation: the proposed model has been translated into an IT platform to be concretely experimented on during design activities.

4.1. The platform architecture

The IT platform architecture able to deploy the proposed approach is shown in Figure 5. It is composed of a knowledge-based engine, using a shared database of different data (i.e., technical, marketing, life cycle, product BOM, product data, and CAD data) and four tools (i.e., a product variants configurator tool, a CM tool, a manufacturing cost estimation tool, and an LCA tool). A database system is filled with the specific parameters obtained from the gathered requirements. Moreover, the values of such parameters are inserted into the database to form a configuration. All the existing product variants can be automatically input capturing the related information from an enterprise resource planning or product life cycle management system. The knowledge-based engine collects also all the compatibility rules that are necessary to validate any set of parameters. In particular, the configurator tool lets marketing and technical users add value to the configuration process. The platform is supposed to be shared between the marketing, design, and purchasing departments offering dedicated graphical user interfaces that provide specific software functionalities.

Fig. 5.

The configuration platform architecture.

When a new product variant has to be defined, marketing staff validates the new set of requirements along with design experts in order to define the new functional requirements, solutions, and the relative parameters. Such data represent the starting point for the technical actions. The system interface allows users to define novel product configurations by combining all the wanted parameters. This action is usually carried out by the marketing staff. The interface shows the interested product parameters and adapts them with the addition or removal of records in this table. It also offers the search functionality of existing products to find the product variant closest to the customers’ requirements, based on agent-based models. Four operators are introduced:

1. 1. Filter operator: It filters a subset of parameters to find similar configurations. Such an operator is based on parametric queries on the table of requirements.

2. 2. Distance operator: It computes the Euclidean distance of two variants expressed in the n-dimensional space of the parameters. Such an operator allows the most similar variants to be found and sorted in an automatic manner.

3. 3. Compatibility evaluation: It evaluates the compatibility of a pair of parameters by searching for a variant where the two parameters already coexist. This requires [n · (n – 1)] / 2 pairs to be considered to assess the global validity of a new configuration.

4. 4. Rule-based exclusion: It allows logic rules to be input to limit the values that can be assumed by parameters. The syntax is simple and uses not only arithmetic operators but also logic and conditional ones such as and, OR, NOT, EQUALS, and IF.

While the first two operators allow a manual or assisted search to be performed, the last two operators allow a new variant to be automatically assessed. In particular, compatibility evaluation alerts the marketing expert on the novelty introduced by a new combination of parameters. In contrast, the rule-based exclusion operator aims to form a knowledge base that will grow with the everyday usage. Although every rule must be formulated with the help and expertise of the design department, the growth of the rule database progressively will allow the marketing department to be independent. Moreover, the rule set represents a base of explicit configuration knowledge on the specific product family. The user is informed if the new configuration is not consistent (i.e., if parameters are incompatible due to any rules) and an alert is shown. A constraint satisfaction engine is used for rules validation and global product assessment (Ferfernig et al., 2014). Finally, a new configuration is saved in the database increment for the available solutions to be recovered in the future.

The interface shown in Figure 6 provides editing functionality for defining the validity rules, which verify the compatibility of product parameters as new variants are configured. Each rule is composed using a syntax made up of arithmetic, logic, and conditional operators. A dedicated interface facilitates rule definition by listing properties and possible operators. Below, an example of rule is given:

Fig. 6.

The configuration tool interface for checking input validity rules.

Such an interface also provides messages associated to the rule in order to provide clues and explanations to the user about the new configuration based on a recommender system approach (Ferfernig et al., 2013). The rules, and hence the message associated with them, are classified according to their severity:

• • Information rule: The message reports an advice or useful information.

• • Exclamation rule: The message warns the marketing user that something is to be added, changed, or removed in the current configuration but is not crucial.

• • Critical rule: The message alerts that the current configuration is not feasible and recommends which values of the parameters have to be changed or which parameters have to be added or removed.

In addition, a tooltip is associated with each parameter, providing specific information. Finally, the rule can be enabled or not and then saved. Not all cases are covered by these rules, namely, the combination of parameters of the new variant configurations created by the marketing user could not be related to rules or simply there are no contraindications to the configuration. Therefore, similar past configurations can be searched, but if the parameters that represent the change are not present in the company history, this is the case to send a preliminary evaluation to the technical department.

The CM tool comes to the aid of the design department when the assessment of a new variant is required. The designer uses the model representation to estimate the change propagation and its impact on the product structure from the properties of one or more blocks to be changed (Fig. 7).

Fig. 7.

The change management tool interface for variant management.

The graph engine collects and computes the three representation levels (functional structure, modular structure, and product architecture) and the related graphs. The software provides a graphical user interface for managing the three representation domains. The requirements view lets the user set the impact indices for the properties to all identified design contexts, which, as stated above, are seen as a classification of the product requirements. The relations view allows inputting standard relations between properties of the blocks. The archetypes tab is the overview about all the components involved in all the considered product families. Then, the graphical output related to the change propagation and the values of the output of the change impact indices are part of the software module of change analysis.

Finally, the CM tool has the possibility to communicate other company repositories, such as an LCA tool and a cost estimation module that allows the technical users to have a more accurate evaluation of the impact indices. Such indices are required by the CM tool for the computation of the change impacts regarding the design contexts related to life cycle analysis and costs. LCA is a well-known methodology that allows evaluating environmental impacts related to a product, both manufactured or consumed, process or activity. It examines the entire life cycle, from cradle to grave, and the potential environmental impact intended, for example, as the use and consumption of natural resources (i.e., extraction, treatment, and processing of raw materials) and the environmental consequences of dross due to production and transport, its use and reuse and maintenance until the recycling and its final disposal. It is accomplished through the identification and quantification of the raw materials and energy consumption and emissions. It allows comparing quantitatively similar products and identifying and evaluating opportunities to reduce the impacts. It can be performed at any stage of the life cycle, but its usefulness is predominant in the initial stage of design. The reference standards that describe in detail the requirements for conducting an LCA are ISO 14040 and ISO 14044. As far as the LCA tool, the platform includes commercial software, for example, SimaPro (https://www.pre-sustainability.com/simapro). It provides collecting, analyzing, and monitoring the sustainability performance of products and service in an easy way by modeling and analyzing complex product life cycles in a systematic and transparent way, measuring the environmental impact of products and services across all life cycle stages thanks to structured databases containing a wide range of inventory data and impact assessment methods (it also includes the Ecoinvent database), and identifying the hotspots in all aspects of the supply chain, from extraction of raw materials to manufacturing, distribution, use, and disposal. Such analyses are executed on single parts or an entire product family, or part of them. In the case of family, it allows understanding if the introduced change leads to a variant that improves or not its environmental impacts. The designer can evaluate if the introduced modification is convenient or not and assess the impact index value used in the CM tool. If the environmental impact computed with the LCA tool differs from the impact index value, a tuning can be executed.

Cost is another of the main design drivers considered by the platform. Its evaluation in the early design phases allows cost-effective choices to be performed. The platform includes the commercial software LeanCOST (http://www.hyperlean.eu/?page_id=1168&lang=en), which is based on an analytical approach for the cost estimation issue (Fig. 8).

Fig. 8.

Cost estimation tool architecture (adapted from Mandolini et al., 2012).

LeanCOST estimates times and costs of manufacturing cycles from a knowledge-based approach. Its interface is shown in Figure 9. The system interacts with the above-mentioned function-based product representation to retrieve geometric and nongeometric information (e.g., material, tolerances, and surface treatments) in order to apply its cost models.

Fig. 9.

The cost estimation tool interface.

In particular, cost is estimated considering four components:

1. 1. machining cost: the time in which the machine works the piece multiplied by the machine unitary cost;

2. 2. stock cost: the stock weight required to manufacture the final product multiplied by the stock unitary cost;

3. 3. accessory cost: the time in which the machine does not work the piece (i.e., machine is changing tool or piece) multiplied by the machine unitary cost; and

4. 4. machine setup cost: the time during which the machine is performing activities at the beginning of a batch production (e.g., computer numerical control program testing and tool setting up) multiplied by the machine unitary cost.

The first three costs are specific for a single component, but the fourth depends on the production batch dimensions.

With similar intents of use than the LCA tool, the inclusion of this software in the platform allows understanding the impact of the change from the costs point of view. The feedback allows tuning the CM tool for more accurate change impact estimations. Cost estimation and LCA analysis have been considered and involved in the platform before other computer-aided engineering tools because of the importance of such analysis from the preliminary evaluations of a variant. In any event, the redesign platform architecture is able to integrate other kind of tools based on a similar interaction approach.

4.2. The industrial case study: Product configuration for household appliances

The proposed approach as well as the defined platform were validated on industrial case studies in collaboration with Electrolux, a global leader in home appliances and appliances for professional use. In particular, the hot division was involved and the case study product variety consisted of three kinds of products: the freestanding (FS) cooker, the built in (B-I) hob, and the B-I oven (Fig. 10).

Fig. 10.

Electrolux hot division product families.

There are about 3000 variants of these types of product, and they are upgraded and enhanced continuously. Dimensions, frame shape, number of burner and its type (induction or gas), and colors are only a few examples of properties that a marketing specialist could combine to generate a new product variant. In this context, a FS cooker was chosen as a representative product as it combines the structures of an oven and a hob, two main product types that identify the hot division.

The starting point for the functional analysis of any product was to find a function, the “black box,” that gathers the basic function of the product. For a FS cooker, this base function is “cook food” (Fig. 11).

Fig. 11.

The “black box” function for a cooker product.

Input and output flows from the black box were identified and cascaded into the product sublevels. Inputs for the base function are food, energy, and signal (e.g., inputs given by a user). The external contamination represents the dust belonging to the external environment. As output, in addition to energy, signal, and cooked food, the dross represents both the waste derived from cooked food and the dust removed, for example, from the surfaces. In the first level of the functional decomposition (Fig. 12), three key functions have been identified, recalling the three main targets of the product: safety (not only for the user but also for the product), cooking, and cleaning. Table 2 shows the whole identified functional decomposition, which moves from the three main subfunctions and reaches the third level depth. The modular product structure was derived from the third level of the functional decomposition. Stone's (Reference Stone, Wood and Crawford2000) three heuristics (i.e., the dominant flow, the branching flow, and the conversion-transmission flow) and the MFD method were used to identify the modules, which have been reported in the last column of Table 2.

Fig. 12.

First level of the functional modeling decomposition.

Table 2.

Functional decomposition of the analyzed freestanding oven

In order to define the product architecture, the BOM of a real product has been analyzed. In particular, the freestanding cooker (model ZCG6600MW, Zanussi) has been chosen (Fig. 13). Its analysis provided the recognition of the subfunctions implemented by each component of the product BOM, and the identification of the most significant components out of the BOM, which were linked to the implemented functions. Down line of this analysis, the functional auxiliary relations will be automatically stored in the structure. Each component carried out more subfunctions as reported in Table 3, where the strikethrough components were considered not significant for the analysis.

Fig. 13.

The analyzed freestanding cooker.

Table 3.

Portion of the components mapping of the FS cooker articles to the functional analysis

The industrial case study focused on a marketing specialist who wants to configure a new B-I oven variant. The first step is searching for existing configurations using the marketing interface of the configurator tool (Fig. 14). After that, the specialist may want to investigate in the parameters group “appearance” if there are variants with the “details” and a specific kind of knob [i.e., Pop In Pop Out (PIPO) color black]. The search provides only one result: model code E949714418 (Fig. 15). If the specialist wants to know if any similar configurations exists according to specific changes, the search engine finds two similar configurations as shown in Figure 16 (i.e., the configuration with a standard gray knob and the configuration with a “full glass” control panel). Therefore, starting from the initial configuration found (code E949714418), the specialist creates a new variant and can evaluate the effect of the introduced changes and its feasibility (Fig. 17).

Fig. 14.

Configurator tool in use for existing configuration search.

Fig. 15.

Example of search results.

Fig. 16.

Search results: similar configurations analysis.

Fig. 17.

Change not feasible due to incompatible parameters.

Subsequently, due to parameters incompatibility highlighted by the configuration tool, the designer investigates the effect of the introduced change by a control panel by the CM tool. As stated above, the product architecture in this case focuses on a general B-I oven configuration. The functional representation and the existing connection between components and functions allow the automatic instantiation of auxiliary functional relations. Figure 18 shows the product architecture and structure of the entire product (i.e., the oven). By selecting the right component variant from the code property, it is possible to represent the starting configuration to which to apply the desired change. Now, the impact of such change can be easily visualized on the control panel. The impact is evaluated to understand the related benefits as shown in Figure 19. The probability of components change can be estimated thanks to the functions’ parameters analysis, and represented by graphs as shown in Figure 20.

Fig. 18.

Representation in the change management tool of the product architecture of the analyzed oven.

Fig. 19.

Investigation on the change impacts.

Fig. 20.

Analysis of the probability of components change.

Finally, thanks to the connection with the LCA and the cost estimation tools, the environmental and the economical impacts of the new variant are analytically computed. The platform uses the standard system interfaces (i.e., SimaPro and LeanCOST), but data about the product characteristics (e.g., dimensions, materials, and finishing properties) are directly taken from the configuration tool to have a complete assessment of the new product variant, supporting decision making at both technical and strategic levels.