The Configurable Complementary Structures (CCS) model

The generic product structuring (GPS) concept basically provides an answer to the issue with describing variability at every single level of a product structure in order to define a recursive and non-redundant product family modelling language across domains (Erens, 1996).

GPS leverages the notion of parameter (variable feature) with parameter values (option values) to allow setting an expression condition at any level of a platform single product structure in order to later dynamically retrieve a specific configuration where a selection condition is met. This removes the cumbersomeness of handling every variant product structure separately.

Configuration constraints that exclude some combinations of parameter values are also used to ensure only valid selection expressions are passed to generate coherent product variants. To elaborate, the generic bill-of-material (GBOM) concept translates a customer-order commercial specification (set of valid parameter values) into a production-oriented variant bill of materials by retrieving generic preferred modules and then, physical components, that meet the selection condition (Hegge & Wortmann, 1991; Van Veen & Wortmann, 1992). GBOM purpose is specifically about generating variant product structures for customer-driven manufacturing (ATO, MTO, PTO, CTO) by efficiently translating a flexible product variant’s commercial description into a coherent variant product structure that is suitable for fast paced realisation processes (Wortmann et al., 1997). While GBOM supports a configuration-oriented modelling of product platforms by underpinning interdependencies between the functional (customer

requirement), technological (generic modules) and physical (component) domains, GPS represents the underlying generic product structure modelling by which the domain construct ranges are parameterized at each level of the intended platform product structure tree. This can either be perceived from the physical domain standpoint to drive sales-delivery processes (Brière-Côté et al., 2010; Hegge & Wortmann, 1991; Van Veen & Wortmann, 1992; Wortmann et al., 1997) or strictly from the technological domain in support to product platform conceptual design (Erens, 1996). However, GPS modelling may present some limitations when it comes to engineer-to-order (ETO) product configuration because required alternatives are not necessarily understood and bounded before actual customer orders are received and ETO design is started. A well define modularity, scalability and foreseeable business strategy may help mitigate the issue but it is preferable to have mechanisms in place to adapt to unplanned customer demands while maximising the reuse of existing designs. For these reasons, Brière-Coté, Rivest and Desrochers (2010) propose an adaptive generic product structure (AGPS) approach by which constructs are categorized into common features (invariant), parameterized features (reuse of existing) and special features which are meant for specific ETO product needs as drawn from Mesihovic and Malmqvist (2004). This approach allows to aggregate new variability into a product platform single product structure while maximising the integration with the existing parameterized framework. In a nutshell, AGPS appends discovered variability (special features) to the generic product structure through ETO development cycles, which means new parameter or parameter values, modules and components are incrementally added to the structure to form the new integrated variability asset that enables reusability for the next cycle. Besides the ability to handle special features that support the current ETO design, the remaining part of AGPS is a GPS incremental update which is driven by a well-defined family configuration update process across ETO development cycles. GPS and AGPS therefore display valuable capabilities for modelling variability and configurability for ETO product platforms in multiple domains and development stages while fostering design reusability. According to the objective herein, it is proposed to use similar product configuration modelling approach by adopting a representational formalism that is suitable for product lifecycle management implementations. Such formalism is for example used by Peltonen et al. (1998) who explain that an ordinary structure extended with optional, alternative and parametric items can be regarded as the explicit structure of a configuration

model. These authors state that the explicit structure together with the constraints governing the configuration retrieval process “roughly correspond to the idea of a generic product structure”. In product lifecycle management contexts, explicit structures are formalized using the notion of effectivity with most prevalent usage in engineering change configuration management (Watts, 2012). Effectivity, which is defined on the relationship between two constructs (within or across domains), is basically a parametric expression associated to the child construct that determines the conditions for which the construct is “in or out” in the context of its parent or another upper level construct. The parent construct in turn is deemed configurable as it contains children that can be filtered “in or out” based on their individual effectivity parametric expressions. Variability and configurability are therefore maintained at the configurable construct level which usually appears unresolved i.e. 150%. This explicit structure requires a valid effectivity expression to resolve/filter coherent configurations (100%) that bear meaning in the specific domain context.

Figure 5.6 shows a conceptual entity relationship diagram (ERD) of the proposed CCS model using Chen (Chen, 1976) notation style. Functional coupling relationships are not represented to ease readability.

Figure 5.6: CCS conceptual entity relationship diagram

It can be seen from the ERD that the relationship between the constructs in the same domain is simply homonym of the construct and it allows for explicit structures in the domain except for existential domain which do not allow to set effectivity on the relationship at this point. This is justified by the fact that a serialized individual is inherently resolved. Also, SI is modelled as a weak entity because it requires a DP to exist, for instance a Part definition. Within the technological domain, architectural modularity is defined by the various effectivity paths at each level of the logical structure tree (LFs), whereas scalability is reflected by the range of design embodiments (DPs) that can be selected through gbom effectivities to instantiate coherent product variants. Similar variability can also be maintained directly in the physical domain as explained in chapter 4. This is graphically synthesised in Fig. 5.1 where the first block is used as a template of the intended modular product architecture (100%) whereas the explicit structure is actually maintained in the physical domain. Such approach is suitable for companies with DMU/BOM-centric development processes whereby formalising a separate flexible logical abstraction of the product platform is not seen as mandatory. Although the advantage of architectural explorations without physical embodiment is inherently removed in this case, and also tracking from the physical embodiment back to the functional requirement may be difficult, the approach is sometimes justified by a requirement to reduce the burden of maintaining an additional structure with no real operational value (perception is only DMU/BOM does). Indeed, productivity and lead time concerns may arise in the case of fast-paced development processes where there are very less changes to the logical constitution of the product and participants can quickly interact using/re-using product structures in the physical domain i.e. DMU, eBOM, mBOM rather than trying to formalise a tribally known logical architecture beforehand. In these situations, even for breakthrough designs, advance design cross-sections, layouts or master lines that result from preliminary multi-disciplinary design optimisations (Panchenko et al., 2002) appear sufficient to kick-off the DMU/BOM centric development process for a selected alternative. In these cases, physical domain scalability represents the sole variability that is further leveraged and there is no apparent need to maintain a formal explicit logical structure that contains alternative designs and the rationale for eliminating them. This is to say, it is not always given that companies are willing to maintain product structures in the technological domain. This may necessitate ability of the product to be modularized, a product portfolio that requires SBCE

as discussed with Table 4.1, a strong business strategy, resource allocation and understanding of the value in maintaining logical structures and alternative design data on the long run. Figure 5.7 below illustrates the approach from a product platform conceptual design standpoint whereby logical abstraction and multi-domain variability are fully leveraged i.e modularity and scalability.

The catalogue of parameters, parameter values and constraints that drives the effectivity expressions in the tree is showed on the top right as inspired by Erens (1996) p.135. Constraints for example do not allow to filter configurations such as [x1,-,z2,-] or [-,y1,z1,-] because they do not resolve into coherent product configurations (PC) or so-called, valid architectural options (AO). In the context of SBCE, such catalogue and resulting explicit structure can be understood as the design space or design bandwidth to progressively narrow by allowing other functional groups to view/filter product alternatives in their own domain. Functional groups can therefore develop their own options in reference to the explicit structure and by using a common PD framework, shared constructs and data sets (single version of the truth). Each alternative option is then evaluated through virtual simulations, prototyping and test. Data as gathered for each combination of options is associated to the corresponding configuration, thereby becoming codified knowledge available to the whole community in support to set-based convergence for current and future development programs.

Figure 5.7: Illustration of CCS cross-domain implementation (Technological to Physical. No manufacturing process represented)

The adopted effectivity approach allows for product configuration modelling in the functional, technological or physical domains and is furthermore compatible with configuration engines (configurators) typically available in PDM and PLM systems, see (Mesihovic &

Malmqvist, 2004). These configurators can be designed to resolve architectural option effectivities (parameter, parameter values) and constraints when applied to technological or physical constructs (Sabin & Weigel, 1998; Soininen, Tiihonen, Männistö, & Sulonen, 1998).

Also, configurators have already proven very effective and robust for resolving change evolution effectivities (date, unit, product versions, etc.) during product development and beyond, see examples in (Mukherjee, Ryan, & Wason, 1994; Orr, Panuganti, Ryan, Sambataro, & Wason, 1993).

It is claimed that the multi-domain product modelling (section 5.2), variability and configurability approach devised herein together hold the potential to support explorations of a product platform design space by allowing various disciplines involved in the product lifecycle to consider sets of distinct alternatives concurrently so as to appropriately inform a set-based design

convergence process. This is in support to the implementation of the first set-based design fundamental principle as stipulated by Gosh and Seering (2014), see principle A in section 2.2.1.

It is also claimed that the approach allows for the preservation of conceptual solution sets until variants are instantiated in the physical domain and data is cross-functionally collected to inform the decision-making process. This is in support to the implementation of the remaining set-based design fundamental principle i.e. principle B in section 2.2.1. It is argued that the multi-domain approach can effectively support implementations of these fundamental principles in the sense that, by using the proposed framework and, as noted by Gosh and Seering (2014), the principles can manifest themselves in all phases of the design process, not limited to the conceptual phase or the interface with detailed design phases.

The proposed multi-domain product modelling combined with the variability and configurability components form the multi-domain Configurable Complementary Structure model (CCS) that partially fulfills RQ2 recalled below:

RQ2: What is an appropriate approach for various domains of expertise within the aerospace industrial product development to exchange on the basis of alternative design solutions and furthermore, narrow down to an optimal design by following a set-based convergence process?

Next section will provide additional details on the set-based convergence process.