Literature review

AD theory was first proposed by Suh (Reference Suh2001), and during decades of development, it is now widespread in the design community. This theory can be applied in many circumstances and disciplines. Shortly after AD theory's establishment, it was introduced into the design practice of manufacturing facilities (Suh et al., Reference Suh, Cochran and Lima1998) and software systems (Suh and Do, Reference Suh and Do2000). Since then, a large number of researchers have been attracted to solve their design problems from multifarious domains with the help of AD theory. Cheng et al. (Reference Cheng, Feng, Lin, Liu and Tan2017) developed a novel heterogeneous AD method for the anti-vibration optimization of the key components in a turbo-generator. Rauch et al. (Reference Rauch, Vickery, Garcia, Rojas and Matt2018) established a software prototype for the smart shop-floor management based on the AD theory. Product and software design is only a part of AD theory's application, AD theory is also very useful for the design problems in industrial engineering. Chen et al. (Reference Chen, Goh and Zou2018) proposed an AD method of logistics provider selection for the omni-channel environment. Rauch et al. (Reference Rauch, Spena and Matt2019b) presented an AD method to support flexible and agile manufacturing and assembly systems for the small- and medium-sized enterprises. Additionally, AD theory's application is not limited in the engineering practice, it can also be used in social problem solving. Palleti et al. (Reference Palleti, Joseph and Silva2018) used the principles of AD theory to detect the vulnerabilities and corresponding potential attacks for critical infrastructures. Drakaki et al. (Reference Drakaki, Gören, Tzionas, Dargam, Delias, Linden and Mareschal2018) addressed the refugee settlement site planning decision-making process by constructing an intelligent multi-agent system with the help of AD theory. Recently, AD theory is also actively researched and applied within the “hot” topics like sustainability and Industry 4.0. Cochran et al. (Reference Cochran, Hendricks, Barnes and Bi2016) offered an extension of AD theory to ensure that leaders, managers, and engineers can sustain manufacturing systems throughout the product lifecycle. Gualtieri et al. (Reference Gualtieri, Rauch, Rojas, Vidoni and Matt2018) designed a collaborative human-robot workstation using AD theory for the new context of Industry 4.0. Rauch et al. (Reference Rauch, Morandell and Matt2019a) established a method to construct design guidelines for implementing Industry 4.0 learning factories using the mapping process of AD theory. Because of the limitation of the space, here just list some of the excellent works based on AD theory. More related works can be found in the review written by Rauch et al. (Reference Rauch, Matt and Dallasega2016).

These luxuriant works in multifarious domains reemphasize that AD theory is a successful conclusion of the general rules in the design activities, and they also illustrate that the possibility of obtaining well-performed design solutions can be largely promoted if the axioms are observed. However, AD theory still needs improvement from the comprehensive consideration of engineering factors and contexts. Suh (Reference Suh1995) took quality into consideration to make AD theory more complete. He et al. (Reference He, Niu, Hou and Li2018) introduced the consideration of sustainable and clean production into the construction of functional requirements. Chen et al. (Reference Chen, Li, Fan, Zhou and Zhang2016) reconfigured AD theory within a context of knowledge service, so that demanders and suppliers could be better matched. These considerations promote the suitability of AD theory for a wider practical application; however, they also demand AD theory to be assisted by more powerful methodologies and technologies. Deo and Suh (Reference Deo and Suh2004) introduced mathematical transforms into the AD theory to promote the ability of description and analysis. Thielman and Ge (Reference Thielman and Ge2006) proposed a systematic methodology to support AD theory in the evaluation and optimization of large-scale engineering systems. Li et al. (Reference Li, Song, Mao and Suh2019) used extenics to describe coupled solutions in the results of AD theory. These works promote AD theory's ability in description, analysis, and evaluation of design resources and solutions. However, the most important and innovative process of AD theory, the mapping from the functional domain to the physical domain, is still not accelerated efficiently. It is more and more difficult for this mapping to catch up with the increasingly comprehensive engineering considerations and the increasingly complicated description, analysis, and evaluation of design resources and solutions. To resolve this problem, researchers were attracted into the zigg-zagging between the functional domain and the physical domain, which consists of the functional requirement decomposition and the transformation from the functional requirements to the design parameters. Cochran et al. (Reference Cochran, Arinez, Duda and Linck2001) integrated Manufacturing System Design Decomposition (MSDD) and AD theory, so that the functional requirement decomposition can be completed by MSDD. In this way, the cost and production system design decisions become more effective (Cochran et al., Reference Cochran, Foley and Bi2017). Yuan et al. (Reference Yuan, Liu, Sun, Cao and Qamar2016) completed the functional requirement decomposition with a proposed hybrid approach implemented with Systems Modeling Language (SysML). Nagel et al. (Reference Nagel, Perry, Stone and McAdams2009) established a functional modeling tool called FunctionCAD for the interactive functional requirement decomposition. Chakrabarti and Bligh (Reference Chakrabarti and Bligh2001) supported the functional requirement decomposition by using the recursive problem redefinition. These works largely contribute to the functional requirement decomposition, but, as for the transformation from the functional requirements to the design parameters, it still needs more focuses.

The transformation from the functional requirements to the design parameters is tightly related to the conceptual design synthesis in other design methodologies; therefore, its acceleration can be inspired by the efforts of design synthesis automation. Vermaas and Dorst (Reference Vermaas and Dorst2007) used a philosophic method to improve the model proposed by Gero for the design synthesis. Camelo and Mulet (Reference Camelo and Mulet2010) developed a multirelational and interactive model to support the design synthesis process. Welch and Dixon (Reference Welch and Dixon1994) developed a model for conceptual design synthesis based on an explicit behavioral reasoning step. These efforts largely promote the elaboration and practicability of the conceptual design model, which means a solid foundation for the design synthesis automation. On the other hand, a well-formed representation for the elements and factors of the design process, like functional requirements, design resources, and design solutions, is also important for the design synthesis automation. Joskowicz and Neville (Reference Joskowicz and Neville1996) presented a language to describe the behavior of fixed-axes mechanisms for the design synthesis of mechanisms. Stone and Wood (Reference Stone and Wood2000) ; and Stone et al. (Reference Stone, Wood and Crawford2000) ; proposed a new design modeling language using function-flow to characterize the product function. Chen and Xie (Reference Chen and Xie2017a, Reference Chen and Xie2017b) developed the function-flow into an input–output model to represent the function and support the automation of design synthesis. Hirtz et al. (Reference Hirtz, Stone, Mcadams, Szykman and Wood2002) proposed a functional chain representation using the terminology of the functional basis for engineering design synthesis. These efforts focus on the representation of the functional requirements and design resources, if they can be considered together comprehensively, the relationships of the design resources can also be well described. As for the design solutions, some researchers introduced the graph model for help. Münzer et al. (Reference Münzer, Helms and Shea2013) proposed an object-oriented and graph-based representation for computational design synthesis. Helms and Shea (Reference Helms and Shea2012) described the computational design synthesis process with an object-oriented graph grammar. Muenzer and Shea (Reference Muenzer and Shea2015) proposed a simulation model based on a generated concept model graph. All these efforts, like the input–output and chain-structured models for the functional requirements, the graph-based model for the design solutions, can be introduced into the traditional AD theory to make a foundation for the construction of a computer-aided approach, which can automate the transformation from the functional requirements to the design parameters. Furthermore, the rich design resources offered by the outside providers should also be seriously considered, while they are usually not be paid enough attention to in the former researches about AD theory.

Classification of the design parameters

To achieve the automation of the mapping from the functional domain to the physical domain, the core mission of this study is to construct a computer-aided approach including a methodology and its corresponding algorithm, which can be executed by computers. Therefore, the main objectives, including design resources and design parameters, should be modeled as elements and their divisible attachments and constructible combinations, so that the mapping can be transformed into an executable process for a computer. Based on this idea, different design parameters may have different constructive granularities. Therefore, a classification is established in this study to distinguish the design parameters’ constructive granularities, so that the design parameters can be treated respectively for the establishment of a systematical and completely-covering methodology and its corresponding algorithm.

Before the introduction of this classification, a simple design case completed by the traditional AD theory is illustrated step by step firstly to show the background.

Design case completed by the traditional AD theory

Here take a case simplified from the elevator design proposed by Xiao and Cheng (Reference Xiao and Cheng2006) as an example. As shown in Figure 1, the zigg-zagging in the middle of the figure completes the mapping from the functional domain to the physical domain. The details of the functional requirements and their corresponding design parameters are shown in Table 1. Their relationships are shown as the following design equations with design matrices.

(1)$$\left[ {\matrix{ {{\rm FR}1} \cr {{\rm FR}2} \cr {{\rm FR}3} \cr}} \right] = \left[ {\matrix{ X & 0 & 0 \cr X & X & 0 \cr X & X & X \cr}} \right]\left[ {\matrix{ {{\rm DP}1} \cr {{\rm DP}2} \cr {{\rm DP}3} \cr}} \right], $$

(2)$$\left[ {\matrix{ {{\rm FR}11} \cr {{\rm FR}12} \cr {{\rm FR}13} \cr {{\rm FR}14} \cr}} \right] = \left[ {\matrix{ {\matrix{ X & 0 \cr 0 & X \cr}} & {\matrix{ 0 & 0 \cr 0 & 0 \cr}} \cr {\matrix{ 0 & X \cr 0 & X \cr}} & {\matrix{ X & 0 \cr X & X \cr}} \cr}} \right]\left[ {\matrix{ {{\rm DP}11} \cr {{\rm DP}12} \cr {{\rm DP}13} \cr {{\rm DP}14} \cr}} \right], $$

(3)$$\left[ {\matrix{ {{\rm FR}21} \cr {{\rm FR}22} \cr {{\rm FR}23} \cr {{\rm FR}24} \cr}} \right] = \left[ {\matrix{ {\matrix{ X & 0 \cr X & X \cr}} & {\matrix{ 0 & 0 \cr 0 & 0 \cr}} \cr {\matrix{ X & 0 \cr 0 & X \cr}} & {\matrix{ X & 0 \cr 0 & X \cr}} \cr}} \right]\left[ {\matrix{ {{\rm DP}21} \cr {{\rm DP}22} \cr {{\rm DP}23} \cr {{\rm DP}24} \cr}} \right], $$

(4)$${\rm FR}121 = \lsqb X \rsqb {\rm DP}121, $$

(5)$$\left[ {\matrix{ {{\rm FR}141} \cr {{\rm FR}142} \cr {{\rm FR}143} \cr}} \right] = \left[ {\matrix{ X & 0 & 0 \cr X & X & 0 \cr X & 0 & X \cr}} \right]\left[ {\matrix{ {{\rm DP}141} \cr {{\rm DP}142} \cr {{\rm DP}143} \cr}} \right]. $$

Fig. 1. Zigg-zagging between the functional domain and the physical domain.

Table 1. Functional requirements and their corresponding design parameters

Three kinds of design parameters

The above design case shows a situation that although the physical domain consists of design parameters, these design parameters are not always the same kind of things, they may have different essences with different constructive granularities. For example, in the above case, DP14 is “Coiling block”. It is a design resource as one of the components of the final design solution. Meanwhile, DP143 is “Thickness of coiling block” which is not a design resource like DP14. Actually, it is one of DP14's features. Additionally, DP1 is different with both these two design parameters, it is actually a combination of several design resources, including “Sling”, “Block and tackle”, “Rope”, and “Coiling block”. Therefore, the design parameters can be classified into three kinds, that is, design resources (DRs), design resource features (DR Features), and design resource combinations (DR Combinations).

Design resource

Design resource is the key concept in this classification of the design parameters. Design resources are functional entities, which are the basic elements of the design solution and the raw materials for the design missions. As shown in Figure 2, a design resource is represented by its name, inputs, outputs, and features.

Fig. 2. Design resource and its detailed information.

For a design resource, the transformation from its inputs to its outputs is defined as its function. Like the case shown in Figure 2, the design resource is a crank slider, and its function is to transform rotary motion into reciprocating motion. A design resource may have multiple inputs and outputs, and they can be described as vectors. Here assume a design resource, DR2, has m inputs, that is, $\Phi _{{\rm DR}2}^{{\rm I}\lpar 1 \rpar }\comma \, \Phi _{{\rm DR}2}^{{\rm I}\lpar 2 \rpar }\comma \, \ldots\comma \, \Phi _{{\rm DR}2}^{{\rm I}\lpar m \rpar }$, and n outputs, that is, $\Phi _{{\rm DR}2}^{{\rm O}\lpar {\rm 1} \rpar }\comma \, \Phi _{{\rm DR}2}^{{\rm O}\lpar 2 \rpar }\comma \, \ldots\comma \, \Phi _{{\rm DR}2}^{{\rm O}\lpar n \rpar }$. (In this study, the letter “Φ” is treated as the combination of the letters “I” and “O”, which represents an input/output.) These inputs and outputs can be represented by the following input vector and output vector, respectively.

(6)$$\overrightarrow {\Phi _{{\rm DR}2}^{\rm I}} = \lsqb {\Phi_{{\rm DR}2}^{{\rm I}\lpar 1 \rpar }\comma \, \Phi_{{\rm DR}2}^{{\rm I}\lpar 2 \rpar }\comma \, \ldots\comma \, \Phi_{{\rm DR}2}^{{\rm I}\lpar m \rpar }} \rsqb ^T, $$

(7)$$\overrightarrow {\Phi _{{\rm DR}2}^{\rm O}} = \lsqb {\Phi_{{\rm DR}2}^{{\rm O}\lpar 1 \rpar }\comma \, \Phi_{{\rm DR}2}^{{\rm O}\lpar 2 \rpar }\comma \, \ldots\comma \, \Phi_{{\rm DR}2}^{{\rm O}\lpar n \rpar }} \rsqb ^T. $$

Thus, DR2's function, the transformation from DR2's inputs to DR2's outputs, can be represented as the following Jacobian matrix:

(8)$${\rm J}_{{\rm DR}2} = \displaystyle{{{\rm \partial} \overrightarrow {\Phi _{{\rm DR}2}^{\rm O}}} \over {{\rm \partial} \overrightarrow {\Phi _{{\rm DR}2}^{\rm I}}}} = \left[ {\matrix{ {\matrix{ {\displaystyle{{{\rm \partial} \Phi_{{\rm DR}2}^{{\rm O}\lpar 1 \rpar }} \over {{\rm \partial} \Phi_{{\rm DR}2}^{{\rm I}\lpar 1 \rpar }}}} & {\displaystyle{{{\rm \partial} \Phi_{{\rm DR}2}^{{\rm O}\lpar 1 \rpar }} \over {{\rm \partial} \Phi_{{\rm DR}2}^{{\rm I}\lpar 2 \rpar }}}} \cr {\displaystyle{{{\rm \partial} \Phi_{{\rm DR}2}^{{\rm O}\lpar 2 \rpar }} \over {{\rm \partial} \Phi_{{\rm DR}2}^{{\rm I}\lpar 1 \rpar }}}} & {\displaystyle{{{\rm \partial} \Phi_{{\rm DR}2}^{{\rm O}\lpar 2 \rpar }} \over {{\rm \partial} \Phi_{{\rm DR}2}^{{\rm I}\lpar 2 \rpar }}}} \cr}} & {\matrix{ \cdots & {\displaystyle{{{\rm \partial} \Phi_{{\rm DR}2}^{{\rm O}\lpar 1 \rpar }} \over {{\rm \partial} \Phi_{{\rm DR}2}^{{\rm I}\lpar m \rpar }}}} \cr \cdots & {\displaystyle{{{\rm \partial} \Phi_{{\rm DR}2}^{{\rm O}\lpar 2 \rpar }} \over {{\rm \partial} \Phi_{{\rm DR}2}^{{\rm I}\lpar m \rpar }}}} \cr}} \cr {\matrix{ \vdots & \vdots \cr {\displaystyle{{{\rm \partial} \Phi_{{\rm DR}2}^{{\rm O}\lpar n \rpar }} \over {{\rm \partial} \Phi_{{\rm DR}2}^{{\rm I}\lpar 1 \rpar }}}} & {\displaystyle{{{\rm \partial} \Phi_{{\rm DR}2}^{{\rm O}\lpar n \rpar }} \over {{\rm \partial} \Phi_{{\rm DR}2}^{{\rm I}\lpar 2 \rpar }}}} \cr}} & {\matrix{ \ddots & \vdots \cr \cdots & {\displaystyle{{{\rm \partial} \Phi_{{\rm DR}2}^{{\rm O}\lpar n \rpar }} \over {{\rm \partial} \Phi_{{\rm DR}2}^{{\rm I}\lpar m \rpar }}}} \cr}} \cr}} \right]. $$

If the integral starting point is set as 0, the effect of DR2's function can be described as the following mathematical equation:

(9)$$\overrightarrow {\Phi _{{\rm DR}2}^{\rm O}} = {\rm J}_{{\rm DR}2}\overrightarrow {\Phi _{{\rm DR}2}^{\rm I}}\,. $$

Design resource feature

Sometimes, just a design resource feature can achieve a functional requirement, like DP143, “Thickness of coiling block”, to FR143, “Bear the wrapping hoop force of the rope”, shown in Figure 1 and Table 1. A design resource feature may be a design resource's own feature, and it may also be a design resource's input or output's feature, like DP121, “Multiplying power of the block and tackle”, shown in Figure 1 and Table 1. Design resource features are attachments of design resources, so that if the design resources have already been figured out for the design solution, the design resource features could directly be determined with the limited amount of workload naturally. So, in this study, the main point is establishing a way to find out the appropriate design resources and combine them into a design resource combination which can achieve the functional requirements. As for the design resource features and their corresponding functional requirements, they are not concerned much here.

Design resource combination

A design resource combination is constructed by its component design resources connecting with each other. Here, the connection among design resources is established based on the match between two inputs/outputs. Take Φ1 and Φ2 as an example, only if the following three conditions are met simultaneously, can it be determined that Φ1 matches Φ2 as the following equation:

(10)$$\Phi 1\mathop \to \limits^{{\rm Match}} \Phi 2.$$

Condition 1: Φ1 and Φ2 have the same name.

Condition 2: Φ1's features conclude all Φ2's features.

Condition 3: For every common feature, Φ1's features have the same name and unit as Φ2's features, and the value range of Φ1's feature is contained by the value range of Φ2's feature.

Based on the above definition, design resources can be connected together into a design resource combination. Figure 3 shows an example of the design resource combination consisting of six component design resources, that is, DR1, DR2, DR3, DR4, DR5, and DR6. The matches among their inputs and outputs are shown as the following equations:

(11)$$\Phi _{{\rm DR}1}^{{\rm O}\lpar 2 \rpar } \mathop \to \limits^{{\rm Match}} \Phi _{{\rm DR}3}^{{\rm I}\lpar 1 \rpar }, $$

(12)$$\Phi _{{\rm DR}2}^{{\rm O}\lpar 1 \rpar } \mathop \to \limits^{{\rm Match}} \Phi _{{\rm DR}3}^{{\rm I}\lpar 2 \rpar }, $$

(13)$$\Phi _{{\rm DR}1}^{{\rm O}\lpar 3 \rpar } \mathop \to \limits^{{\rm Match}} \Phi _{{\rm DR}3}^{{\rm I}\lpar 3 \rpar }, $$

(14)$$\Phi _{{\rm DR}2}^{{\rm O}\lpar 1 \rpar } \mathop \to \limits^{{\rm Match}} \Phi _{{\rm DR}4}^{{\rm I}\lpar 1 \rpar }, $$

(15)$$\Phi _{{\rm DR}1}^{{\rm O}\lpar 3 \rpar } \mathop \to \limits^{{\rm Match}} \Phi _{{\rm DR}4}^{{\rm I}\lpar 2 \rpar }, $$

(16)$$\Phi _{{\rm DR}4}^{{\rm O}\lpar 1 \rpar } \mathop \to \limits^{{\rm Match}} \Phi _{{\rm DR}5}^{{\rm I}\lpar 1 \rpar }, $$

(17)$$\Phi _{{\rm DR}3}^{{\rm O}\lpar 1 \rpar } \mathop \to \limits^{{\rm Match}} \Phi _{{\rm DR}5}^{{\rm I}\lpar 2 \rpar }, $$

(18)$$\Phi _{{\rm DR}5}^{{\rm O}\lpar 3 \rpar } \mathop \to \limits^{{\rm Match}} \Phi _{{\rm DR}6}^{{\rm I}\lpar 1 \rpar }, $$

(19)$$\Phi _{{\rm DR}5}^{{\rm O}\lpar 1 \rpar } \mathop \to \limits^{{\rm Match}} \Phi _{{\rm DR}6}^{{\rm I}\lpar 2 \rpar }. $$

Fig. 3. Design resource combination consisting of 6 DRs.

As mentioned before, a design resource's inputs and outputs can also be described as an input vector and an output vector. With this description, the connections among the design resources can also be represented as transfer matrices.

Here should first introduce the match between two input/output vectors. For two input/output vectors, $\overrightarrow {\Phi _{{\rm DR}x}^{\rm O}}$ and $\overrightarrow {\Phi _{{\rm DR}y}^{\rm I}}$, only if the following two conditions are met simultaneously, can it be determined that $\overrightarrow {\Phi _{{\rm DR}x}^{\rm O}}$ matches $\overrightarrow {\Phi _{{\rm DR}y}^{\rm I}}$ as the following equation:

(20)$$\overrightarrow {\Phi _{{\rm DR}x}^{\rm O}} \mathop \to \limits^{{\rm Match}} \overrightarrow {\Phi _{{\rm DR}y}^{\rm I}}. $$

Condition 1: $\overrightarrow {\Phi _{{\rm DR}x}^{\rm O}}$ and $\overrightarrow {\Phi _{{\rm DR}y}^{\rm I}}$ have the same number of vector elements.

Condition 2: The vector elements of $\overrightarrow {\Phi _{{\rm DR}x}^{\rm O}}$ match the vector elements of $\overrightarrow {\Phi _{{\rm DR}y}^{\rm I}}$ one by one in order.

Now, go back to the connection among DR1, DR2, and DR3 shown in Equations (11)–(13). With the definition of the input/output vector match, it can also be represented by one equation in the matrix form as follows:

(21)$$\left[ {\matrix{ {\matrix{ {\matrix{ 0 & 1 \cr}} & {\matrix{ 0 & 0 \cr}} \cr}} \cr {\matrix{ {\matrix{ 0 & 0 \cr}} & {\matrix{ 0 & 1 \cr}} \cr}} \cr {\matrix{ {\matrix{ 0 & 0 \cr}} & {\matrix{ 1 & 0 \cr}} \cr}} \cr}} \right]\left[ {\matrix{ {\Phi_{{\rm DR}1}^{{\rm O}\lpar 1 \rpar }} \cr {\Phi_{{\rm DR}1}^{{\rm O}\lpar 2 \rpar }} \cr {\Phi_{{\rm DR}1}^{{\rm O}\lpar 3 \rpar }} \cr {\Phi_{{\rm DR}2}^{{\rm O}\lpar 1 \rpar }} \cr}} \right]\mathop \to \limits^{{\rm Match}} \left[ {\matrix{ {\Phi_{{\rm DR}3}^{{\rm I}\lpar 1 \rpar }} \cr {\Phi_{{\rm DR}3}^{{\rm I}\lpar 2 \rpar }} \cr {\Phi_{{\rm DR}3}^{{\rm I}\lpar 3 \rpar }} \cr}} \right].$$

Use the vector and matrix notation, this above equation can be simplified as follows:

(22)$${\rm C}_{{\rm DR}1\comma \,{\rm DR}2}^{{\rm DR}3} \left[ {\matrix{ {\overrightarrow {\Phi_{{\rm DR}1}^{\rm O}}} \cr {\overrightarrow {\Phi_{{\rm DR}2}^{\rm O}}} \cr}} \right]\mathop \to \limits^{{\rm Match}} \overrightarrow {\Phi _{{\rm DR}3}^{\rm I}}. $$

Here, $${\rm C}_{{\rm DR}1\comma \,{\rm DR}2}^{{\rm DR}3}$ represents the transfer matrix of the connection from DR1 and DR2 to DR3. Based on this description, the other design resource connections can be represented as follows:

(23)$${\rm C}_{{\rm DR}1\comma \,{\rm DR}2}^{{\rm DR}4} \left[ {\matrix{ {\overrightarrow {\Phi_{{\rm DR}1}^{\rm O}}} \cr {\overrightarrow {\Phi_{{\rm DR}2}^{\rm O}}} \cr}} \right]\mathop \to \limits^{{\rm Match}} \overrightarrow {\Phi _{{\rm DR}4}^{\rm I}}\comma \, {\rm \; \;} {\rm C}_{{\rm DR}1\comma \,{\rm DR}2}^{{\rm DR}4} = \left[ {\matrix{ {\matrix{ {\matrix{ 0 & 0 \cr}} & {\matrix{ 0 & 1 \cr}} \cr}} \cr {\matrix{ {\matrix{ 0 & 0 \cr}} & {\matrix{ 1 & 0 \cr}} \cr}} \cr}} \right], $$

(24)$${\rm C}_{{\rm DR}3\comma \,{\rm DR}4}^{{\rm DR}5} \left[ {\matrix{ {\overrightarrow {\Phi_{{\rm DR}3}^{\rm O}}} \cr {\overrightarrow {\Phi_{{\rm DR}4}^{\rm O}}} \cr}} \right]\mathop \to \limits^{{\rm Match}} \overrightarrow {\Phi _{{\rm DR}5}^{\rm I}}\comma \, \; \; {\rm C}_{{\rm DR}3\comma \,{\rm DR}4}^{{\rm DR}5} = \left[ {\matrix{ 0 & 1 \cr 1 & 0 \cr}} \right], $$

(25)$${\rm C}_{{\rm DR}5}^{{\rm DR}6} \overrightarrow {\Phi _{{\rm DR}5}^{\rm I}} \mathop \to \limits^{{\rm Match}} \overrightarrow {\Phi _{{\rm DR}6}^{\rm I}}\comma \, \; \; {\rm C}_{{\rm DR}5}^{{\rm DR}6} = \left[ {\matrix{ 0 & 0 & 1 \cr 1 & 0 & 0 \cr}} \right].$$

As the design resources in the design resource combination connect with each other, the design resource combination itself also connect with the functional requirement. This connection can also be described by the matches among the inputs and outputs of the design resource combination and the functional requirement. Here define the inputs of the upstream design resources as the inputs of the whole design resource combination, and the outputs of the downstream design resources as the outputs of the whole design resource combination. The situation in this case is shown as the following equations:

(26)$$\Phi _{{\rm DRC}1}^{{\rm I}\lpar 1 \rpar } = \Phi _{{\rm DR}1}^{{\rm I}\lpar 1 \rpar }, $$

(27)$$\Phi _{{\rm DRC}1}^{{\rm I}\lpar 2 \rpar } = \Phi _{{\rm DR}1}^{{\rm I}\lpar 2 \rpar }, $$

(28)$$\Phi _{{\rm DRC}1}^{{\rm I}\lpar 3 \rpar } = \Phi _{{\rm DR}2}^{{\rm I}\lpar 1 \rpar }, $$

(29)$$\Phi _{{\rm DRC}1}^{{\rm I}\lpar 4 \rpar } = \Phi _{{\rm DR}2}^{{\rm I}\lpar 2 \rpar }, $$

(30)$$\Phi _{{\rm DRC}1}^{{\rm O}\lpar 1 \rpar } = \Phi _{{\rm DR}6}^{{\rm O}\lpar 1 \rpar }, $$

(31)$$\Phi _{{\rm DRC}1}^{{\rm O}\lpar 2 \rpar } = \Phi _{{\rm DR}6}^{{\rm O}\lpar 2 \rpar }, $$

(32)$$\Phi _{{\rm DRC}1}^{{\rm O}\lpar 3 \rpar } = \Phi _{{\rm DR}6}^{{\rm O}\lpar 3 \rpar }. $$

Therefore, the connection between the functional resource combination and the functional requirement shown in Figure 3 can be described as the following input/output matches:

(33)$$\Phi _{{\rm FR}1}^{{\rm I}\lpar 4 \rpar } \mathop \to \limits^{{\rm Match}} \Phi _{{\rm DRC}1}^{{\rm I}\lpar 1 \rpar }, $$

(34)$$\Phi _{{\rm FR}1}^{{\rm I}\lpar 2 \rpar } \mathop \to \limits^{{\rm Match}} \Phi _{{\rm DRC}1}^{{\rm I}\lpar 2 \rpar }, $$

(35)$$\Phi _{{\rm FR}1}^{{\rm I}\lpar 1 \rpar } \mathop \to \limits^{{\rm Match}} \Phi _{{\rm DRC}1}^{{\rm I}\lpar 3 \rpar }, $$

(36)$$\Phi _{{\rm FR}1}^{{\rm I}\lpar 3 \rpar } \mathop \to \limits^{{\rm Match}} \Phi _{{\rm DRC}1}^{{\rm I}\lpar 4 \rpar }, $$

(37)$$\Phi _{{\rm DRC}1}^{{\rm O}\lpar 2 \rpar } \mathop \to \limits^{{\rm Match}} \Phi _{{\rm FR}1}^{{\rm O}\lpar 1 \rpar }, $$

(38)$$\Phi _{{\rm DRC}1}^{{\rm O}\lpar 3 \rpar } \mathop \to \limits^{{\rm Match}} \Phi _{{\rm FR}1}^{{\rm O}\lpar 2 \rpar }. $$

Use the vector and matrix representation, the above equations, Equations (26)–(38), can be concluded as the following two equations:

(39)$${\rm C}_{{\rm FR}1}^{{\rm DRC}1} \overrightarrow {\Phi _{{\rm FR}1}^{\rm I}} \mathop \to \limits^{{\rm Match}} \overrightarrow {\Phi _{{\rm DRC}1}^{\rm I}} = \left[ {\matrix{ {\overrightarrow {\Phi_{{\rm DR}1}^{\rm I}}} \cr {\overrightarrow {\Phi_{{\rm DR}2}^{\rm I}}} \cr}} \right]\comma \,{\rm \; \; C}_{{\rm FR}1}^{{\rm DRC}1} = \left[ {\matrix{ {\matrix{ {\matrix{ 0 & 0 \cr}} & {\matrix{ 0 & 1 \cr}} \cr}} \cr {\matrix{ {\matrix{ 0 & 1 \cr}} & {\matrix{ 0 & 0 \cr}} \cr}} \cr {\matrix{ {\matrix{ 1 & 0 \cr}} & {\matrix{ 0 & 0 \cr}} \cr}} \cr {\matrix{ {\matrix{ 0 & 0 \cr}} & {\matrix{ 1 & 0 \cr}} \cr}} \cr}} \right], $$

(40)$${\rm C}_{{\rm DRC}1}^{{\rm FR}1} \overrightarrow {\Phi _{{\rm DRC}1}^{\rm O}} = {\rm C}_{{\rm DRC}1}^{{\rm FR}1} \overrightarrow {\Phi _{{\rm DR}6}^{\rm O}} \mathop \to \limits^{{\rm Match}} \overrightarrow {\Phi _{{\rm FR}1}^{\rm O}}\comma \, {\rm \; \; C}_{{\rm DRC}1}^{{\rm FR}1} = \left[ {\matrix{ {\matrix{ 0 & 1 & 0 \cr}} \cr {\matrix{ 0 & 0 & 1 \cr}} \cr}} \right]. $$

Introducing the distributed design resource environment

As mentioned before, this study is mainly focused on the design resource searching and design resource combination constructing, as for the design resource features and their corresponding functional requirements, they are not concerned much here. To achieve this main goal, a computer-aided approach is proposed for the mapping from the functional domain to the physical domain. This approach takes the rich design resources outside the designers’ access into consideration and also includes a computer algorithm to help complete the mechanical and repetitive works of design resource searching and design resource combination exhausting. This approach can improve AD theory's support for the designers, and alleviate the contradiction between the designers’ increasingly innovative design conception and the limitation of their access to the rich design resources and the powerful computing capacity.

This proposed approach obtains access to the outside design resources via the advanced Internet. The design resources can be published on the Internet by their providers distributed in different locations, institutes, and disciplines. These design resources on the Internet actually construct a distributed design resource environment, and the proposed approach plays the role of a bridge connecting this environment and the designers. To achieve this, the distributed design resource environment is firstly modeled as a design resource graph, so that its design resources can be searched and combined by a computer algorithm based on the functional requirement.

Design resource graph

Design resource graph is a data model of the distributed design resource environment. It records the design resources and their connections as shown in Figure 4. However, the connections in the design resource graph are not necessarily complete. In this design resource graph, the connection from DR43 to DR44 is incomplete because the third input of DR44 is not matched by any output of DR43. This flexible and slack constructive configuration of design resource graph is suitable for the two-step construction of a design resource combination. In the first step, a chain of design resources is searched out from the design resource graph with a computer algorithm which is proposed in the Design resource chain generating algorithm section. This chain is completely connected with the functional requirement via its starting design resource as the upstream design resource and the ending design resource as the downstream design resource. Meanwhile, the connections among its component design resources are not necessarily complete, so that there is the possibility of adding assistant design resources into this chain and improving it into a non-chain-shaped design resource combination in the second step. Therefore, the structures of constructed design resource combinations are not limited as chains, which flourishes the diversity of the construction's results.

Fig. 4. Design resource graph and the incomplete design resource connection.

Assume the chain signed in Figure 4, that is, DR1→DR5→DR8→DR12→DR13→DR17, is obtained in the first step, and its detailed input/output matching situation is shown in Figure 5. In this chain, there are three unmatched design resource inputs, that is, the first input of DR5, the first input of DR8, and the second input of DR17. This design resource chain cannot achieve the functional requirement unless these inputs are all matched. Therefore, six assistant design resources are found out from the design resource graph, and added into the design resource chain, so that the three inputs are matched, and the final non-chain-shaped design resource combination is formed.

Fig. 5. Constructing the final design resource combination by adding assistant design resources into the design resource chain.

Design resource chain generating algorithm

As mentioned in the Design resource graph section, a computer algorithm is proposed in this study to generate design resource chains from the design resource graph. These chains’ starting and ending design resources should completely connect with the functional requirement, which means only some of the design resources in the design resource graph can play the role of the starting and ending design resources. Therefore, the following two criteria are proposed to determine whether a design resource can serve as the starting or ending design resource of the generated design resource chain (DR Chain).

DR Chain Criterion 1

For a design resource, if all its inputs can be matched by the inputs of the functional requirement, it can be determined as a starting design resource of the generated design resource chain.

DR Chain Criterion 2

For a design resource, if all the functional requirement's outputs can be matched by its outputs, it can be determined as an ending design resource of the generated design resource chain.

During the design resource chain generating algorithm, all the starting and ending design resources should be found out first, and then, the next work is about figuring out design-resource-formed paths bridging any pair of starting and ending design resources. This process can be described as the following steps:

Step 1. In the beginning, the generated design resource chain is empty. Add one of the starting design resources into the generated design resource chain as the 1st design resource.

Step 2. Find out all the successors of the 1st design resource, and add one of them into the generated design resource chain as the 2nd design resource.

Step 3. Keep on finding the successors of the generated design resource chain's last design resource, so that the chain keeps growing longer.

Step 4. Interrupt the design resource chain's growth when one of the following three situations occurs.

1. (1) The length of the generated design resource chain exceeds the limitation which is set to avoid overlong design resource chains.

2. (2) The generated design resource chain's last design resource has no successor.

3. (3) The generated design resource chain's last design resource is an ending design resource.

Among these three situations, only the last one indicates that a proper design resource chain is found successfully. So, the generated design resource chain should be outputted as a result.

Step 5. After the interrupt mentioned in Step 4, the generated design resource chain's last design resource should be removed. If the generated design resource chain's new last design resource has another successor, keep lengthen the chain toward another direction, and if not, this new last design resource should also be removed.

Step 6. Keep on doing Step 3–5, so that the generated design resource chain could be lengthened and shortened in turn, and finally, it becomes empty again.

Step 7. If there are still other starting design resources in the design resource graph, add one of them into the generated design resource chain as the 1st design resource and repeat Step 2–6.

Step 8. Keep on doing Step 7, until there is no other starting design resource rest.

These algorithm steps are concluded into a flow diagram shown in Figure 6.

Fig. 6. Flow diagram of the design resource chain generating algorithm.

To illustrate the above algorithm in detailed case, here take the design resource graph shown in Figure 4 as an example. Assume that DR1 and DR3 are the starting design resources, and DR17 is the ending design resource. Set the limitation of the generated design resource chain's length as 6 DRs. The operating steps of the algorithm and the corresponding changes of the generated design resource chain are shown in Table 2, and the operating steps are also shown in Figure 7 for a visual representation.

Fig. 7. Illustration of the operating steps of the design resource chain generating algorithm.

Table 2. Operating steps of the design resource chain generating algorithm and the corresponding changes of the generated design resource chain

The design resource graph is shown in Figure 4. DR1 and DR3 are the starting design resources, and DR17 is the ending design resource. The limitation of the generated design resource chain's length is 6 DRs.

Mapping from the functional domain to the physical domain

With the above proposed design parameter classification, design resource graph, design resource chain generating algorithm, and design resource combination construction, a systematical transformation from the functional requirements to the design parameters is formed within the distributed design resource environment as shown in Figure 8.

Fig. 8. Systematical transformation from the functional requirements to the design parameters.

As shown in Figure 8, for a functional requirement, there are three possibilities for the process of finding its proper design parameter. Firstly, current design parameters (design resource combinations or design resources) can be analyzed, if there is any design resource feature can achieve this functional requirement, this design resource feature is the proper design parameter. If there is no proper design resource feature found, the design resource chain generating algorithm should be executed by the computer within the design resource graph, so that the design resource or design resource combination can be generated to achieve the functional requirement. At this time, this design resource or design resource combination is the proper design parameter. But, if there is still no proper design resource or design resource combination found, the zigg-zagging should be kept on, which means this functional requirement should be decomposed just as mentioned in the traditional AD theory. The whole process now can be concluded as a computer-aided approach for the mapping from the functional domain to the physical domain as shown in Figure 9.

Fig. 9. Computer-aided approach for the mapping from the functional domain to the physical domain.

During the zigg-zagging, the design equations in all the levels should be written down, and the design matrices should be checked with the independence axiom, so that the coupled relationship between functional requirements and design parameters can be avoided. Here, in this case, if this mapping meets the independence axiom, its design equations should be as follows:

(41)$${\rm Level}\,1{\rm :} \; {\rm FR} = \lsqb X \rsqb {\rm DP}, $$

(42)$${\rm Level}\,2{\rm :} \; \left[ {\matrix{ {{\rm FR}1} \cr {{\rm FR}2} \cr}} \right] = \left[ {\matrix{ X & 0 \cr 0 & X \cr}} \right]\left[ {\matrix{ {{\rm DP}1} \cr {{\rm DP}2} \cr}} \right], $$

(43)$${\rm Level}\,3{\rm :} \; \left[ {\matrix{ {{\rm FR}11} \cr {{\rm FR}12} \cr}} \right] = \left[ {\matrix{ X & 0 \cr 0 & X \cr}} \right]\left[ {\matrix{ {{\rm DP}11} \cr {{\rm DP}12} \cr}} \right]\comma \, \; \; {\rm FR}21 = \lsqb X \rsqb {\rm DP}21, $$

(44)$${\rm Level}\,4{\rm :} \; \left[ {\matrix{ {{\rm FR}111} \cr {{\rm FR}112} \cr}} \right] = \left[ {\matrix{ X & 0 \cr 0 & X \cr}} \right]\left[ {\matrix{ {{\rm DP}111} \cr {{\rm DP}112} \cr}} \right]\comma \, \; \; \left[ {\matrix{ {{\rm FR}121} \cr {{\rm FR}122} \cr}} \right] = \left[ {\matrix{ X & 0 \cr 0 & X \cr}} \right]\left[ {\matrix{ {{\rm DP}121} \cr {{\rm DP}122} \cr}} \right]. $$

Now, this mapping is a feasible mapping. Additionally, if there is more than one mapping obtained, the alternatives should be tested by the information axiom, so that the optimal one can be picked out.

Implementation

To prove the feasibility of this proposed computer-aided approach, a software prototype called the ADS-DDRE is established. ADS-DDRE's root database is set on several central servers, and its client part can be configured on personal computers. Design resource providers distributed in different locations, institutes, and disciplines can publish their design resources on the Internet by the client part, and the design resources’ data is stored in the root database as a design resource graph. Designers can visit the root database through the client part, and complete the data processing work, including design resource searching, design resource chain generating, and design resource combination constructing, within the design resource graph by the proposed design resource chain generating algorithm. Next, a natural leisure hotel is designed by ADS-DDRE as an example.

This natural leisure hotel is aimed to take full advantages of the natural resources, like the sunlight, the river flow, the daily garbage, the maize straw, and the organic food, to supply natural leisure services for the customers. This functional requirement can be expressed as FR0 shown in Table 3.

Table 3. Detailed information of FR0

After figure out the functional requirement, FR0, the designers should start ADS-DDRE's client part and input FR0 as shown in Figure 10. Then, the features of FR0's inputs and output should be edited as shown in Figure 11. Click the “Next” button to start searching for FR0's design parameter. However, no proper design resource or design resource combination is found, as shown in Figure 12.

Fig. 10. Inputting FR0 into ADS-DDRE.

Fig. 11. Editing the features of FR0's inputs and outputs.

Fig. 12. No proper design parameter is found for FR0.

Therefore, concretize “natural leisure services” into “natural residence” and “natural diet”, so that FR0 can be decomposed into FR01 and FR02 as shown in Table 4.

Table 4. Detailed information of FR01 and FR02

Now, input FR01 and FR02 into ADS-DDRE and try to find their design parameters. However, there is still no result. So, the zigg-zagging should go on, FR01 and FR02 should be further decomposed. As for FR01, to make the customers feel comfortable in the residence, this hotel should supply natural illumination, heating, and municipal electricity. So, FR01 can be decomposed into FR011, FR012, and FR013. As for FR02, the customers need a healthy diet, which comes from a professional kitchen with enough fuel gas supplement. Thus, FR02 can be decomposed into FR021 and FR022. The detailed information of FR011, FR012, FR013, FR021, and FR022 is shown in Table 5.

Table 5. Detailed information of FR011, FR012, FR013, FR021, and FR022

Input these five functional requirements into ADS-DDRE and begin to search the corresponding design parameters. This time, some alternatives can be found for each functional requirement as shown in Figures 13–17.

Fig. 13. Alternative design parameters for FR011.

Fig. 14. Alternative design parameters for FR012.

Fig. 15. Alternative design parameters for FR013.

Fig. 16. Alternative design parameters for FR021.

Fig. 17. Alternative design parameters for FR022.

Based on the tables shown in Figures 13–17, the design parameter alternatives for FR011, FR012, FR013, FR021, and FR022 can be described by the intuitionistic diagrams shown in Figures 18–22.

Fig. 18. Design parameter alternatives for FR011.

Fig. 19. Design parameter alternatives for FR012.

Fig. 20. Design parameter alternatives for FR013.

Fig. 21. Design parameter alternatives for FR021.

Fig. 22. Design parameter alternatives for FR022.

There are many design parameter alternatives found by ADS-DDRE for the functional requirements, that is, two for FR011, five for FR012, three for FR013, two for FR021, and one for FR022. Therefore, the final design parameter for this design case should be one of the combinations of these five groups of design parameter alternatives, which meets the independence axiom and information axiom the most.

There are 60 (2 × 5 × 3 × 2 × 1 = 60) design parameter alternative combinations here in total. First, figure out their design matrices and test them with independence axiom.

The design equations of the 60 design parameter alternative combinations are shown in Table 6. There are 12 design parameter alternative combinations go through the independence axiom test, so all of them are decoupled.

Table 6. Design equations of the design parameter alternative combinations

“DPA” is short for “Design parameter alternative”.

To select the optimal one from the 12 design parameter alternative combinations, their component design resource number should be figured out, as shown in Table 7.

Table 7. Design resource number of the 12 design parameter alternative combinations

Here, the design parameter alternative combination, C32, consists of the least design resources, which means it contains the least information. Based on the information axiom, here should take C32 as the optimal design scheme as shown in Figure 23. In this design solution, there are five design parameters in total, that is, DP011 for FR011, DP012 for FR012, DP013 for FR013, DP021 for FR021, and DP022 for FR022. Among them, DP021 and DP022 are design resources, and DP011, DP012, and DP013 are design resource combinations.

Fig. 23. Final design solution.