A Fuzzy Method for Propagating Functional Architecture Constraints to Physical Architecture

Abstract

To cite this version:Eric Bonjour, Samuel Deniaud, Maryvonne Dulmet, Ghassen Harmel. A fuzzy method for propagating functional architecture constraints to physical architecture.. Journal of Mechanical Design, American Society of Mechanical Engineers, 2009, 131 (6) The product domains are mainly composed of three sub domains [1], which are:• Customer expectations and life-cycle requirements,• Functions which are arranged in the functional architecture,• Sub-systems and components which are arranged in the physical (or design) architecture.These domains form different views of the product at different levels of abstraction. Requirements correspond to external functions and constraints that the product has to satisfy. These requirements are fulfilled through the realization of the system functions that in turn are realized by the integration of different product components.In the engineering design field, researchers have developed architecting rules and methods to map functions to physical components [2][3][4][5][6]. Other approaches view the functional model of a system as being described by an abstract functional decomposition that may, but does not need to, have a direct mapping onto physical decomposition of assemblies and subassemblies [7]. Ulrich [3] defines product architectures as "the scheme by which the function of a product is allocated to physical components." A key feature of product architecture is the degree to which it is modular or integrative [8]. In modular architectures, functional models of the product map one-to-one to its physical components. On the other hand, in integrative architectures "several functional elements are each implemented by more than one component, and several components each implement more than one functional element" [3]. In real design situations, designers have to make a trade-off between modular and integral architectures.Hence, many products are hybrid [9]. Their architectures are not fully modular or integral and lie somewhere between the two extremes. The above definitions are mainly based on the functionality of a module. There is another common way of defining a module by only focusing on interactions between elements. Baldwin and Clark [4] define a module as "a unit whose structural elements are powerfully connected among themselves and relatively weakly connected to elements in other units". Browning [8] defines integrative elements as interacting with all of the modules without belonging to any module.Research, concerning platform-based product development and product family design [10][11][12][13][14][15][16], has received huge interest over the last decade since it aims at providing methods to identify common modules and generate product variants with distinctive modules (commonality vs variety). According to [10], a non-unique component is defined as a component that is present in at least two products in a product family. It can be either common between the products sharing this component or variant across products.Overviews of current research status on th...

A method for jointly drawing up the functional and design architectures of complex systems during the preliminary system-definition phase

“…They are being increasingly used in systems engineering for product modularisation (Stone, Wood, and Crawford 2000;Alizon et al 2007;Ulrich and Eppinger 2008), for designing product platform architectures (Luh, Ko, and Ma 2011;Li et al 2012), for analysing technical interactions either within products (Whitfield, Smith, and Duffy 2002;Bonjour et al 2009;Helmer, Yassine, and Meier 2010) or within the project organisation (Pimmler and Eppinger 1994;Sosa, Eppinger, and Rowles 2003;Arundacahawat, Roy, and Al-Ashaab 2011), for analysing change propagation (Clarkson, Simons, and Eckert 2004;Keller, Eckert, and Clarkson 2009;Fei et al 2011;Cheng and Chu 2012) and for representing the structure of collective design competencies .…”

Architecture decisions in different product classes for complex products

“…While much design research has been carried out into the creation of design concepts through experimental studies or generative systems and modeling methods for both requirements and functional modeling, the process of designing the system architecture of complex products in industry is not yet clearly identified or understood. Based on our own case studies and those published in the literature (Chepko et al, 2008; Bonjour et al, 2009; Albers et al, 2011; Moullec et al, 2013), this paper will argue that there is huge variation in the process of creating a system architecture and the decisions required to define a system architecture, as well as in the support that designers require to do so. The system architecture of a highly innovative one-off product, such as a space shuttle where new technology is employed to meet newly identified functions, is very different from that of mass product incremental products like traditional cars.…”

“…While much of the academic research on system architecture, such as (Ziv-Av & Reich, 2005; Bonjour et al, 2009; Hellenbrand et al, 2009; Albers et al, 2011) is concerned with the generation of completely new systems, this is rarely the case in industry, where most products are to a certain extent reusing components, systems, or solution principles. Therefore, the degree of novelty is an obvious dimension of our classification.…”

An Unsupervised Machine Learning Approach to Assessing Designer Performance During Physical Prototyping

“…Later stages require designers to select which requirements are suitable for ideation, a task which has had many proposed solutions [3][4][5][6][7]. The subsequent concept Dering MD-17-1178 1 generation phase has been impacted by advancements in automation tools, with many methods available that can generate concepts [8][9][10]. Next, design validation and assessment can be accomplished using semi-automated simulation techniques, such as Computational Fluid Dynamics [11,12]; however, this does not eliminate the need for physical prototyping.…”