M-ARM: An automated systematic approach for generating new variant design options from an existing product family

Abstract

Companies with established product families can meet emerging market needs by extending their product families over time, that is, by introducing new product variants sequentially. Starting points for each new design can be generated by integrating design solutions from existing products in the same family. This article introduces an automated systematic approach to derive all possible ways of combining existing designs to produce a new variant with a desired new combination of functionality, based on algorithmic analysis of product models. The approach considers the functions in existing products and how they are realised in specific CAD parts and the geometric features defining them. By automatically generating and evaluating all the options, the new approach helps identify the most efficient way to combine existing parts and features from a product family to generate a new product variant with distinct functionality. The approach has been applied to product families of mechanical and mechatronic consumer products. It was evaluated by manually implementing the automatically-generated redesign instructions in CAD for several product variants, which built confidence in the approach’s accuracy and performance. From the evaluation, opportunities for further work are suggested.

1 Introduction

Many companies offer multiple products to address the needs of different market segments. To stay competitive, the product lines must be refreshed occasionally to address evolving market needs and incorporate new technologies. In many cases, the basis for a new product with a unique combination of functionality may be generated by integrating parts and functions from several existing products in the family, each offering a subset of the desired functions for the new product. This allows a company to benefit from the value of their existing design solutions. It also allows new technology from one design to be carried over to enhance other products in the family. Any required entirely new functionality may be integrated by making further changes to the generated designs.

To support design in this context, an automated systematic approach is introduced to identify and evaluate all the possible ways of generating a new product variant from an existing family of products. The new approach is called the Multiple-variant Adaptive Redesign Method (M-ARM). It leverages the Adaptive Redesign Method (ARM) by Wong and Wynn (2023), also published in this journal. Unlike most existing approaches to product variant and family redesign, which address the tasks on an architectural level, M-ARM is based on analysis of specific CAD features and their contributions to mechanical operating functions—this allows fully-automated generation of redesign options and the specific CAD operations required to implement each option. This automation allows the full space of options to be explored and evaluated rapidly. The value of the new method is to help designers systematically identify a suitable product combination approach for generating a new variant, which is not a straightforward task when the number of possible combination options becomes large and the products to be integrated have numerous parts and features. As well as supporting this task, the new approach also demonstrates the value of modelling and storing product architecture information in a design library so that design elements can be reused. Through a series of research projects, elements of the approach have been trialled on motorised security cameras, electric toothbrushes, ballpoint pens, printers, water flossers, and kitchen juicers.

1.1 Research method

Having identified the possibility of supporting variant design in the product family context, a reverse engineering method was used to build an understanding of how this could be done. A product family of four ballpoint pens—each offering various combinations of functionalities as shown in Fig. 1—was used as an initial case study to generate a dataset of product architectures and develop the M-ARM approach. The new method’s output was tested and iteratively improved by trialling a range of inputs using the pens dataset and examining the results in detail for each case. To evaluate the method’s applicability to more complex mechatronic products, it was further trialled on a family of security cameras to develop a new camera variant. These cameras are each comprised of more than 65 CAD features. The detailed assessments of the redesign plans generated by the method revealed improvements, limitations and suggestions for future work.

Fig. 1

Four pen variants forming a representative product family and their respective operating functions addressing different market needs

1.2 Article outline

This article is presented as follows. Section 2 discusses background literature to clarify the research gap and pinpoint the need for the new approach. Section 3 uses the ballpoint pens dataset mentioned above to explain and demonstrate the steps of the new approach. Section 4 discusses how the approach was evaluated. Section 5 demonstrates applicability beyond the pens through a case study of motorised security cameras. Section 6 recaps the contributions and discusses limitations and future work. Section 7 concludes this article.

2 Background and related work

A product family is a group of products that share some common design assets while also having unique attributes to satisfy different market segments or needs. Each product in a family is called a product variant. Product families allow companies to reuse tried and tested design principles and solutions—or physically identical parts and modules—across multiple products to cater to specific segments and respond to evolving market needs (Otto and Wood 2001). By leveraging product families, firms can be more responsive in the market, generating competitive advantage. Reusing existing design solutions from a product family can save new product development time and allow firms to benefit from economies of scale, which can reduce costs. Firms can also leverage brand loyalty across products in a family. However, a product family strategy also has disadvantages. These include increased risk of products sharing the same design faults, the possibility of product variants competing for the same market segments, and the increased complexity of the design, development, production and management processes, which can bring additional risks and costs to a firm (Krause and Gebhardt 2023).

Product families can be planned from scratch or incrementally developed. This research focuses on the latter situation. One reason is that deriving new products from existing products is very common in practice; perhaps 70% of design projects are associated with redesign (Chamberlain et al. 2008; Smith et al. 2012). For this incremental development of product families, two main design strategies have been observed: platform-driven and product-driven development (Alizon et al. 2006).

A platform-driven development strategy focuses on deriving a platform for future products from an existing product family. With this strategy, a company must decide which elements to make common between the existing products. Once the platform is formed, a new generation of product variants can be derived from it.

One of the tasks to achieve platform formation is to assess commonality between existing products, and hence determine which elements can be made common across the new family. This has been addressed by a range of commonality definitions and measures. For example, Collier (1981) measured commonality between product variants based on the number of reoccurring parent items for each distinct component in a product assembly structure. Wacker and Treleven (1986) measured the degree of commonality by dividing the number of physically identical components by the total number of components in a product family. Martin and Ishii (1996, 1997) measured commonality based on the ratio between the total number of unique components to the total number of components in a product family. Other than considering physical commonality, Jiao and Tseng (2000) considered the cost of shared components in their commonality indices. They observed that standardising costly components that are shared between product variants has a greater impact on product cost than standardising cheaper components. To capture the wider implications of cost on commonality, Siddique et al. (1998) considered the commonality of components, coupling between components, assembly workstation and assembly sequences for their measurement of commonality. Kota et al. (2000) considered not only these processes associated with commonality but also took into account differentiation by excluding components responsible for differentiating a product variant. Thevenot and Simpson (2006) also considered differentiation and process similarity in their measure along with cost. Alizon et al. (2006) considered differentiation not only at the product family level but also at the components level, allowing them to determine the degrees of commonality and variety between product variants even if they have different components as their platform.

Complementing these approaches for defining and measuring commonality, researchers have also proposed methods to increase commonality—that is, to form platforms by sharing design assets across existing product variants. For instance, Song et al. (2019) formed a platform based on the frequency of user-level functions between the product variants. The occurrences of the functions were captured by analysing patent data of existing product variants using a network analysis algorithm. Functions realised by larger numbers of product variants were prioritised for inclusion in the platform. Agard and Kusiak (2004) proposed clustering similar customer requirements to form functional requirements, from which function structures should be derived. In their approach, the function structures are analysed to determine the functions and corresponding physical solutions to be made common in a platform. Cheng (2012) also proposed platform formation based on customer requirements. They used a series of matrices to capture the relationships between and within the requirements and the components of each product variant. The matrices of the variants were then analysed using a clustering algorithm to determine components that can be made common between them, forming a platform. Steva et al. (2006) also used a series of matrices to form a platform by comparing and identifying not only common functions between the product variants but also their components and their inter-component connections. However, unlike the former methods, they obtained their functions based on the input and output flows associated with components to improve the consistency in functional modelling—rather than from customer requirements. Overall, the platform-driven approaches mentioned in this paragraph all focus on optimising commonality in support of a platform-driven product family strategy rather than leveraging an existing product family to derive new products one at a time to serve emerging market needs.

On the other hand, a product-driven strategy focuses on deriving a new product variant from an existing product family (Alizon et al. 2006); this is the focus of this article. Each new product variant is derived by redesigning one of the existing product variants, potentially integrating new functionalities and technologies or removing existing ones. After a new variant is created, it can be used later to derive other product variants. One advantage of a product-driven strategy is that cost efficiencies can be obtained by reusing existing designs and design principles without incurring the costs of a platform. Another is that the family introduction process is driven by iteration and feedback rather than careful upfront planning and market analysis and, therefore, is more tolerant of uncertainty. The feedback-driven approach is likely to provide more opportunities to improve the design of each product, respond to unanticipated market needs, and hence increase the likelihood of success in the market while reducing the risks of investment in a platform (Alizon et al. 2008). The benefits of deriving products by redesigning existing ones make this strategy more prevalent than platform-driven redesign in practice (Tang et al. 2010).

Overall, while a range of approaches have been developed to support aspects of product family design, there has been limited work to support the practical realisation of new designs by leveraging design solutions from an existing product family. There are a range of challenges still requiring support. Of particular interest in this article, since there are usually multiple existing variants that can realise the desired functions of a new variant design, there may be multiple possibilities of product combinations from which a new variant design can be derived; the number of options for combining designs increases with the number of product variants available to be drawn on. Related challenges for planning the new variant design effort include determining the combination approach that will require the least redesign and integration effort, determining the best parent product to use as the starting point for the new product variant, identifying which particular parts need to be carried over from which existing variants or redesigned by adding or removing features, identifying the sequence in which the redesign tasks should be done, and identifying how redesign activities can be distributed across a design team.

2.1 Approaches to support product variant design

Approaches to support product integration and redesign could potentially help address the aforementioned challenges. Most such approaches in research literature are based on analysis of product models that link functions or requirements for a product to its physical realisation—see the reviews of Eisenbart et al. (2017) and Paehler and Matthiesen (2024) for further information on such product models.

The product integration methods by Zhang et al. (2011) and Liu et al. (2014) combined all the functionality of two products to form a new variant. They achieved this using function structures to capture the functions of the existing variants. They used a product-function mapping matrix to identify the components from each of the source variants that realise each unique function, and analysed the matrix to determine components that are functionally equivalent across both variants, and hence do not need to be replicated in the new design. Similarly, Kang and Tang (2013) combined the full functionalities of two products by using function structures to obtain the functionality of two products to be merged. The functionality of the components between the two products was compared adjacently using a matrix called Function Similarity Matrix to determine what components can be eliminated in the newly combined design. Lu et al. (2017) used a similar approach to Kang and Tang (2013), which involved function structures and matrices to determine functionally equivalent components that could be made redundant in the new combination design. In their approach, they considered not only functional similarity but also the flow interaction between components of the new combination design. Kalyanasundaram and Lewis (2011) also considered the flow in their function integration method. They calculated the flow and function similarity between the components after forming the function structures of the two parent products to determine the components that will be active or dormant in the new design. By considering flow, they can identify parts of a product that can potentially be implemented with a re-configurable node to realise different functions. Overall, although the approaches mentioned in this paragraph could help designers identify which parts from two variants are necessary and unnecessary in a combined new design, they do not identify the best approach to take when there are several possible starting points in a product family context. They also operate on the architectural part or function level, not providing detailed implementation-level advice. Ong and Guo (2004, 2006) stored the specifications of product variants using an online system which enables users to search for variants to be used as a foundation architecture for a new variant design. The system provides different combinations of assemblies to address a desired set of functional requirements. Although this approach helps identify possible product combinations, it does not provide detailed support for deriving the variant solutions, for instance, by indicating parts and features that need to be removed from an identified base variant and those that need to be modified.

Fig. 2

Overview of fields in the Detailed Design Model (DDM) and steps to create it. This example shows the Cristal pen of Fig. 1. The DDM helps designers objectively determine the operating functions of product variants via partially constrained connections (P) and links them to the features and flows of the product using the references in the matrix. These connections allow extraction and reuse of particular features of the design based on desired operating functions. Adapted from Wong and Wynn (2023) under license CC BY 4.0

One approach that does offer detailed guidance for product integration by identifying specific CAD-level redesign activities is the Adaptive Redesign Method (ARM) of Wong and Wynn (2023) recently published in this journal. The ARM is leveraged in the new method proposed in this article, and hence is described in greater detail here than the other contributions mentioned so far. In overview, the ARM supports the integration of specific functions from two product variants to derive a third variant with unique functionality. This is done by systematically analysing product architecture information captured in a modelling scheme called the Detailed Design Model (DDM), which uses a matrix approach to represent each product variant being integrated. A DDM represents a product’s design in detail in functional and physical domains, also representing the interactions between these domains. It captures parts, features, flows (energy, material and signal), product states (physical configurations) and state transitions involved in the product’s mechanical operating functions. The DDM does not capture other important properties of a product, such as its dimensions, colour and material. Nor does it capture product life-cycle perspectives apart from the mechanical functions and motions needed for operation—considerations such as manufacturing processes, assembly and maintenance are not incorporated. Although such issues have a substantial impact on a product’s design, they are not considered in the DDM because it was not intended as a general-purpose modelling method—rather, its content was determined by the minimum data needed for the specific task of deriving new variants from existing ones, given desired sets of operating functions. A full description of the DDM and the modelling process can be found in Wong and Wynn (2023). The following paragraphs provide a brief overview of the DDM at the level of detail required to understand this article.

The DDM is based on a matrix format as shown in Fig. 2. The top-leftmost field of the matrix is a design structure matrix showing connections between features of the product’s parts. Each feature is directly named after a CAD feature in the CAD model defining the part. This ensures that the definition of features in the matrix is unambiguous and the results of the method can be related to concrete tasks to alter specific CAD features and parts. In the top-left field of a DDM, interactions between features are represented as either C (for fully constrained interactions between features) or P (for partially constrained interactions, allowing relative motion). In cases where two features are sometimes in contact and sometimes not, depending on the configuration of the product’s mechanisms, the interaction is modelled as P.

The DDM also captures flows of energy, material and signal through the parts of the product. These are shown in the top-rightmost field of the matrix for flows going into features and in the centre-leftmost field for flows coming out of features. The interaction between a feature and flow is a technical function (a low-level function) which is represented by a number. This number is an index reference to the function descriptor list by Hirtz et al. (2002), as outlined in the top-right of Fig. 2. For example, a flow in the ballpoint pens example is the material flow of ink (column R, row 15) from the feature Ink Chamber.Chamber body (row 15) through some features of the ballpoint tip (rows 3 to 6 showing ink outputs) through the ball feature itself (row 1 showing ink output). Mechanical interactions within the product that could be interpreted as flows, such as ‘flows of force’ or motions of parts need not be modelled because the feature-feature interactions matrix already captures them. However, flows of mechanical energy into or out of the product that cause it to operate or are the desired result of operation do need to be represented. An example is the application of force and motion to a button on the tip of a pen to extend the ballpoint tip.

Finally, the DDM represents a design’s mechanical configurations and the possible motions between those configurations, thereby capturing the mechanical operating functions. This information is indicated in the bottom-most field of Fig. 2. Here, each configuration change is captured as an initial state, a transition state involving motion, and a final state, represented as three consecutive rows in the matrix. The cells in the bottom two fields of the DDM matrix indicate which feature interactions are involved in the state indicated in the respective rows and which flows are involved. This part of the matrix is crucial to encode the parts and features involved in each mechanical operating function of the design so that the physical realisation of each function in specific parts, features, flows and interactions can be extracted. Features that indirectly support particular primary features, which directly realise functions, can be identified by tracing feature-feature interactions in the DDM.

The systematic steps of the DDM modelling procedure, which are summarised in Fig. 2 and detailed by Wong and Wynn (2023), facilitate the production of consistent data in product models. In particular, the following parts of the approach were introduced to reduce subjectivity. The approach refers to a CAD model to define the features of parts, uses defined flow types to determine technical functions, and uses mechanical configurations of a product to define its operating functions. These techniques help ensure the consistency needed so that modelled product data to be used to compare products, determine redesign activities and reference certain features of a part. When models are created by different people, it is essential to additionally ensure team members agree upon the definitions of the elements used in the model to avoid misinterpretations of the model.

Building on the DDM, the Adaptive Redesign Method (ARM) is a systematic manual procedure for combining two product variants modelled using the DDM to produce a detailed list of instructions for deriving a new product variant with a unique combination of operating functions by specific modifications to the CAD parts and features. An in-depth description of the ARM can be found in Wong and Wynn (2023). In overview, the ARM proceeds as follows:

• 1. Decide the operating functions desired in the new product variant, drawing from those available in the two starting variants.

• 2. Decide which of the two existing variants will be modified to produce the new variant (called the base variant) and which will be the source for carry-over parts and features (called the source variant).

• 3. Identify parts and features of the base variant that are undesired in the new variant and remove them because they are not directly required for any desired function.

• 4. Identify parts and features of the base variant that only support those undesired features and remove those as well, recursively.

• 5. Identify parts and features (including directly and indirectly supporting parts and features) that must be carried over from the source variant to realise desired functions.

• 6. For individual features that must be carried over from the source variant instead of entire parts, determine the existing base variant parts to which they need to be added. This is achieved by systematically processing the feature-feature and flow-feature fields of the DDM, using a comparison matrix to manually determine the base variant part that is most similar in terms of technical functions and physical interactions to the source variant part from which the feature was obtained.

• 7. Output a detailed list of redesign activities for the new variant design by manually processing the values in the comparison matrix one at a time. The list can then be used to derive the new variant design using a CAD system, allowing the dimensions of existing parts to be adjusted. These changes to dimensions are not indicated by the method, which does not capture spatial geometry.

Overall, the DDM offers a detailed modelling approach connecting a product’s parts and features to the CAD-level definitions, allowing the ARM to produce detailed guidance for integrating specific functions from one product to another. However, the ARM focuses on the technical issue of integrating two selected variants in CAD—it does not help with the more strategic question of how best to form a new variant given many possibilities for combining existing designs in different pairs, triples, etc. The ARM is also time-consuming to execute manually due to the many processing steps required.

Fig. 3

The steps of the Multiple-variant Adaptive Redesign Method (M-ARM), which determines all options for integrating a set of product variants to produce a new combination of operating functions, and provides guidance on which option would be most efficient to implement in CAD

2.2 Research gap and objective

To recap, companies rarely design new products from scratch but seek to reuse design assets from their existing product lines. Design methods could support the required combination decisions as well as the redesign and integration activity itself. However, no current method can provide support on the CAD feature level to help determine the possible ways to form a new variant design. Existing methods to support product family design mainly focus on architectural and strategic issues such as modularity, commonality and changeability—but do not provide detailed guidance for implementing redesign. The ARM supports detailed analysis at the CAD level and provides detailed redesign plans, but focuses only on the technical integration of particular functions between two selected variants.

Overall, no existing approach can provide support for new variant design in product family situations in which functions and their realisations can be drawn from several product variants to form the new variant, while also providing detailed instructions for the redesign work. To address this gap, this article introduces a new approach that helps answer the question: When there are multiple source variants from which desired functions could be drawn, what product combinations are possible and which combination will require the least amount of redesign effort to derive?

3 Multiple-variant Adaptive Redesign Method

The new method is called the Multiple-variant Adaptive Redesign Method (M-ARM). Its steps are summarised in Fig. 3. Conceptually, the approach’s processing is not complicated, as shown in the figure. Nevertheless, substantial iterative development and testing were required to fully realise this concept and show that the entire process can be automated and produce appropriate results across a range of cases. Given the substantial amount of processing required, this automation is essential so the method can be used to fully explore the space of redesign options, and hence address the objectives of this article.

In the next subsections, the approach is described with the intention to provide enough detail for reproduceability. The four ballpoint pens shown in Fig. 1 are used as a product family to demonstrate the steps of the new method.

3.1 Step 1. Model existing product variants and select desired functions for new variant

To form the database of product designs for the method to draw on, existing variants in the product family must first be modelled using the DDM. These product models need only be created once, after which they can be reused for future applications of the M-ARM method.

To apply M-ARM, the subset of product variants to be used as starting points and the desired set of operating functions for the new design must be selected as shown in Fig. 4. For the running example, all four pen variants shown in Fig. 1 are selected as potential sources, and the following desired operating functions are chosen: to deposit ink, to extend ballpoint tip, to retract ballpoint tip, to reveal banner, and to hide banner. Note how none of the selected starting variants offers this specific combination of functions—a new pen design is required.

Fig. 4

Selecting variants from a DDM design library and selecting the desired operating functions to be integrated from them to create a new variant design

Fig. 5

Derivation of all possible ways to generate a desired new pen variant from an existing family of pens

3.2 Step 2. Generate all product combination options

Next, all possible combination options to achieve the desired set of operating functions are systematically generated.

The DDMs are first processed to map the selected product variants against the superset of operating functions realised—see Fig. 5(1) for the pens case. The bottom row indicates the new variant’s desired functionality.

In the approach, to obtain a product with a new combination of operating functions, a single starting point design is first selected (called the base variant); additional necessary functions are then integrated into it by carrying over parts and features from other designs (called the source variants). Any of the products can potentially be used as base variant. Therefore, a new matrix is created to determine which desired operating functions are realised by and missing from each possible base variant—see Fig. 5(2). This matrix is then processed to determine which variant(s) each missing operating function could be sourced from, as shown in Fig. 5(3). The ticks in the earlier table are replaced with the base variant name to indicate that those desired operating functions will be provided by the base variant. The crosses are replaced with the names of all variants that realise the respective functions.

Fig. 6

Redesign activity list for a new pen variant that integrates two pens. Each row represents a single specific instruction to adjust a specific CAD feature. The list shows base and source variant features that need to be removed, retained, carried over and examined to derive the new pen variant. Keys for feature types: Uf = undesired feature, Usf = undesired supporting feature, Df = desired feature, Dsf = desired supporting feature. Reproduced from Wong and Wynn (2023) under license CC BY 4.0

Finally, the combination options are generated and used to create the matrix shown in Fig. 5(4). To illustrate, consider the first base variant of Fig. 5(3)—Cristal. When this pen is used as base variant, one possible combination to achieve the desired set of operating functions is [Cristal, Clic, Clic, Banner, Banner], indicating that to deposit ink is already realised by the Cristal pen, while to extend ballpoint tip and To retract ballpoint tip are to be carried over from the Clic pen, and to reveal banner and to hide banner are to be carried over from the Banner pen.

3.3 Step 3. Generate activity lists for pairwise integrations

The source variants for each combination are next integrated into the base variant in a pairwise way as indicated in Fig. 3, using an automated version of the ARM algorithm of Wong and Wynn (2023). The processing is quite intricate and fully explained with examples in the earlier article. Each pairwise integration results in a list of redesign activities to realise the integration. In overview, the lists contain three types of activities: remove a base variant feature because it is not required, retain a base variant feature which may require geometric adjustment, and carry over a source variant feature or entire part into the base variant. For each redesign activity, the ARM also determines whether the activity is definitely required, or whether the associated feature requires manual examination to verify whether it can realise a particular function or is needed to support another feature.

An example redesign list resulting from the algorithm is shown in Fig. 6. This example has 26 activities; however, the automatically computed lists can comprise several hundred activities for more complex products. Note how each activity (row) in Fig. 6 concerns a unique CAD feature. Each feature of the base variant appears exactly once in the list (retain, remove or examine the feature for inclusion in the new design) while only some of the features of the source variant appear in the list (carry over or examine the feature for potential carry-over). The notes column, automatically generated by the ARM, helps to interpret the list when working through it to execute the integration in CAD.

Continuing the example, when using the Cristal pen as the base variant and examining the product combination [Cristal, Clic, Clic, Banner, Banner], the ARM will be executed twice, which is an automated process requiring no intervention from the designer. First, the to extend ballpoint tip pen function and to retract ball tip functions will be integrated from the Clic into the Cristal pen, followed by to reveal banner and to hide banner from the Banner pen into the Cristal in the second pass. In this case, the ARM will produce two redesign lists, each comprising detailed instructions to generate a design having a subset of the desired functions.

3.4 Step 4. Merge lists and remove duplicate activities

The redesign activity lists generated from the previous step are then merged to produce a single list per combination option; in this case, 10 lists will be generated after merging. Duplicates can occur in the merged lists because the ARM executes several independent pairwise integrations. For instance, in the running example, the redesign activity of removing the Cap part from the Cristal pen appears on every pairwise integration. Such duplicate activities are identified and removed.

3.5 Step 5. Post-process redesign activity lists

Fig. 7

Redesign options automatically generated by the M-ARM for the ballpoint pens example, showing the types and numbers of redesign activities required to implement each option. In this case, the method identifies that the option Pen Combination 10 requires the fewest redesign activities to derive. Key: BV = base variant, SV = source variant(s), UC = unrealistic combination

The resulting lists are postprocessed because they may contain partial duplicate instructions, in particular 1) instructions with duplicate features and redesign activity types but different notes, and 2) instructions with duplicate features but different redesign activity types and notes. Processing partially duplicated instructions streamlines the process for the designer, minimising rework.

To address the first partial duplication scenario (rows with duplicate features and redesign activities but different notes), the duplicate features and redesign activities are merged into a single row while the notes are concatenated to retain the design information. For example, if the same feature is to be examined twice to consider whether it is needed to support two different carryover features, the tasks will be merged into a single row that indicates both issues should be considered simultaneously.

The second duplication scenario (rows with duplicate features but different redesign activities and notes) occurs only with the activities ‘retain’ and ‘examine’ for base variant features. To address this, base variant features with the redesign activity ‘retain’ are overridden by the redesign activity of ‘examine for potentially retain’ because the latter indicates that a decision is needed. For instance, the final status of the Ballpoint tip.Ink funnel of the Cristal pen is elevated from being retained to being examined. In this case, the designer needs to consider whether the existing design of the Cristal pen Ballpoint tip.Ink funnel can retract through its Barrel.Ballpoint funnel to achieve the retractable function compared to directly reusing the ballpoint ink funnel to achieve the banner function.

3.6 Step 6. Visualise and compare the redesign options

Finally, a summary chart is generated to show all the possible product combination options and highlight those requiring the fewest redesign activities, as shown in Fig. 7. The chart also indicates which product combinations are unlikely to be sensible options because complementary operating functions are to be sourced from different products. These nonsensical combinations are automatically determined by comparing references in the operating functions sections of the DDM to identify complementary functions, and detecting when a complementary function is sourced from two different variants. For example, it is unlikely to be effective to carry over to extend ballpoint tip from the Clic (a retractable ballpoint pen) and to retract ballpoint tip from the Atlantis (another retractable pen). These unrealistic options usually contain a high number of redesign activities.

In this case, the method output as summarised in Fig. 7 reveals four potentially sensible (effort minimising) ways of creating a new variant with the desired functionality—these design options represent different pen combinations and only require integrating two variants. The figure also reveals several ways of achieving the new variant by combining three or four pens, but these are substantially less efficient in terms of the number of redesign activities required. Of the two-pen combination options, the chart suggests that the redesign effort is likely quite similar, although one option entails slightly fewer activities and hence is recommended. A designer would need to consider these options and make an expert judgement which to take forward. Once this decision is made, the selected redesign list provides a detailed basis for planning and executing the CAD work.

3.7 Summary

The Multiple-variant Adaptive Redesign Method (M-ARM) supports new variant design in a product family context. The new approach identifies all possible product combination options that could be used to form a new variant from a design library, and identifies the combination that will require the fewest CAD operations to derive. Although the processing is intricate, it was found possible to fully automate. Once product models are available, it is straightforward to generate detailed redesign processes using the approach to create a new variant having any combination of their functions.

The method only currently evaluates the number of activities in the processes for generating a new design having desired functionality—it does not consider the qualities of the resulting designs when identifying the best redesign option, such as ease of assembly or types of materials used. The method also does not indicate non-CAD activities that would be required to complete the design, such as engineering analyses, testing and documentation. However, the redesign list generated from the method provides a basis for planning such activities by showing all individual parts that will be changed.

4 Verification

The method will only be useful if it reliably generates accurate redesign processes that can be followed and reflect the actual activities a designer needs to execute to complete the design integration.

Therefore, careful attention was dedicated to verifying the generated redesign lists. The intermediate steps of the method were initially verified by manually checking the outputs for the pens example with two variants only. Performance testing was then done by introducing more variants and operating functions, leading to code optimisation to improve scalability. Once the code could run at scale, black box testing was used. The code was run on different combinations of the products and desired operating functions, and the results were tested by manually implementing the generated redesign lists on CAD. The following steps were performed to implement each redesign list and check its accuracy:

• 1. Sort the list in terms of feature type and highlight the types in different colour tones to assist readability.

• 2. Sort the list again but in terms of parts and apply a secondary sort in terms of redesign activities, which generates a readable sequence for execution.

• 3. Create a new assembly drawing in CAD.

• 4. Add the existing parts that are on the list into the assembly drawing.

• 5. Go through the list part by part, starting with the parts with mainly desired features first.

• 6. Within each part, go through the redesign activities and determine whether certain features should be retained. Obvious features that are not needed are removed first from the first round of iteration. Removal of uncertain features can be left in the next round of iteration.

• 7. After the first round of changes, form subassemblies by assembling parts from the same variant first.

• 8. Assemble sub-assemblies between different variants. Dimensional changes may be required in this step.

• 9. Repeat steps 5 and 8 until the assemblies physically fit together.

• 10. Check the redesign list against the actual CAD model to determine the accuracy of the design list generated by the method.

Boundary testing was also performed, involving extreme inputs to ensure the outputs remained sensible. Examples of these tests included DDMs having the wrong format, only one product being selected as a source variant, and cases where all the desired operating functions already existed in one of the selected products.

These verification activities revealed issues in the approach, which were corrected progressively as they were identified. Some of these issues are summarised in the next paragraphs.

First, it was found that the order of identifying the redesign activities mattered. For instance, if a base variant feature is deemed to require examination because of functional similarity to a desired source variant feature, then logically it cannot be categorised as a feature to be retained later in the analysis. This was resolved by adjusting the code so that, as mentioned earlier, some types of redesign activities appearing in the list override others when the same feature appears multiple times.

Second, it was determined that the approach could not distinguish between different types of energy inputs to a design, leading to the calculation of incorrect similarities between base variant and source variant features. The issue was addressed by ensuring the products were modelled in sufficient detail in the initial DDM models. In particular, instead of using a simple description of “energy” to describe mechanical energy flow inputs and outputs while operating a product, forces applied and the direction of the forces were used to describe each of those flows. These force descriptions were sufficient to distinguish various types of interactions used to operate a product in different ways. The automated method was then able to correctly associate the features between the variants that were functionally similar without needing to modify any of its steps. This also showed that the method works with various descriptor systems for modelling flows as long as the product variants are modelled consistently.

Third, it was realised that when the ARM is executed manually as originally described by Wong and Wynn (2023), the method user has opportunities to apply their judgement to the output of individual method steps before the information is propagated to the next step. A particular challenge for the algorithmic implementation (which is part of Step 3 of the M-ARM) was to ensure the correct identification of supporting features, that is, identifying the need to carry over features which do not directly realise a desired function but are necessary to support its realisation. The manual ARM provides opportunities to make decisions on whether such potential supporting features are likely to be required, and hence whether they should be carried over—the user can make common-sense judgements based on their understanding of the designs being integrated. However, the algorithm cannot make such case-by-case judgements since it can only decide based on the patterns of dependency in the DDM. This is particularly challenging because of the need to check features directly supporting a required carry-over feature, second-level features that support those, and so on. A simple tracing of all dependencies outward from a desired feature would ultimately require all features in the design to be categorised as potential supporting features. This was resolved by considering the number of steps away from the desired feature; for example, Dsf indicates all features that are one step from a desired feature and thus potentially support it, Dsf1 indicates potential second-level supporting features, and so on. The features are prioritised in the redesign list such that those identified as Dsf are examined first for potential inclusion. The more steps from a desired feature, the less likely the feature will be required to support it, and the lower the corresponding redesign activity should be weighted in assessing the likely redesign effort.

5 Application case study

Once the verification based on the pens had been completed, an application study was performed to test the approach on a family of more complex products—internet protocol (IP) security cameras. The purpose was to assess the approach’s applicability to products beyond the pens and to those with substantially more operating functions and features. Three cameras were selected to form a representative product family: Fixed, Pan-Tilt (PT) and Pan-Tilt-Zoom (PTZ)—see Fig. 8.

Fig. 8

The internet protocol (IP) security camera variants used to form the case study for testing the method

As before, a reverse engineering approach was used to tear down and examine the product designs in detail before building the DDMs. The M-ARM was then applied to derive a new camera design with the following operating functions, which do not exist as a set in any of the three existing camera variants:

• 1. Tilt forwards and backwards

• 2. Tilt upwards and downwards

• 3. Pan clockwise and anticlockwise

• 4. Zoom in and out of an object

• 5. Focus in and out on an object

Reflecting the method’s focus, the case study only considers the operating functions involving mechanical motion. Software-only functions were not considered.

5.1 Applying the method

The three cameras were disassembled and modelled using CAD, requiring approximately 4 weeks of full-time work to model 543 features. This would not be required in an industrial context where CAD models are already available. The DDMs were then created, which took approximately 16 h in total. Although somewhat tedious, the modelling effort is relatively low compared to a typical product development project, and only needs to be performed once to populate the design database. Once the DDMs had been formed for each camera, they were fed into the M-ARM programme to generate the redesign activity lists for a new product variant with the functionality mentioned above. The computation itself took approximately 3 min, which could be accelerated by implementing the method in a heavyweight programming language rather than spreadsheet macros.

The algorithm generated six different product combinations for the new camera design. As shown in Fig. 9, two combinations involved only two cameras to derive the new camera design: the Fixed camera and PTZ camera. These two combinations entailed fewer redesign activities than the other options, which required all three cameras. The figure also shows that the sequence of integrating products matters and results in different sets and numbers of redesign activities.

Fig. 9

Numbers and types of redesign activities for each camera combination generated to implement the new design in the cameras case study. The chart indicates that Camera Combination 4 requires the fewest redesign activities to derive compared to other camera combinations. Key: BV = base variant, SV = source variant(s)

5.2 Verifying the method output

Any of the corresponding redesign activity lists would provide suitable instructions to generate the new design. Camera Combinations 4 and 1 were chosen to be verified using CAD. Camera Combination 4 was selected because it had the fewest redesign activities. Camera Combination 1 was chosen because it involved integration of three designs. The CAD models created by following these lists are shown in Figs. 12 and 13 respectively; each required approximately 10 h to create manually.

In each case, a new CAD assembly drawing was first created and the parts for which most of their features are needed in the new design were placed into it in an approximate arrangement. Each part was then adjusted by working through the respective section of the activity list and modifying the individual features as indicated. Once the features had been modified, the parts were assembled while concurrently making the required geometric adjustments.

The features in the completed CAD models were then compared to the list of features generated from the method to determine whether the method had provided reasonable suggestions. For Camera Combination 4, of the 328 CAD features appearing in the redesign list, 53 required manual examination for potential inclusion and were ultimately excluded from the CAD design. Overall, the method identified all necessary CAD activities plus another 16% of activities that in reality required no redesign work. The equivalent numbers for Camera Combination 1 are shown in Fig. 11.

Figures 10 and 11 summarise the percentage of features the method suggested should be included or examined for potential inclusion versus those actually included in the final CAD model, indicating how this was distributed across the different classes of features identified by the algorithm. The figures show that as the ranking of desired supporting features increased, the number of those features the designer was instructed to consider decreased, and the number of features actually used in the CAD model also decreased. This reflects expectations because, qualitatively, the more steps away a desired supporting feature is from a desired feature, the less likely it is actually needed to support that desired feature.

Fig. 10

Table showing the percentage of each feature type in the generated redesign list that was actually used in the new variant design for Camera Combination 4. The aggregated values in the table indicate that for this variant combination, the method is 84% effective in determining the likelihood of a feature being required in the actual design

Fig. 11

Table showing the percentage of each feature type in the generated redesign list that was actually used in the new variant design for Camera Combination 1. The aggregated values in the table indicate that for this variant combination, the method is 72% effective in determining the likelihood of a feature being required in the actual design

Fig. 12

Assembled view of new camera variant design derived from Camera Combination 4, comprising 275 CAD features in total. Parts in black are from the Fixed IP camera (base variant) while parts in white are from the PTZ IP camera (source variant)

Fig. 13

Exploded view of new camera variant design derived from Camera Combination 1, comprising 276 CAD features in total. The black parts in the upper half of the figure belong to the Fixed IP camera (base variant), light grey parts in the upper half of the figure belong to the PTZ IP camera (first source variant) and the remaining parts in the lower half of the figure belong to the PT IP camera (second source variant)

Finally, two more camera case studies were performed to evaluate the method in different redesign scenarios. The first scenario was to implement the automatic pan function from the PT IP camera into the Fixed IP camera to derive a new camera with a motorised pan function that can be manually tilted forwards, backwards, upwards and downwards. The second scenario was to implement the zoom and focus function from the PTZ IP camera into the PT IP camera to derive a new IP camera with motorised pan and tilt functions, along with zoom and focus. The method generated one camera combination for this test: the PT IP camera as the base variant and the PTZ IP camera as the source variant. These tests helped to verify and refine the method further.

5.2.1 Insights from implementing the redesign lists in CAD

The case study provided insights into the processes of interpreting and implementing the redesign lists produced by the method.

First, it was discovered that the automatically-generated redesign lists were easiest to implement in CAD when sorted based on parts followed by the type of redesign activity. This is because a parts-based redesign sequence aligns with how parts are represented in separate files in CAD. This organisation also made it possible to determine which product in the combination is most efficient to be modified geometrically to physically fit with the other features based on the number of parts in the list. The product with the fewest parts in the list is usually more efficient to modify because this will lead to less change propagation while executing the geometric adjustments. For instance, the diameter of the Fixed IP camera base cover and its height were increased to fit with the base cover of the PTZ camera instead of shrinking the base cover of the PTZ to fit the base cover of the Fixed IP camera. This is because the base cover of the PTZ camera interacts with several other features, so changing it will cause further feature changes.

Second, it was found easier to implement the change susing a breadth-first top-down approach starting from the parts level, followed by the features level and then the dimensions level, rather than integrating one source variant after another whilst going through all the levels for each source variant. This was particularly evident when deriving Camera Combination 1. After placing the parts from all three cameras in the assembly drawing, the features for each part were compared against the generated redesign list to determine which should be removed, retained and adjusted, or added. Once the features were finalised, the dimensions of the features were resized to make them fit each other. Some alternating between the features level and the dimensions level did occur, but overall, as the design matured while the list was being worked through, the focus shifted from the features level to the dimensions level.

Experience of the CAD implementation of redesign lists also revealed that as more source variant features were being added, it was usually easier to adjust the dimensions of the base variant to accommodate the new source variant features rather than adjusting the dimensions of each newly added source variant feature. Changing dimensions on both base and source variants was sometimes needed for the parts to fit physically.

Third, it was observed that ranking supporting features as Dsf, Dsf1, DSf2 and so on helped to decide which supporting features from which variant to use when multiple supporting features are available to support desired features. For example, the rear cover of the Fixed IP camera was used in the new design instead of the rear cover of the PTZ IP camera because the Fixed IP camera rear cover had supporting features with a higher ranking (ranging from Dsf to Dsf1) than the supporting features of the PTZ IP camera rear cover, which could alternatively have been used (ranging from Dsf3 to Dsf5).

6 Discussion

6.1 Recap of contributions

The new approach introduced in this article automatically identifies all ways of combining existing designs to derive a new product variant design with unique functionality. It also automatically generates the CAD redesign activities for each design option, which allows designers to determine the design option that is most efficient to derive in terms of redesign activities. It achieves this by automatically processing the product data represented in the Detailed Design Model of Wong and Wynn (2023). Automation of this approach was crucial to determine all design options because manually processing the data would be infeasible, especially when analysing product families with many variants and large numbers of features per variant.

The approach can support some of the important tasks when generating design solutions from an existing product family, particularly in the early stages of considering options, producing plans, and assessing likely redesign efforts. It may be particularly helpful for planning the work in collaborative environments where the redesign lists could provide a basis to delegate design tasks evenly, such that different designers could work concurrently to implement the required design changes.

6.2 Limitations and future work

The approach’s potential has been illustrated through reverse engineering case studies of two product families—this has also revealed opportunities for further development and improvement. The most useful is probably to investigate the automation or partial automation of the initial DDM modelling which could be achieved by extracting CAD data. Such an approach has been explored by other authors, for example, by Li and Xie (2015). These authors extracted data from CAD assembly drawings to form a DSM showing the dependencies between components. Automated knowledge extraction would reduce the effort required to form DDMs, thus enhancing the method’s practicality. Secondly, automating the CAD redesign activities to generate the new variant design could also be investigated. Perhaps automating these steps will, in future, be feasible using AI.

In practice, redesign and product integration require consideration of many more issues than the carryover of functions, parts and features. The method is not intended to address these issues; however, it could potentially be expanded to become more aware of a broader range of considerations and constraints in redesign. For example, it might be extended to consider carrying over or replacing entire modules of one design to another, which could be desirable for various reasons such as recognising off-the-shelf or platform parts that a designer does not wish to change. Also, the current approach only compares products at the mechanical features level and does not consider the needs of other design domains. An example of this can be seen in the cameras case study, where the method would suggest integrating the motherboards of the PTZ or PT camera with the motherboards of the Fixed camera to realise the pan function. However, an alternative solution would be to reuse the entire circuit system of either the PTZ or PT cameras to realise the pan function because the motherboards of those cameras can already realise some of the other user functions of the Fixed IP camera.

Future work could also investigate evaluating the quality of function realisations within different designs in the DDM library to provide a more refined basis for ranking redesign options. This might be done based on analysis of information already captured in the DDM or might draw on additional information—perhaps based on customer evaluations of product variants or other data collected from the product use phase, such as the reliability of particular mechanisms—or perhaps based on new fields added to the DDM modelling scheme to capture relevant information, such as the cost of each part and feature in each existing variant, or the manufacturing and assembly operations required.

Although the method can integrate specific operating functions into a product by identifying and merging specific features required to realise them, it does not consider the holistic factors that influence a product’s design, such as aesthetics and ergonomics. For instance, the camera design in Fig. 12 contains all the necessary features to technically realise the desired operating function. However, the design requires further refinement on its aesthetics and ergonomics to bring it to a consumer-ready form.

On a more detailed level, the algorithm also has some limitations revealed by the in-depth analysis of the case studies. One limitation is that it classifies some features as desired supporting features which need to be examined for potential carryover in some cases where a designer can immediately see that they are not necessary. For example, in the camera case study, the WiFi antenna. Connector was classified as a supporting feature (Dsf4) rather than an undesired feature (Usf). This classification was made because the connector is linked to a desired carryover feature through four levels of supporting features, even though its only purpose is to secure the WiFi arm.Connector, which realises an undesired operating function. Although the method is conservative at informing designers to consider retaining potentially unnecessary features in the new design, it leads to inefficiencies because time must be spent considering the recommended checks. An M-ARM enhancement that would consider feature functionality in ranking supporting features might address this overzealous identification of potential redesign tasks, which constituted about 16–28% of the tasks for the cameras case, as previously mentioned.

A second issue revealed by the camera case study is that the M-ARM cannot distinguish features with identical technical functions but with different specifications. For instance, when the zoom and focus functions of the PTZ camera were integrated into the PT camera, the method perceived the zoom and focus motors of the PTZ camera as functionally similar to the pan motor and tilt motor of the PT camera because of the motors’ identical functions. As a result, the method suggested integrating the supporting features of zoom and focus motors to the pan and tilt motors, which is incorrect. A solution to this problem would be to represent the different specifications of technical functions in the DDM, so that the M-ARM could differentiate features with different specifications but identical technical functions. Although the method could be made more accurate to avoid some misclassification of features, there is a tradeoff: more information would be required in the underpinning DDM models.

7 Concluding remarks

Deriving new product variants from an existing product family enables existing design assets to be leveraged when introducing new products. This article has supported the task by introducing a systematic approach that automatically generates all the different ways to combine existing products to produce new variant design solutions with a desired set of operating functions. For each design solution, a list of redesign activities is automatically generated at the CAD feature level, which can be used to derive the new designs. These redesign activity lists can be compared to determine the design solution that requires the least design effort to derive. Judgement and design experience are required by designers when implementing the method’s output in a CAD system and integrating design issues beyond CAD modelling.

The approach has been implemented in spreadsheet software and verified through a reverse engineering study of two product families. A range of redesign activity lists generated by the method were examined in detail and implemented manually in CAD to assess their accuracies. The tests revealed that the method results had an average level of 78% accuracy in terms of determining the features needed in the physical design, which provided a good level of guidance for planning and executing the CAD work.