2.1. Conceptual design and solution principles

In technical product development, the conceptual design phase forms the critical link between defining what a product must achieve and determining how it will achieve it. The process begins with a clear problem definition and the creation of a requirements list, which compiles all essential specifications, constraints, and target functions for the design task (Reference Pahl, Beitz, Feldhusen and GrotePahl et al., 2007; VDI 2221-1, 2019; Reference Schlattmann and SeibelSchlattmann & Seibel, 2021). Typically organized in tabular form, this list serves as a living document that evolves throughout the project and provides a consistent reference for evaluating and selecting design concepts. It ensures that subsequent decisions during concept development remain traceable to the original technical and economic objectives.

According to VDI 2222-1 (1997), a function defines the basic transformation relationship between a system’s inputs, internal processes, and outputs as it fulfils its intended purpose. Expressing these functions in concise verb–noun formulations helps avoid premature fixation on specific solutions, thereby fostering innovative thinking. The product’s purpose is first described through an overall function, often represented as a black-box model that illustrates the transformation of material, energy, and information. This overall function is then decomposed into subfunctions, each representing a partial task necessary to achieve the overall goal. The resulting functional structure—expressed in tables or block diagrams—clarifies the relationships among subfunctions and provides a logical framework for exploring alternative technical realizations.

Based on this functional model, designers identify and combine physical effects to form solution principles. A solution principle, as defined by Reference Pahl, Beitz, Feldhusen and GrotePahl et al. (2007), is the fundamental idea that determines how a technical function is realized. It combines an appropriate physical effect with the required geometric and material characteristics to achieve the desired transformation. The development process involves identifying physical effects capable of fulfilling subfunctions, combining them into working principles, and synthesizing these into a coherent working structure that performs the overall function. The result is a set of principle solution variants that represent potential technical concepts for further evaluation.

Reference RothRoth (2000) emphasizes that a solution principle is the core physical and geometric method by which a function is fulfilled, independent of its detailed embodiment. In his approach, design catalogues (Reference Roth and ChakrabartiRoth, 2002) serve as a structured source of proven principles that can be systematically combined to address specific subfunctions. Reference Hubka and EderHubka and Eder (1996) interpret the solution principle as the organ structure—the network of effect carriers that realize the functions defined in the function structure. Their model highlights that developing a solution principle means translating functional requirements into interacting organs that together achieve the overall purpose.

Once several solution principle variants have been generated, a systematic selection and evaluation process ensures that the most suitable concept is chosen. Reference Pahl, Beitz, Feldhusen and GrotePahl et al. (2007) describe this as a two-step procedure: first, an initial screening eliminates infeasible or incompatible variants based on hard criteria such as technical viability and cost; second, a detailed evaluation applies a weighted point-scoring method that assesses both technical and economic performance, akin to the cost-benefit procedure outlined in VDI 2225-1 (1997). Reference RothRoth (2000) and Reference Koller and KastrupKoller and Kastrup (1998) propose similar approaches, dividing evaluation criteria into technical value (e.g., functionality, safety, ergonomics) and economic value (e.g., material and production costs). Weighted aggregation of these criteria allows objective comparison of alternatives and supports transparent design decisions.

The conceptual design phase thus establishes a structured progression from requirements to functions and finally to solution principles. The requirements list defines what must be achieved, the functional model clarifies what must be done, and the solution principles specify how it can be realized. This hierarchical linkage ensures that design concepts remain consistent with functional needs and project goals, while maintaining flexibility for innovation. By systematically developing, evaluating, and selecting solution principles, designers create a rational foundation for embodiment and detailed design, ensuring that each decision is traceable to both technical logic and economic justification (Reference Koller and KastrupKoller & Kastrup, 1998; Reference RothRoth, 2000). In the context of this work, these established models provide the conceptual scaffolding, while the MILP formulation offers a quantitative mechanism for automating parts of the selection and evaluation process.

2.2. Computational methods in conceptual design synthesis

The automation of solution principle (SP) selection marks a significant progression in conceptual design research, aiming to reduce reliance on manual reasoning and improve the efficiency of mapping functions to physical solutions. Earlier conceptual design frameworks such as those developed by Reference Chakrabarti and BlighChakrabarti and Bligh (1994, Reference Chakrabarti and Bligh1996) laid the groundwork by establishing systematic, rule-based methods for functional reasoning and synthesis. These approaches introduced recursive problem decomposition and knowledge-guided synthesis, where functions were transformed into structural solutions through iterative refinement. However, the process remained largely manual, requiring expert designers to interpret functional requirements and select appropriate SPs from existing knowledge bases.

Later developments built upon this foundation by introducing computational and knowledge-based synthesis methods. For example, Reference Qi, Hu, Zhu and PengQi et al. (2015, Reference Qi, Hu and Peng2018) automated functional–structural synthesis through the integrated and the hybrid principle solution synthesis (IPSS and HPSS) methods. These frameworks employed intelligent agents to chain compatible principle solutions based on input–output flow matching, while fuzzy multi-criteria decision-making techniques (Reference KahramanKahraman, 2008) were used to evaluate and select the most promising combinatorial solutions. By incorporating Extenics theory to resolve structural conflicts (e.g., vibration or interference), these systems demonstrated how automation could not only accelerate design generation but also improve feasibility and multidisciplinary coherence.

Building on these advances, Reference Rosenthal, Liebert and NiggemannRosenthal et al. (2025) proposed a formalized and optimization-driven approach for automated SP selection. Their solution principle structure finder applies an A*-based search algorithm to identify minimal, non-redundant sets of SPs that completely satisfy a function structure. Using standardized Roth functions (Reference RothRoth, 2000) and constraint-based combination rules, the SPSF systematically explores and ranks potential SP configurations. The approach ensures that the resulting conceptual designs are both complete and computationally efficient, offering a reproducible framework that reduces human effort while maintaining interpretability.

Meanwhile, the universal conceptual modelling (UCM) framework (Reference Lukyanenko, Samuel, Parsons, Storey, Pastor and JabbariLukyanenko et al., 2024) provides a broader theoretical context for such automation. UCM emphasizes modularity, minimalism, and accessibility in conceptual modelling, principles that can guide the development of automated SP selection systems that remain understandable and adaptable for both experts and non-experts. When combined with algorithmic synthesis methods (Reference Rosenthal, Liebert and NiggemannRosenthal et al., 2025) and knowledge-based reasoning frameworks (Reference Chakrabarti and BlighChakrabarti & Bligh, 1994, Reference Chakrabarti and Bligh1996; Reference Qi, Hu and PengQi et al., 2018), these principles help ensure that automated systems not only generate solutions but also remain transparent and human-centred. In summary, the evolution from manual to automated SP selection reflects a gradual integration of functional reasoning, computational synthesis, and universal modelling principles.

However, most existing approaches either focus on minimizing the number of selected solution principles, clustering requirements, or rule-based synthesis; they rarely incorporate a quantitative, system-wide compatibility objective into a single optimization model. This gap motivates the MILP-based approach proposed in this paper.

3.1. Problem overview and complexity

We address the problem of selecting an optimal set of categorical solution principles in early-stage conceptual design. Given a functional decomposition $$F$$ , each function $$f \in F$$ is associated with a finite set of candidate solution principles $${P_f}$$ and a set of local requirements $${T_f}$$ . The objective is to select exactly one principle per function such that both requirement satisfaction and cross-functional compatibility are jointly optimized.

Two types of incompatibility are considered:

• • Local requirement incompatibility $${d_{fpt}} \in \left[ {0,1} \right]$$ , representing how poorly principle $$p \in {P_f}$$ satisfies requirement $$t \in {T_f}$$ .

• • Cross-functional incompatibility $${D_{fp,gq}} \in \left[ {0,1} \right]$$ , representing the incompatibility between principles $$p \in {P_f}$$ and $$q \in {P_g}$$ for $$f \ne g$$ .

Requirement importance weights may also be specified. In this study, all weights are set to 1.

Binary decision variables are defined as Equations (1) and (2):

(1)

(2)

The total incompatibility to be minimized is Equation (3)

(3) $${\min \left( {\mathop \sum \limits_{f \in F} \mathop \sum \limits_{p \in {P_f}} \left( {\mathop \sum \limits_{t \in {T_f}} {w_{ft}}\;{d_{fpt}}} \right){x_{fp}} + \beta \mathop \sum \limits_{\mathop{f,g \in F}\limits_{\displaystyle{_{f \lt g}}}} \mathop \sum \limits_{p \in {P_f}} \mathop \sum \limits_{q \in {P_g}} {D_{fp,gq}}\;{y_{fp,gq}}} \right),}$$

where $$\beta \in \left[ {0,1} \right]$$ is a trade-off parameter controlling the relative importance of cross-functional compatibility. The parameter $$\beta $$ enables systematic exploration of different conceptual design strategies. For $$\beta = 0$$ , the model reduces to purely requirement-driven selection, where each function is optimized independently with respect to its local requirements. For increasing values of $$\beta $$ , cross-functional compatibility progressively influences the solution, coupling the individual function selections into a global configuration problem. At $$\beta = 1$$ , local and systemic incompatibility are weighted equally under the chosen normalization.

Because both incompatibility measures are normalized to the interval $$\left[ {0,1} \right]$$ , the trade-off parameter directly governs the relative impact of subsystem integration versus local performance. This formulation therefore allows controlled investigation of architecture transitions as design priorities shift.

The following constraints ensure feasibility:

1. 1. Exactly one principle per function Equation (4):

   (4) $$\mathop \sum \limits_{p \in {P_f}} {x_{fp}} = 1{\rm{\;}}\forall f \in F.$$

1. 2. Linearization of pairwise interactions Equation (5):

   For all , $$p \in {P_f}$$ , $$q \in {P_g}$$ :

   (5)

   

The resulting model is a mixed-integer linear program (MILP). Due to cross-functional compatibility interactions, decisions become globally coupled, and the number of feasible configurations grows exponentially as $$\mathop \prod \nolimits_{f \in F} \left| {{P_f}} \right|$$ . The problem is therefore NP-hard and requires solver-based optimization for scalable application. The proposed linear binary formulation was selected because it enables (i) guarantees of global optimality, (ii) transparent decomposition of objective contributions into local and cross-functional components, and (iii) compatibility with mature and widely available MILP solvers.

3.2. Implementation

The MILP formulation described in Section 3.1 is implemented using a structured model-building procedure that translates the functional decomposition and incompatibility data into a solver-ready optimization problem. The implementation follows a clear sequence of steps: initialization of sets and parameters, declaration of binary decision variables, construction of constraints, definition of the objective function, and execution of the solver.

First, the sets of functions $$F$$ , candidate principles $${P_f}$$ , and local requirements $${T_f}$$ are defined. Local incompatibility values $${d_{fpt}}$$ , cross-functional incompatibilities $${D_{fp,gq}}$$ , and requirement weights $${w_{ft}}$$ are stored in structured data formats. These serve as direct inputs to the optimization model.

Binary variables $${x_{fp}}$$ are then introduced to represent the selection of a specific principle for a given function. Auxiliary binary variables $${y_{fp,gq}}$$ are defined to capture pairwise compatibility relationships between principles of different functions. A constraint enforcing exactly one selected principle per function is added, followed by linearization constraints that activate pairwise incompatibility contributions only when both associated principles are selected.

The overall implementation procedure is summarized in Figure 1.

Figure 1.

Pseudocode of MILP compatibility optimization

After assembling the model, the objective function is constructed as the weighted sum of local and cross-functional incompatibilities. The resulting MILP is solved using a standard optimization solver. The solution consists of one selected principle per function, together with the associated objective value and its decomposition into local and pairwise contributions.

Because the decision variables correspond directly to conceptual design choices, the output is fully interpretable: designers can identify which principles are selected, which incompatibility contributions dominate the objective, and how configuration decisions change when adjusting the trade-off parameter. This interpretability is essential for embedding the approach into early-stage conceptual design workflows.

3.3. Experimental setup

To evaluate the proposed compatibility-based configuration model, a simplified waffle maker system is used as a proof-of-concept case. The system consists of four functional blocks: Store_Electricity, Store_UserSettings, Store_Batter, and Guide_ElectricityToHeatingElement. For each function, two alternative solution principles are defined, resulting in a discrete configuration space of $${2^4} = 16$$ possible combinations. The candidate principles assigned to each function are summarized in Table 1.

Table 1.

Function—principle mapping

Each function is associated with two technical requirements that characterize the desired performance of the selected principle. These requirements represent simplified engineering targets such as capacity, insulation, or flexibility. For clarity and generality, all requirement importance weights are set to $${w_{ft}} = 1$$ , allowing the structural behaviour of the optimization model to be examined without additional weighting effects. The functional requirements considered in this study are listed in Table 2.

Table 2.

Functional requirements

For every function–principle–requirement combination, a normalized local incompatibility score $${d_{fpt}} \in \left[ {0,1} \right]$$ is defined. Lower values indicate better alignment with the corresponding requirement. These values quantify how well a candidate principle satisfies its associated functional targets.

For example, Battery performs moderately on capacity (0.32) but well on safety (0.15), whereas FlashMemory performs very well on retention (0.06) but less well on speed (0.51). The complete set of local incompatibility scores used in the experiment is presented in Table 3.

In addition to local requirement satisfaction, cross-functional compatibility between principles is explicitly modelled. For each valid pair of principles belonging to different functions, a normalized incompatibility value $${D_{fp,gq}} \in \left[ {0,1} \right]$$ is defined. These values represent potential integration conflicts such as thermal interaction, spatial interference, or system-level integration challenges. For instance, Battery and Tank exhibit strong incompatibility (0.90), while EEPROM and Container are fully compatible (0.00). The complete cross-functional incompatibility matrix is shown in Table 4.

Although the case study is intentionally small, it retains the essential combinatorial structure of conceptual configuration problems. Even with only four functions and two alternatives per function, the configuration space already contains 16 feasible combinations exhibiting competing trade-offs between local requirement satisfaction and cross-functional compatibility.

To analyse this trade-off systematically, the optimization model is evaluated for $$\beta \in \left\{ {0.0,0.1, \ldots ,1.0} \right\}.$$

For each value of $$\beta $$ , the globally optimal configuration and its decomposition into local and pairwise incompatibility contributions are recorded. This enables clear visualization of architecture transitions as compatibility importance increases.

Table 3.

Incompatibility scores

Table 4.

Cross-functional incompatibility