Go to the table of contents.

Previous ...


5.1 Overview of the research results

5.1.1 Relationship between research topics and presented papers

The research work presented here has focused on a set of issues regarding the creation and representation of platform-based products intended to provide a set of high variety products to the market and has used a modular approach in so doing. The research is motivated by the dual need to improve the treatment of product variety in the context of established design methods and to do that in an organizational setting that requires scaleable solutions that are able to support product development in the context of an organization operating on a global market. The previous chapters have presented a wide array of related work. The issues and topics covered in a research that aims to address a core product model is however very broad making it virtually impossible to cover all aspects in related areas in detail. There is certainly more work that exists that for different reasons has not been referred to here. However, even though a great deal of work has gone into these issues over the years, there are still many issues regarding performing development of platform based, high variety and modular products in a globally operating company that remain to be addressed. The work presented is a contribution to this large field of interesting issues, both in the areas of engineering design theory and methodology and in the application of these theories and methods in an industrial setting.

Figure 51: Cross reference between research topics and presented papers.

Figure 51 provides a cross reference between research topics and the presented papers. The cross reference is only an overview, and the papers in general cover more than the highlighted topics. The cross references, however, represent the main purpose of each paper in terms of the research presented. The research, over time, has focused on different issues and aspects which are represented through the focus and content of the papers. One such focus has been a product description oriented perspective to the representation of high variety and platform-based products. Another has been on utilizing the introduced concept of configurable components as a supportive design tool for a systems engineer.

The focus on an improved core product description is mainly reported in papers A and C. The aim of these papers is the introduction and motivation of the configurable components. In these papers the contextual setting for the concept of configurable components is to utilize the concept of configurable components in a new generation of a product description system. A product description system plays a critical and central role in any manufacturing company. There are two main issues that are proposed to be improved through the application of configurable components in a product description system. The first issue concerns how product variability is dealt with in the current generation of product description systems. This issue is described in section 5.2.5. The second issue concerns the parts oriented paradigm upon which most current product description systems are based. A part in this context refers to those physical parts that are identified during product development to be handled by the manufacturing (and service) operations in the company in order to produce (and provide maintenance for) the products. Papers A and C furthermore present the implementation of the proposed concept in a new product description system used in a full scale vehicle development program. Naturally, this effort involves many more issues and work than are covered by this research and reported in this thesis.

The utilization of the concept of configurable components as a design tool is primarily reported in papers B and F. These papers are oriented toward relating the proposed concept of configurable components to engineering design methodology and issues in utilizing the proposed concept in the day-to-day work for the development of systems and products. Paper B has a theoretical perspective and includes and describes the proposed concept of configurable components in a framework that supports systematic product platform design using a combined function-means and parametric modeling approach. Paper F aims at providing further understanding of the proposed concept through the use of the concept in a pre-development case (i.e. a cross-car beam study). Furthermore, the concept is put in relation to and compared with previous research by other authors on the concept of generic product structuring (e.g. see section 4.5.4). Furthermore, paper F focuses on some additional elements and features of the proposed concept of configurable components (e.g. component structure instantiation).

Not only products need to be developed. A defined product will of course also need to be manufactured and produced. Therefore, the development of the manufacturing system deserves consideration as well. Platform-based, high variety, modular products are also challenging in terms of the development of an efficient manufacturing system for these products. Therefore, when the product development capabilities are extended through the application of the configurable component concept in the representation of the product’s definition, this will impact the approach to manufacturing system development and how to represent the manufacturing system. In papers D and G the configurable component concept is put into this context and generalized into a framework that can be applied for both product representation and for representation of the manufacturing system. The work presented in this area is only a first step toward showing the applicability of such an approach. Utilizing the configurable component framework for development and representation of the manufacturing system will require more work in terms of incorporating the framework with existing design methods similar to the work presented in paper B on product platform design and development.

Paper E represents an effort to further explore the implications from a design perspective of the issues involved in design for variability in a platform-based context. The work presented highlights the importance of product brands in the context of platform-based development and illustrates the impacts of this scenario on the complexity of the design tasks. The variety and commonality design space is introduced and discussed as a means to enable a deeper understanding of the fundamental issues involved in creating branded product variety using a platform-based approach. The concept of design bandwidth is introduced as a measure of the required and provided ability and flexibility of a design solution to participate in a product platform. Paper E furthermore proposes the introduction of a layer of variable influence factors to be identified as sources of variation in the functional requirements. In combination with the concepts presented in the other papers, a comprehensive framework can be envisioned that links the sources of variation to the embodiment and manufacture of adequate variety in response to the needed variation.

Finally, paper G also touches upon the possible formation of a framework utilizing the concepts developed in this research to provide and integrate operational model connecting sales and marketing with the product definition and the manufacturing systems models to form an integrated business oriented framework.

5.1.2 Contextual foundations of the research results

The research results presented is an extension of knowledge that builds on the previous achievements of many people. Figure 52 provides an illustration of a number of established fields in engineering design that has provided foundations and contexts that in different ways are utilized and integrated with the proposed concept of configurable components. The intention of the figure is to provide an illustration of how different knowledge areas have inspired and contributed to the formation of the research and the results. The figure does not intend to propose any similarity in significance between the results presented here and the fields that have provided the contexts and foundations for this research. It is, however, an illustrative picture of how the concept of configurable components has come into existence and how it is supported by previous research and established frameworks and methodologies.

Figure 52: Theoretical foundation for the proposed CC framework.

The observant reader may notice that the systems engineering area is represented with a reference that is more recent than the introduction of the concept of configurable components. This is justified by the fact that systems engineering is a large field with many possible references and yet no single reference that by itself represents the entire field. The reference selected represents a view of systems engineering that is closely related to the envisioned utilization of configurable components.

5.1.3 Conceptual map of topic areas

Figure 53 presents a conceptual map of topic areas that are within the scope of the research work that has been performed and is presented in this thesis and its attached papers. The purpose is to provide an overview of the areas involved as well as to some extent show how the areas are related on a high level and in the perspective of the work presented.

Figure 53: Conceptual map of focused areas.

The conceptual map illustrates how the product description area that was the point of departure for this research is related to the conception and exploration of configurable components and a systems structure for product representation that is composed of configurable components. The aim of an integrated product and process model leads to the exploration of applying the configurable components framework to a manufacturing systems structure and manufacturing operations model. The context of the work and models created within the automotive industry is a platform-based product development paradigm where the aim is to maximize commonality and re-use while providing customers an adequate product variety. The proposed solution path for achieving this is to focus on the assurance of design solutions developed to provide an appropriate design bandwidth enabling a co-optimized balance between commonality and re-use that governs efficient internal business operations and a product variety that enables efficient external business operations to achieve customer satisfaction and enthusiasm.

5.2 Product description

5.2.1 A process model for an integrated product model

To be able to discuss and develop an integrated product model (IPM) there is a need to frame a common understanding of the context within which this IPM is intended to be used. A process model (see Figure 54) representing this context was developed in team discussions held while working with the new generation core product description system (see illustration d in Figure 55 below). The main purpose of this process model is to guide a high level analysis of important requirements that must be placed on an integrated product model. The model is not complete in the sense that it does not cover the full lifecycle of a product nor does it cover all areas in an enterprise. Like any model, it is developed to suit its particular purpose. In this case the main purpose has been to increase the understanding of the role of the core product description systems used by a car manufacturer and especially in the interface between product development and manufacturing operations (or more accurately the order-to-delivery (OtD) process).

Figure 54: A process model for analysis of requirements on an integrated product model.

One of the intentions of the model is to create a clear-cut separation between the product development and the production processes. In reality, no such clear separation exists but, as a modeling approach, it can be justified. The clear boundary between the two processes serves the purpose of providing a clear foundation for analysis of each of the two processes and for the interactions and interfaces necessary between the two. The layout of the model also serves the purpose of illustrating that a relatively small flow of money through product development controls the large flow of money during the production operations (e.g. compare with a sound amplifier). This amplifier analogy can highlight the importance of the content and quality of the control current (development results used for production operations) for the quality of the resulting sound (the effectiveness and efficiency in the production operation and the products delivered). Based on this analogy it should be of interest to more carefully analyze exactly what constitutes the control current and how the control current from product development is used to control the large current in the order-production-delivery process. Furthermore, two important questions can be identified: (1) What is actually delivered as an end result from the product development process to the order-production-delivery process; and (2) What ought to be delivered? Even though the concrete exploration of these two questions is beyond the scope of this thesis they are mentioned since they influence the observations and analyses made in this research work and the understanding of how the answers to these questions influence and shape the concepts presented and proposed.

For an automotive company the operations of the order-to-delivery process at minimum will require: (1) one or several production facilities with installed and operational production equipment; (2) product and process information in order to plan and control the execution of the production processes; (3) a trained workforce acting on the production information made available for control of the production system, thereby producing the intended outcome from the production operations; and (4) an established supply chain (including the necessary communication linkage for production control) providing the materials and component modules required to produce the products. A similar set of prerequisites is assumed to be relevant for the service operations.

5.2.2 The central role of product descriptions

Two basic assumptions were made in the early phases of this research. The first assumption is that there is a need for an integrated product model (IPD) that is capable of representing the emerging product definition throughout the different phases of product development – from early conceptual phases until the product is retired, or at least until the start of regular production. The second assumption is that this integrated product model should be used by a computer application providing the core product description system within the company.

The first assumption is motivated by the need of a coordinating mechanism between concurrently operating cross-functional development teams that may be physically and organizationally decentralized. That is, a development team can be located anywhere around the globe as well as be part of a collaborating development company. Providing a common view of the current state of the emerging product definitions is considered an important enabler of effective and efficient collaboration between the teams involved. Furthermore, development of complex products involves many different disciplines and technological areas that need to be embraced and coordinated throughout the lifecycle of the product and especially during its development phases.

The second assumption serves to highlight two important aspects. First, the amount and required reach and speed of availability of the information require that the product description is computer based and available at any time, anywhere in the world, where it is needed in order to progress with the development process. Second, by a core description it is implied that adequate and timely information must be provided for all cross-functional disciplines as well as for all specific disciplines within different functional areas (e.g. all different technological areas such as mechanical, electrical, and software engineering disciplines).

The reason for making these assumptions is the understanding that a well-designed and well-implemented product description approach and system support is essential for supporting the development teams so that they move forward effectively and efficiently through the development process. Two aspects are considered that support the assumption. The first aspect is that coordination of the cross-functional activities and decision making will be improved by providing a common view of the emerging product. The second aspect is that this common view must be provided throughout the product lifecycle. As a consequence, a common view of the current state of the emerging product definition must be provided that ranges from its initial state of being incomplete and inconsistent towards the final state. In the final state a complete and consistent set of information is available that can be utilized by the following processes to: produce, deliver, use, and service the product (see Figure 1 in section 2.2).

An observation that can be made on the basis of the scenario described above is that the capability to make sense of a large amount of (inconsistent and/or conflicting) changes that occur frequently and have many sources of entry is a vital feature that must be a property of a computer-based product description system acting successfully in the role described above.

5.2.3 The "invisible" product description

It may be easy to talk about and refer to a product definition and/or description, but it is hard to actually identify its composition in a real product development environment in a company. There may be a computer-based core product description system that is referred to as being the master of the product definition and description. However, it is not uncommon that such a core product description only manages a fraction (albeit an important fraction) of the information that is actually required to have something that comes close to a product definition and/or description.

Instead of a clear and concise product description there may be many different documents and systems describing different overlapping (and in some cases even disjoint) sub-sets of design documentation about the product. With many different documents and databases, where each and every one defines and describes certain aspects of the product, the coordination and availability of these documents and databases naturally becomes an issue.

Furthermore, for each of the documents and databases there is associated a certain sub-set of the people involved in the development as the user community of that particular document. A natural consequence of this is a problem keeping all these different documents synchronized, i.e. making sure that they describe the same product and the same set of design decisions taken about the product at this state in the development process.

This is particularly difficult in early phases of the development process when many different design alternatives are generated and participate in the development efforts. Simultaneously, many design decision about the product design and the direction of the design are taken. Much of the information dealt with during this phase is also difficult to represent formally and therefore to manage within documents and with computer support.

It is however not uncommon to find that some form of a parts list system plays a central role as a provider of the common definition of the emerging product. The parts list system often also provides a rigorous functionality for change management of the information to be managed by the system. These systems have often evolved with the company over a long time and grown to become more or less an "enterprise" system with interfaces and dependencies cross-functionally throughout the company and many different business processes and systems tied in.

5.2.4 Evolution of product descriptions

Companies that develop, manufacture, and market complex products need a way to define their products and to forward this definition in a way that enables the manufacturing operations. The approach to product description used has slowly changed over time (Figure 55 and paper A). Primarily two factors can be distinguished to be drivers of this evolution. The first factor to be mentioned here is the rapid evolution of information technology. The central role of the product description system combined with the integration ties from both an information systems perspective and between several business processes implies that there is a great deal of inertia involved in a change of the product description system. The underlying information technology of a product description system may, however, be changed without changing the basic approach to product description. The second factor driving the evolution is therefore to be found in the underlying approach to product description.

Figure 55 describes four generations of an evolution of the underlying basic approach to product description. The first generation with simple parts lists is sufficient only for dealing with simple products. Therefore, with computer-based product descriptions and with more complex products, it became necessary to introduce a hierarchical approach to product description.

Figure 55: Evolution of product descriptions.

The product description system of an automotive manufacturer is a core supplier of the information that enables the manufacturing operations. Since the manufacturing operation of an automotive manufacturer to a large extent revolves around assembly operations, the product description methodology is based on a physical part paradigm. That is, the information managed by the product description system is traditionally centered on physical parts and their use (e.g. through usage definitions) in the products. The physical part paradigm is well-suited for supplying manufacturing operations with the information required in day-to-day operations. It is also rather well-suited for supplying after-market service parts operations with the information required to identify and manage spare parts inventories. It is however not very well-suited for supporting the development phase of the products and especially not in early phases of product development. Even though the physical part paradigm has been the prevailing paradigm for product descriptions the approach to how to define product descriptions has changed and evolved over time. This evolution of product description approaches is illustrated in Figure 55.

During the late 1970s and beginning of the 1980s Swedish automotive manufacturers moved from the parts hierarchy approach as in (b) in Figure 55 to a variant parts hierarchy as in (c) in Figure 55. The reason for this change is twofold: first, the maintenance of a separate hierarchy of parts for each product variant had become too resource consuming, since the number of product variants to be produced were constantly increasing. Second, the change to a production system where products were produced based on customer orders instead of being produced to stock according to a production plan required better approaches to product descriptions. The variant parts hierarchy, illustrated in (c) in Figure 55, provided a drastic improvement in addressing these two issues.

5.2.5 Variant bill-of-material and product configuration

Several slightly different approaches to the variant parts hierarchy exist, but in essence they all share a similar behavior (see for instance also section 4.5.3). In the case of this research the variant parts hierarchy approach is illustrated in Figure 56. In this kind of variant parts hierarchy, the top level (or levels) has been eliminated from the static structure definitions. Instead, the top level (or levels) forms a variant control structure for selection between different available variants of the static structure definitions. For each leaf in the variant control structure a variant of a static structure definition must be selected.

Figure 56: Variant parts hierarchy.

Associated with each leaf in the variant control structure is a set of static structure variants that are available for selection to represent this leaf in the control structure when a particular product variant is requested. Each of these static structure variants is tagged with one or more lists of feature labels.

A product variant is defined through the definition of a list of feature labels. To obtain the parts to be used in a particular product variant, the product variant definition (i.e. the list of variant labels identifying the product variant) is assigned to the variant control structure. When such a product variant definition is available in the variant control structure a matching can be made between the tagged static structures and the product variant definition assigned to the variant control structure.

In the approach to the variant parts hierarchy described here, there is a requirement that one and exactly one matching static structure variant must be found for each leaf in the variant control structure. This is in a way a mechanism to ensure completeness, but it is also a requirement that in some cases leads to work around dummy data creation.

With these basic mechanisms in a variant parts hierarchy, what remain to comment on is the product variant definition and the tags on the static structure variants. In this case, the variant labels are defined in groups that we can refer to as a variant label family. In such a family, the variant labels are mutually exclusive when a product variant definition is created. That is, from each such family, one and exactly one variant label must be chosen to be included in the product variant definition. Again, this approach is a way to in some sense ensure completeness of the product variant definition. Similarly, the requirement also in some cases leads to the need for work around through creation of dummy data. The benefit of this rather restrictive approach is, however, simplicity, and in some sense it supports transparency and ease of interpretation and understanding.

The remaining mechanisms to be described are the rules that govern the construction of valid combinations of variant labels from the different families when defining a product variant. Two types of rules are used: invalid combinations and production rules. An invalid combination rule is simply a list of variant labels from different families that cannot be used in a product variant definition. A production rule is a rule that states that if a certain set of variant labels from different families are already present in a product variant definition, then another variant label – defined by the rule – should be added to the product variant definition as well.

The description of the variant parts hierarchy approach provided here is not a complete and exact definition. Rather, it is an illustrative overview of the basic concepts at work in such a product description approach. The main reason for providing this overview is that it provides a contextual background to the product definition environment in which the configurable component concept was conceived, defined, and implemented as a new core product description system.

5.2.6 Implementation of a new core product description system

With a starting point in the weaknesses of a core product description system based on a variant bill-of-material approach and a physical parts paradigm, the first steps were taken towards the configurable component concept (see section 5.4). Initially, the configurable components were referred to as "smart parts". The "smart parts" concept included the variant parameter interface (VPI) and configurability aspects of the configurable component concept, but was not connected to any methodological design approach. During work with the "smart parts" it gradually became increasingly evident that the physical parts paradigm was a major obstacle that needed to be removed. A major reason for the need to leave the physical parts paradigm was its inability to adequately provide support in the early phases of product development. As a consequence, a more abstract modeling entity was sought for. The answer became the development of the configurable component concept. It was also clear when working with this concept that it would require a systematic approach to the identification and creation of appropriate components and how to define and describe their configurability. The function-means approach provided a framework that could lend itself to be extended to incorporate the configurable component concept and provide a well-established and systematic foundation for how to use the new configurable component concept in product development.

The development of a new generation of "home grown" product description systems was not a viable option. Therefore, a new approach to a core product description system must be based on commercially available software solutions. In this case the choice of a software solution platform was the commercial PDM system iMAN from Unigraphics Solutions. This choice was based on a preference in the company rather than on an evaluation of the most suitable software package. This is not to say, however, that it was an inadequate choice. On the contrary, the iMAN package provided (and provides) very good functionality for management of configurable product structures.

This implementation of a new core product description system is described in more detail in paper A and paper C. Paper B provides a contemporary elaboration on the methodological issues involved in extending the function-means approach with the configurable component concept. The implementation is also further commented on in section 6.3.

Even though the conception of the configurable component concept has its starting point in addressing the weaknesses of a product description system based on a variant bill-of-material approach and a physical parts paradigm, the other problem with supporting the early phases of product development require additional considerations. In the context of this research work it can therefore be noted that the configurable component concept is treated from two major viewpoints: (1) as an improved approach to a core product representation in a product description system of a manufacturing company; and (2) as a representation of the emerging product during conceptual design. The second perspective is based on a systems oriented approach design.

5.3 A systems view and configurable components

The development of large scale and complex systems is traditionally the topic of systems engineering (see section 4.3). Product development in the automotive industry today is concerned with vehicles that are becoming more and more capable and involve many different technologies. The development furthermore involves many different actors both within the company and development partners that are also in many cases suppliers in the supply chain (however, not necessarily tier 1 supplier). Therefore, a systems oriented view seems to be appropriate to consider as a foundation for the configurable component concept.

A vehicle can be viewed as an open system (see 4.3.2). All of its constituent components are in constant interaction, and the emergent properties of the vehicle are not to be found in any of these components in and of themselves but are a result of both the components and the way in which they interact. Furthermore, the vehicle is in constant interaction with its driver and to some extent with the passengers and to an increasing degree with other technical systems in its traffic environment. The open systems view therefore seems to provide an adequate foundation upon which the product development of vehicles can be based.

In this perspective, a configurable component can be regarded as an encapsulation in line with section 4.3.5. With this perspective, the process of identifying and creating the configurable components to represent the product is guided by the two mechanisms of elaboration and encapsulation. As stated in section 4.3.5, this requires that the interactions among elements and emerging properties remain intact.

In the systems oriented approach more generalized, as opposed to specialized, design solutions are preferred (see section 4.3.6). This corresponds well with the configurable component concept that provides for specialization of the components mainly through their configurability mechanisms. This is a slightly different approach to the more traditional approaches of object classes with generalization and specialization classifications (see for instance section 4.5.4).

5.4 Configurable component concept

5.4.1 Introduction

A configurable component is an element that has been defined in order to allow for definition of different variants of the configuration of a system. A configuration of a system is a specific variant of the system that has been achieved by selecting values for the variant parameters made available in the definition of the component. The set of variant parameters that are available for requesting a configuration of the component are collectively referred to as the variant parameter interface of the component. A configurable component is intended to be regarded as a system construct (section 5.3 ). This means that many of the properties and features that are associated with a system should also be present in a configurable component. For instance, this includes modeling of emergent properties that complement the properties of the individual encapsulated design solutions.

One of the most prominent features of a system is that it is composed of elements that interact in order to fulfill the purpose of the system. These elements of a system may themselves be systems in their own right. In this way the systems form a kind of hierarchical structure (see section 4.3.5). The same mechanism and behavior are intended to be available in the configurable component concept. A configurable component may be composed of other configurable components as elements in its definition (similar to the elements of a system). What makes the configurable component concept somewhat different is that the actual set of components that constitute the composition of the parent component depends on the configuration of the parent component. Furthermore, since the components used in the composition of the parent component are assumed to be configurable components as well, the parent components configuration will also determine how to configure the components in its composition. The topic of conditional existence of variables has been explored by for instance Bowen & Bahler (1991) in the context of generalized constraints networks (see also section 4.2.4).

5.4.3 The anatomy of a configurable component

To be able to provide for the features that have been described above the configurable component needs to provide a set of constructs and mechanisms. This means that the configurable component will have a definition of its own elements and their functionality both in terms of how they relate and interact within an instance of a configurable component and in terms of how the relations and interactions with other instances of configurable components are intended. The understanding and definitions of the internal mechanisms and elements in a configurable component have naturally evolved during the time of this research work. The early definition and understanding of the anatomy of the configurable component are given in paper A. Primarily, the internals of the configurable component at that time consisted of a configuration rule set (CRS) that provided the mapping between a requested configuration of the component and the selection of a set of (sub-) components that corresponded to the request. The configuration request is provided using the variant parameter interface (VPI). The configuration rule set furthermore included rules necessary to – in turn – request appropriate configurations of the (sub-) components that were selected to be included. In this early phase of the model, the design solutions were kept as relations from the configurable component to a function-means tree that was supposed to be used to derive the appropriate design solutions based on the functional requirements on the system or design at hand. This model is described in Figures 6 and 7 in paper A.

An understanding gradually emerged that it was necessary for the configurable component to encapsulate the design solution definitions as elements of its internal structure. There are several reasons for this approach. One is concerned with the fact that the design solution definitions in many cases will be parametric designs. In such a case, the configuration rule set of the configurable component can benefit if it is capable of using the parametric constructs in the design solutions. Otherwise, the configurable component would have to duplicate some of the parametric behaviors of the design solutions in its own rules. This would then be a duplicated effort with the same intentions defined two times with potential inconsistencies arising and no additional benefits. The configurable component model with design solutions captured as internal elements is illustrated in Figure 4 in paper D.

With the encapsulation of design solution elements within the boundary of a configurable component follows a need to reflect upon what kind of parameters it will be necessary to deal with in the internal structure of the component. Three basic kinds of parameters can be distinguished: design parameters, performance parameters, and variant parameters. It should be noted that in many cases there are no clear and sharp borderlines that define whether a parameter is of a certain kind. A parameter can, for example, be considered both a design and a performance parameter depending on the actual design task and design solutions considered. However, it is important to carefully consider these three kinds of parameters in the application of configurable components to a design problem. One reason for this is that this classification of parameters provides a structured approach to finding the appropriate parameter sets while it also provides a foundation for a structured approach to the definition of the rule sets that are necessary to define the solution space of the configurable component in terms of its parameters and parameter values.

Design parameters are the characteristics of a design solution that the designer can directly influence with a decision about the value of the design parameter. In Figure 57 the design parameters are exemplified with the length (d1), width (d2), and height (d3). Performance parameters are those characteristics of a design solution that represent measures of the purposefulness of the design solution. In Figure 57 the performance parameters are exemplified with the area (a) and mass (m). Variant parameters are a constructed (artificial and abstract) set of parameters (of features) that, in the view of a user, can be used to differentiate between different design solutions that are variations of a basic design solution. In Figure 57 the variant parameters are exemplified with thickness = {thin, thick} and size = {small, large}.

Figure 57: A simple example illustrating the parameter taxonomy.

The variation is achieved through different values of the design parameters that, as a consequence, will provide different outcomes in the performance parameters. Variant parameters are provided as a convenient mechanism to define sets of design parameter values. These sets define discrete variants of the design solution that result in required or purposeful sets of performance parameters. In Figure 57 the parameters d1 (length), d2 (width), d3 (thickness), and the chosen material are design parameters, i.e. the designer can directly influence and assign these parameters a value. Parameters a (area) and m (mass) are performance parameters. The performance parameters cannot be assigned a value directly by the designer; they are rather consequences of the designer’s choice of values for design parameters d1, d2, and d3, as well as (in the case of the mass) of the chosen material. The parameters of size and thickness are variant parameters. The variant parameters will have no defined design meaning unless the designer defines the relationship between the values of the variant parameters and the values of a defining set of design parameters. Note that the qualitative variant parameter thickness should not be confused with the quantitative design parameter d3 (thickness). One approach to defining the relationship between variant and design parameters is through production rules (i.e. rules of the form "if … then …"). A function oriented approach could be considered as well (i.e. formulating the rule on the form "di = f(vp1, vp2, …, vpN)"). These two basic approaches can also be elaborated further to include mechanisms derived from constraint networks and semantic networks (see section 4.2.4). However, only dependencies formulated using production rules have been used within the scope of the work reported in this thesis.

The internal structure, elements, and mechanisms are further explored and described in paper F. Figure 7 in paper F provides an illustration of the main elements of a configurable component as well as additional illustration of the intention to allow components to exchange not only a variant parameter request but also in return to receive a response in terms of the performances achieved through the requested configuration. Furthermore, paper F provides a description and discussion of the mechanism to achieve the product structure as a result of a recursive instantiation of component instances (Figures 8 and 10 in paper F). Essentially, it is through this mechanism that the capability to re-use a component design, configured differently in several different contexts within the same product instance, will emerge. In paper F this is illustrated using a very simple example of a car with a door design that is assumed to be defined to be configurable in such a way that it can be utilized as a design solution for any of the potentially five door instances in an ordinary range of car body variants.

Considering the issues and models discussed in papers E and G has led to the most recent understanding of the elements that should be included within the boundary of a configurable component (Figure 58). In this proposed model of a configurable component the ability to use a function-means model to provide for the reasons for and rationales of the encapsulated design solutions has been brought inside the boundary of the configurable component as well. It is however important to recognize that this inclusion of elements is not mandatory. Whether or not the different elements and mechanisms should be included depends on the functionality and application intended for the utilization of the concept of configurable components. In this sense the model illustrated in Figure 58 represents the so far most elaborate model of a configurable component.

The elements of the configurable component in Figure 58 are: a parameter interface; a configuration rule set; a composition set; an interface set; a performance model set; a part definition set; and a function-means model set including functional requirements (FR), constraints (C), and design solutions (DS). The parameter interface is used in order to expose parameters defined within the configurable component to its users. The configuration rule set hosts all configuration rules or constraint networks based on the parameters defined within the configurable component. In the case that the other elements within the configurable component are parametric models in themselves, these models may also carry configuration rules and restrictions that complement the configuration rule set. The composition set carries the definitions of how this component utilizes other components in order to achieve its purposes. Within the composition set a composition element establishes the potential use of another configurable component. A composition element is decided to be included or not in a certain configuration through a rule that can be of the form use <component> if <condition> (see paper C). A composition element can include references to alternative components if this is required or a benefit. In that case, the composition element must include a mechanism to choose between the alternative choices available. Since this can be provided for in several different ways, no specific method or approach is proposed. The simplest approach would be to have a default choice. When a specific component has been selected to be included in the configuration, a configuration request will be issued to the referenced component. The elements described provide the basic elements required to create a system structure based on configurable components.

Figure 58: Anatomy of a configurable component and its composition.

5.4.3 System structure composed of configurable components

In some cases the system structure is intended to be able to be configured in such a way that it will identify a set of physical parts that will be used to build a product variant of the system (e.g. paper C). In such a case some of the components must also include part definitions. Part definitions provide the definition of certain physical part variants that correspond to particular configurations of the component. Physical part definitions are identified using an associated specification. This is similar to how product types are identified in the generic BOM concept (see section 4.5.5). Note that even though a part definition may carry part numbers as attributes, the way of identifying the part definition is through its associated specification and not by means of a part number attribute.

Two different approaches to physical part definitions can be considered. In one approach the configurable component includes the part definitions within itself. In another approach, the configurable component utilizes an external source for part definitions (e.g. a parts catalogue of some kind). In this approach the configurable component sends a request to the external source based on part attributes in order to get a response from the external source as to what part will fit those attributes. The second approach is illustrated in Figure 8 in paper B.

5.4.4 Configuration capability and constraints

In most cases the variant parameter interface (VPI) of a configurable component will provide for a very large (un-constrained) variant space. That is, the number of variant parameter value combinations is extremely large. This is in most cases only a theoretical number of combinations, and the encapsulated design solutions will not be capable of providing appropriate designs for all of them. Therefore, the actual design variant space encapsulated and defined by the configurable component is a substantially reduced sub-set. The configuration rule set (CRS) in the configurable component is responsible for providing the required constraints to achieve this. In the context of this reduction of allowed and available combinations (i.e. design variants) paper C introduces a distinction between three different situations that can occur. A particular combination of parameter values can be invalid for three main reasons. It can be a request for: (1) an impossible design; (2) an incomplete design; or (3) a not validated design. An impossible design is a design that is inconceivable according to the physical laws of nature. An incomplete design is a design that is potentially conceivable, but one that has not been completely worked through and is therefore to some extent still undefined. The third case is based on the question of whether a defined design variant should be allowed to be used. In many real situations, the defined design variant space will probably be larger than what is required and needed. Furthermore, only verified and validated design solution variants should be allowed to propagate and be realized in the actual products. Therefore, it is reasonable to include constraints in the configurability of the component that only allow configuration of validated design variants.

5.4.5 Self-sufficiency and information hiding

The configurable component boundary is intended to be defined in such way that the enclosed set is as self-sufficient as possible. The enclosed set of design information within the boundary of the configurable component is to a large extent intended to be hidden inside the configurable component. The information about the component is intended to be available through parameter interfaces of the component. The focus of this research has been on creating the necessary variability of a component, and the variant parameter interface has received the greatest attention. The variant parameters of a configurable component are used to create a finite set of features that is recognized by a user in order to facilitate support for a user of the component to request an appropriate configuration of the design solution. Through the variant parameters the features of a family of designs (captured within the configurable component) are highlighted.

The variant parameters facilitate information hiding since the user need not be concerned with the detailed values of the design parameters but can communicate on a higher level of abstraction (i.e. with less semantic gap between need for features and design details). An important aspect here will be the correlation between the variant parameters and the performance parameters. The performance parameters are a consequence of the selected design parameters and, in turn, the design parameters are determined on the basis of the selected variant parameters. Thus, from a user point of view, the performance parameters can be seen as a direct effect of the selected variant parameters. This is because the information-hiding concept shortcuts the design parameters and provides the user with a direct connection between variant parameters and performance parameters.

Variant parameter values are conceptually related to the grading and selection of sizes that, for instance, Pahl & Beitz (1996) use in their discussion of size ranges. Therefore, their reasoning regarding how to approach the selection of size ranges is also to a certain extent applicable to the identification and selection of variant parameters and their values in the context of configurable components. However, a configurable component may encapsulate a more differentiated set of design solutions compared to the size range concept. The configurable component concept is designed to also accommodate modularization. A modular product provides a different set of functions depending on its configuration. The configurable component concept is therefore considered to be able to accommodate size ranges as well as modular products.

Product development of complex, platform-based and high variety products is seldom carried out completely within the boundary of one company. On the contrary it is common that large parts of the development efforts are carried out by development partners and by companies that participate in the supply chain of the manufacturing of the products. An integrated product and production model of reasonable detail can therefore not be limited to describe only what one of these companies is developing by itself. The product model must be able to span across several of the development actors where each of the actors can provide contributions – definitely to the sub-set of the product model they have responsibility for, but probably also to other sub-sets of the model with which their own design solutions interact or are dependent upon in some way. The capabilities for self-sufficiency and information hiding are believed to be instrumental to the possibility to create and work with such a boundary spanning integrated product and production model. The recognition of the importance of self-sufficiency was identified early in this research (see for instance paper A) and this requirement has a profound impact on how the configurable component concept is defined.

Figure 59: Collaborative development.

The different colored areas in Figure 59 are an attempt to illustrate the effects of shared development responsibilities on the content of a product model. The distribution of a structure based on configurable components has not been within the scope of the research work presented here. However, the understanding that this must be possible in order to effectively support the kind of product development under study is the reason for the attempts to define the concept in such a way that such a decentralized approach can be achieved. Even in a large OEM there may be several decentralized units that are responsible for different design elements. This requires a need for information exchange to support collaborative design in the OEM that is similar to the need for information exchange in the interfaces between the OEM and its development supply chain.

An interesting and important issue in an integrated product and production model is that the partitioning logic for the product may be different from the partitioning logic of the manufacturing system. For instance, it may be important for an OEM to closely define and integrate a piece of software in the product. This makes the development issues of this piece of software a high priority and it is important to define and control the functions and behaviors of the software. Seen from a manufacturing perspective, however, the supplier of this piece of software may be a 3rd or 4th tier supplier. This example highlights the dilemma that, in a manufacturing oriented product structure, the recognized elements are those physical modules that are to be delivered to the manufacturing facility in order to be manipulated in some way by the manufacturing processes within the company. From a product development perspective, however, there may be a need to be able to recognize important design elements that are defined and designed by a 2nd, 3rd, or higher level in the tier structure of the supply chain. It has not been possible within the scope of this research work, however, to explore this issue in detail. The approach taken based on a high degree of self-sufficiency in the model elements is, again, believed to provide a foundation that makes it possible to deal with both boundary spanning models and modeling of the different partitioning logics between the product system and the manufacturing system. The proposed approach to addressing these two structures and their linkages is outlined primarily in papers D and G and section 5.7 below.

5.4.6 Technology and discipline independent

The need for overarching and integrating structures and mechanisms in an integrated product and production model is evident (Figure 60). The previous description of the need for boundary spanning models across the supply chains is one important reason. Another important reason comes from the increasing content of mechatronics and software design solutions in the products. In addition to the ability to provide for boundary spanning modeling an important aspect and requirement on a product modeling framework is the ability to support all involved engineering (and other) disciplines that interact during the development. The framework must enable management of information from different disciplines about the products as well as the platforms and manufacturing systems upon which the products are (or will be) based.

The proposed configurable component framework does not include dependencies on any specific engineering discipline or other discipline. Different kinds of more specialized models can be managed within the framework. For instance, the performance models illustrated in Figure 58 can be more specifically defined with certain engineering disciplines providing the fundamental domain knowledge required. The overall definition of a configurable component and the structure of components is however a system oriented view and as such is largely independent of specific technology domains. A systems oriented structure is driven more by purpose and function than the underlying technologies that make a realization of the system possible.

Figure 60: Multi-disciplinary product development.

5.5 A systems view of a product model based on configurable components

A product (in the context of this thesis) is a material (technical) system that is made by people for its properties. Because of these properties it can fulfill one or many functions. By fulfilling functions a product satisfies needs and gives people the possibility to realize one or more values (see section 4.1.4). In the definition of a product there is a causal chain: form -> properties -> function -> needs -> values. Product development generally proceeds in the opposite direction. Market research and business analysis establish the values and needs for certain products, which then are conceived and established in a product development process. A high level model of the context for product development and the necessary results is illustrated in Figure 61.

Figure 61: A systems view of the product development.

In this high-level model three major drivers influencing the development of the product are recognized and described as voices. These are the voice of the customer, voice of the business, and voice of technology. Each has a major influence on how the product will be developed. Recognizing the voice of the customer is essential to create a product that will be successful on the market. The voice of technology expresses the choices available from a technological standpoint and thus provides both constraints and opportunities for the design of the product. The voice of business provides the governing strategies and objectives for the mission of the product to be developed, produced, marketed, and supported from a business point of view. The voice of business thus provides direction for how to perform the development of the product as well as funding and constraints. The product is described by the triangle captured between the three major driving factors in Figure 61. The description of the product recognizes four major dimensions that must be defined in order to fully capture the product (see also Claesson & Bengtsson, 2004, paper D).

Starting with the lower right sub-triangle the physical elements that constitute the product are identified and described. The description of the physical elements that constitute the product is probably the most practiced approach to product description. Virtually all products are associated with parts lists or hierarchical part structures that can be used for sourcing, manufacturing, and service purposes. The lower left sub-triangle in Figure 61 captures the functions of the product that are identified and described. Functional descriptions associated with products during their development are however not as common as the description of the physical elements constituting the product. Looking at this from the customer perspective it is the situation is the opposite. The functions that can be provided by the product are well described in user manuals and other documentation of the product, whereas the physical elements from which the product is made are not described unless they are spare parts or accessories. Arguably, functional descriptions are more difficult to create than physical descriptions. Function is an intangible property of a product and will only reveal itself when the product is used (actualized) in a particular way (see section 4.1.4). Otherwise, function is a silent property that the product maintains. The upper sub-triangle in Figure 61 is intended to capture information about the product characteristics, that is, the set of perceived features of a product that is important to provide either because the features are more or less explicitly requested by customers in a market analysis or because they are implicitly required by the customers. In the latter case the customers would react negatively if the characteristics were not found in the product. The information captured tries to deal with perceptions and their mapping to the product. An example of a product characteristic could be that, for a car, it can be important that it is "fun to drive" or "safe". There is no direct mapping of these characteristics of the product to certain properties of the physical elements in the product, yet they are important to control and evaluate during the development of the product. The center sub-triangle in Figure 61 is intended to capture the architecture of the product. In this context we refer to the product architecture as the mapping of the elements in the three domains described above. Function elements identified and described in the lower left sub-triangle can be allocated or implemented by identified physical elements described in the lower right sub-triangle. The mapping of the function to the physical element is an element of the architecture that is captured in the center sub-triangle, i.e. an element of the product architecture.

The high-level model of the context of the product development and the necessary results to be created presented in Figure 61 can be further elaborated by placing the model into the context of established design theories and models. In this case we use the function-means model (see section 4.2.2) and the product function model (see Figure 12 in section 4.1.4). These models and some important relationships between them are illustrated in Figure 62. In this perspective, functionality is considered to be composed of two components – a pure function (i.e. what the product actually does, the process), and a set of characteristics (i.e. the aspects that characterize the function when it is in operation and thus provide the foundation for how the function, or rather the product, is perceived).

Figure 62: Relationships between models discussed.

The role of a core product description system is to provide a model that defines and describes the emerging product. Central elements that should be captured in such a description are the four dimensions described in the system view of the product illustrated in Figure 61. Based on the model framework described in Figure 62 and driven by the requirement to deal with variant rich, modular, platform-based products, the concept of configurable components was developed as a fundamental construct in order to realize such a 4th generation product description system (see Figure 55 in section 5.2.4).

5.6 A combined function-means and parametric modeling approach

5.6.1 Operational implementation of the CC as a product definition system

Paper C focuses on the implementation of configurable components (CC) as the core product definition and description system in an operational vehicle program. Figure 63 provides an illustration of the operational context for the implementation. In Figure 63 the configurable components are illustrated by the circles in the triangle. This triangle illustrates the configurable product model. Even though the variant parameters of the component Car could be used for configuration purposes, the operational implementation context required utilization of existing methods. In this case the product program was represented by the two elements, MAPP and TAPP. TAPP is a technically authorized product program, i.e. it should be constrained to what is technically feasible to manufacture and what has been validated as appropriate design configurations. MAPP is a market authorized product program, i.e. it should be the sub-set of TAPP that has been decided to be made available on the marketplace as product variants. Similarly, the release of parts to manufacturing had to be done in a way that mapped to the existing methods and IT systems. To achieve this, a mirror structure used by downstream systems was used to capture released parts and their usage statements (see Figure 63).

Figure 63: Operational context of the CC implementation (paper C).

This implementation rendered many different kinds of experiences. One such experience was the realization that a systematic and methodological approach to the identification and creation of configurable components to be used to build the structure is essential. An ad hoc approach to the definition of configurable components will soon lead to problems in the maintenance and understanding of the structure. The configurable component concept must be used in an efficient and adequate way in order to realize potential and expected benefits. A problem, however, is that there is no one single and obvious approach or method that will be the most appropriate for utilizing the configurable component concept. The flexible nature of the concept enables it to be possible to utilize in combination with many different methodological approaches.

5.6.2 A function-means based method to define configurable components

Within the scope of this research work the function-means (FM) based method is proposed as a systematic and methodological approach to utilizing the configurable component concept. The application of a FM approach and the relationships between a function-means model and a configurable component model are described in paper B. The approach described is based on using the configurable component concept in the manner in which it was introduced in paper A. That is, the configurable components are seen as a complement to a function-means based approach (see section 4.2.2). In the approach presented in paper B the configurable component concept complements the function-means approach in the embodiment phase (Figure 64) in order to provide for definition and management of product variety.

Figure 64: Design decision transformations and product model representation elements.

On a high level, the approach described is illustrated in Figure 64. Based on a market analysis represented through opportunities, needs, and problems, a function-means based approach to the design task is suggested. The FM approach is intended to be applied in such a manner that the generated design solutions (DS) are at such a level of detail that they can be analyzed from the standpoint of variety. This means that these DS will have to be detailed enough to allow for identification of individual design parameters (DP) that reveal the sources of variation in different performance aspects (see section 5.4.2). To account for variability in the product the generated DS must be either sets of alternative DS or parameterized DS. Design solutions described at this level of detail are probably mapped to the organs level, as defined in the chromosome model (see Figure 13 in section 4.2.1).

In a first phase the functional requirements (FR) and constraints (C) are thoroughly analyzed and a set of design solutions (DS) are conceived and defined. In a context where we seek to achieve product variety it is important that variety is considered in terms of the functional requirements as well as provided for by the way the design solutions are defined. In a second phase, the process continues with mapping of the design solutions to configurable components. A configurable component (CC) provides the implementation (or embodiment) of a set of design solutions. An important consideration in doing this mapping is to ensure that the CC will include a sufficient set of DS to be capable of being configured in such a way that one or more of its configurations provide a definition for the realization of a sufficient set of physical part variants or system variants. The configurable component consolidates the different ways the mapped DS are used in order to provide for variation. The CC achieves its different configurations through its parameter sets and configuration rules (see section 5.4).

This process of using the FM approach to define a solving set of DS and the following allocation of DS to a CC and the ability of a CC to generate several variants of a physical part is illustrated in Figure 65.

Figure 65: DS implementation and parts realization.

Figure 65 provides an illustration of a situation where each of the two CCs in the lower left of the CC structure (to the right in the figure) is an implementation of (iaio) a set of design solutions (DS) defined through a FM approach illustrated by the left part of the figure. Furthermore, the figure illustrates a system CC that is composed of the two previously mentioned CCs in such a way that it can be configured in at least three different ways. Each of the three physical part variants (P1, P2, and P3 below the CC structure in the figure) is physically realized by (iprb) a certain configuration of the system CC. This way, three different physical part variants – P1, P2, and P3 – are defined.

In the description of the approach provided above it is important to recognize that a distinction is made between how the words component and part are used. The word component is used to represent a solution to a design problem, whereas the word part is a representation of a physical part. It should be noted that software in this context is included in the definition of a physical part.

The distinctive use of the words component and part and the differentiation between the two words enables definition of effective, efficient, and flexible product models enabling product descriptions without the need for representations of instantiated physical parts. This is important for several reasons. Two of the most important are: (1) it allows us to describe, in one integrated model, the full range of products based on a common platform development effort; and (2) it enables support for analysis iterations in early phases without the overhead workload and costs that are normally associated with management of parts defined in specific usage structures.

5.6.3 Structure and part instantiation

The utilization of a system structure based on configurable components to release appropriate part definitions into a manufacturing control system environment has been previously described above in the context of the implementation performed (section 5.6.1). In general any configurable component can include one or several part definitions. Whether these are activated and/or instantiated depends on the configuration of the component applied as well as on the operation requested to be performed by the component/structure.

When a physical part is needed, a part definition is included as an element of the configurable component responsible for the design solutions upon which the part is based. The part definition is associated with configuration constraints in such a way that the part definition will respond to the appropriate configurations of the component. A component that is configured in such a way that the part definition is triggered is therefore the generative parent of the description and definition of the part. If needed in the specific context where the part definition is triggered, a part instance that will serve as a representation of the physical part can be created. Again, depending on the specific context, this part representation may be communicated to and used by other business systems whenever it is necessary for these systems to refer to this physical part (see for instance section 5.6.1 and paper C).

Considering that re-use of design solutions is one of the key benefits that are expected to be achievable through the application of the configurable component framework some comments on this topic should be provided. A simple example of a car and the doors were used in paper F to illustrate how design solutions can be re-used. The example is illustrated in Figure 66 below.

Figure 66: Re-use and instantiation of configurable components (paper F).

The design solution definitions for a car and its door system are provided for by the three configurable components: Car; Door System; and Door (illustrated in the left part of Figure 66). When a configuration and instantiation request is provided to the configurable component Car it will launch the recursive instantiation scheme illustrated to the right in Figure 66. The result is the instantiated configurable component structure illustrated in the middle part of Figure 66. This structure illustrates the re-use of the Door component in five different usages: two front side door applications ([1] and [2]); two rear side door applications ([3] and [4]); and a rear door ([5]) wagon application. In this particular example it has been assumed that the door system is always composed of two front side doors whereas the two rear side doors and the rear door depend on the configuration of the door system (which in turn depends on the configuration of the car). The "u" marking in front of the conditional doors indicates that, in this case, the configuration request did not supply enough information to determine whether or not these doors should be included in the configuration (i.e. the inclusion decision state is unknown).

The discussion of parts and structure instantiation provided above combined with the illustration of on how component definitions can be used in order to support a re-use oriented design paradigm serve the purpose of illustrating the potential benefits that can be achieved through the application of the configurable component concept to product definition and description.

5.6.4 A platform design process

The configurable components provide mechanisms that enable us to accommodate the variation of parametric design solutions. The adaptable design solutions are necessary in order to define the differences between the product variants based on a product platform. Simultaneously, the common and non-varying design solutions are kept well-defined in one place (i.e. in the configurable component). The configurable component provides the management of the variability (i.e. the configurations) through configuration rules and the posting of variant parameters in its interface. A systematic design approach that exploits the configurable component concept was described in paper B and commented on in the sections above.

Figure 67: The platform design process.

The platform design process is described with three phases: a top-down specification, configuration, and concept design phase; a bottom-level detailed design phase; and a bottom-up system design phase (Figure 67).

5.7 Configurable components for manufacturing system modeling

5.7.1 Relationship between product and manufacturing system models

In the previous sections of this thesis the configurable component concept was introduced and described as a means to provide for product variety development and definition. It is, however, not sufficient to be able to deal with product variety in the product definition only. Any product must of course also be manufactured and provided to the customer. In a context in which a high degree of product variety and customization is intended to be supplied to the market, the product development and definition are only a starting point. Two more domains must be considered in order to be able to fully utilize high product variety from a product platform. These two are the manufacturing domain and the sales and service domain. In this section the manufacturing domain will be included in the emerging framework of using configurable components to provide an integrated product model. The extension of the configurable component concept to the manufacturing domain was presented and described in paper D and paper G.

One important step in extending the fundamental mechanisms of the configurable component concept to the manufacturing system model domain is to establish an appropriate relationship between the two modeling domains. Different approaches to establishing such a relationship has been used in other contexts and for other purposes before (see section 4.6). The approach proposed in this work is based on the mapping between the two domains provided in Figure 68. The left part of Figure 68 illustrates the system view of the product model discussed above (see section 5.5).

Figure 68: Product system structure and manufacturing system structure (paper D).

Along similar veins, the manufacturing operations and their organization and resources can be referred to as a manufacturing system (illustrated in the right triangle in Figure 68). This implies that a system model should be equally well suited to describe the manufacturing system as it is to describe the product. A notable difference that causes confusion is that most often a product and a manufacturing system are described using different terminologies. However, by observing what the different terms in these two contexts actually represent, a harmonization of the two contexts in a similarly structured system model can be achieved. In the right part of Figure 68 the terms of a manufacturing model have been introduced in the same system model framework as previously used to represent the product. The proposed similarities are the following: obviously, both kinds of systems will exhibit different kinds of characteristics and properties that are consequences of how the systems are designed. The value adding material refinement operations performed by the manufacturing system are correspondingly mapped in the framework in a similar way as the functions of a product. The organization of the functions in a product is achieved through its architecture. Similarly, the organization of the operations in a manufacturing system is achieved by its process structure. The process of a manufacturing system is therefore considered to play a role similar to that of the architecture of a product. The last element in the framework is, for the product, the components that provide the actual implementation and realize the product. For a manufacturing system this is similarly done through the equipment and resources (e.g. human workers) of the manufacturing system. As a consequence, the components for the product and the equipment and resources for the manufacturing system are mapped in a similar way in the system model framework.

The focus when extending the concept of configurable components to the manufacturing system model will be placed on the manufacturing operations. The reason for this is that it is assumed that, in order to result in different product variants, some actions in the flow of operations must have been performed differently in the making of the product variants. Therefore, a variation defined and described in the product definition is assumed to be taken care of through a variation in an operation in the manufacturing system.

5.7.2 Taxonomy of manufacturing operations

Based on the central role the operation concept is given in the proposed approach to extend the configurable component concept to the manufacturing system model, it is reasonable to consider what an operation can be in a manufacturing system context.

Figure 69: Taxonomy of manufacturing operations.

In paper D a preliminary taxonomy of manufacturing operations was identified and presented (Figure 69). This taxonomy has not been explored in detail; rather it has been established merely to provide a sufficient differentiation between different kinds of manufacturing operations. This differentiation is assumed to be necessary in order to be able to provide for assumed differences in how they are to be included in and dealt with in the manufacturing system model framework proposed.

The top-most level of the taxonomy is the distinction between any operation and a manufacturing operation. The preliminary taxonomy distinguishes between three major categories of different kinds of manufacturing operations: (1) manufacturing refinement operations; (2) manufacturing handling operations; and (3) manufacturing assessment operations.

The first category – manufacturing refinement operation – is intended to include all the different kinds of value adding operations performed when creating a product using the manufacturing process. The second category – manufacturing handling operations – is intended to include all different kinds of handling operations in a manufacturing system. This category includes all material handling as well as other types of movements of equipment and resources in the manufacturing system. The third category – manufacturing assessment operations – is intended to include all kinds of monitoring that can go on within the manufacturing system. Among these are the operations that check the quality and status of the emerging product. This is exemplified with inspection and test operations in the preliminary taxonomy.

Given the context of this research in the automotive industry some kinds of operations are more in the scope of interest regarding product variety than others. As a first attempt to extend the configurable component concept to the manufacturing system domain, assembly operations will be considered. Much of the product variety for cars is achieved at the final assembly line, which is one of the reasons for this starting point.

5.7.3 Manufacturing assembly operations

To allow reasoning on how to introduce product variants in a manufacturing system model a basic assembly operation will be used as a starting point. The basic assembly operation is illustrated using a simple UML model in Figure 70. The model shows that an assembly operation is a manufacturing operation (i.e. a type or kind of manufacturing operation), which is in agreement with the taxonomy described in the previous section.

Figure 70: Basic model of an assembly operation.

An assembly operation will consume two or more parts. The result or outcome of the assembly operations is a new part that is composed of the parts that have been consumed in the assembly operation. The model also illustrates that an assembly is a part (that is composed of other parts). In many cases one of the consumed parts is what we could call work-in-progress (WIP) or a product in becoming. Since the manufacturing assembly process is supposed to be able to produce several different product variants, there must be some element (or elements) in the model described in Figure 70 that can be varied according to the product variant that will be produced.

Using the final assembly line at a car manufacturer as an example, we can look at one of the so called stations along the assembly line. Standing at the station and observing what is going on, we will observe that different car variants are being worked on almost each and every time a new vehicle comes to the station. A conclusion is that the outcome of the assembly operations performed at a station will be different from time to time. This means that if we want to have a model representation of the object that is the resulting assembly from a station, this object must be able to represent different assemblies from time to time. That is, we must introduce a configurable work-in-progress element. As a consequence of the fact that the outcome of an assembly line station is different from time to time we can also assume that the behavior at the station is different between the assembly variants that are produced at the station. The left part of Figure 71 illustrates this scenario. The bottom part shows that a set of different assembly operation behaviors results in a set of different resulting assembly variants as the outcome. The upper part illustrates the configurable elements representing the operation and the work-in-progress that is introduced with the model proposed in this research work.

Figure 71: Configurable assembly operations and assembly line context.

Both the configurable assembly operation element and the configurable work-in-progress element introduced in the left part of Figure 71 are assumed to utilize most of the mechanisms introduced by the configurable component concept to achieve the required configurability in the context of the manufacturing system model.

The right part of Figure 71 illustrates the basic assembly model put into the context of an assembly line and utilizing the configurable constructs introduced in terms of the configurable assembly operation and a configurable work-in-process element. In the left part of Figure 72 the configurable component concept is shown to be used in two specialized forms: a configurable product component and a configurable process component. The figure further illustrates an intention to make the connection between the two elements through a materialize operation in the configurable product component. Through this approach, a pull-flow through the manufacturing system models will be achieved. The pull-flow and the effects it has on different elements in a manufacturing system model are illustrated in the right part of Figure 72. A request to a configurable product component can through these mechanisms be used to pull the configuration of the manufacturing system model and all the different kinds of resource elements required for this particular product variant.

Figure 72: Manufacturing system model using configurable components.

The approach to manufacturing system modeling described and the inter-linkages between the two types of configurable components (product and process) are still in an early and explorative stage, and more research is required to detail the approach and to validate its appropriateness and capabilities.

5.8 Platform-based product development

5.8.1 Challenges for the automotive engineering design community

The competition in the automotive industry is driving companies to become more and more efficient in parallel with a never ending globalization where more and more actors around the world are joining the competitive race. Using a platform approach to achieve economies of scale has been a commonly adopted approach for quite some time. Furthermore, the need to serve a customer community where the number of market segments are growing while at the same time the number of customers in each segment is shrinking drives the constantly increasing challenge of utilizing common design solutions and parts, while at the same time broadening the customer offer in order to meet more and more individual customer needs. This situation is the topic of paper E, where the starting point is a reflection on how this situation impacts the engineering design community. Figure 73 provides an illustration of the successive shift in focus that has occurred over time for automotive engineering designers.

While an engineering designer in the past could focus on creating optimized individual design solutions for each and every product to be developed, produced, and sold, this scenario has successively become more complicated. While platform-based product development has been applied for quite some time, the more and more globally acting automotive companies are coordinating their product platform to the extent that a platform not only carries several different products but also products of specific brands. Different product and market segments are probably not equally sensitive to brand issues. The whole issue of product brands can not be covered in this thesis and research work. However, it is an observation that has been made that taking care of brand issues in the platform-based product development approach is increasingly becoming an essential factor to consider and account for.

Figure 73: The shift in focus for engineering designers within the automotive industry.

Most cars that are considered to be competing with each other in a market segment probably provide essentially the same set of functions to the customer. This implies that the differentiation between the products is not found through the functions offered by the product. Rather, the competitiveness is achieved through how the functional characteristics are implemented by the engineering designers and how they are perceived by the customer. The implication of this is that the competitiveness in a product will not be found in the large design decisions made during development. Rather, the real competitiveness will come from a larger number of more detailed design decisions that control the more fine-tuned product characteristics which, when well managed and taken together, can form a harmonic whole. Then, if several products from a certain company that share a brand identity are tuned to the same harmony, the brand is strengthened. This is, however, not a straightforward mission to achieve.

5.8.2 Variety, commonality, and design bandwidth

The different products that form the product range of a brand are probably developed on the basis of more than one product platform. This leads to a challenging task of ensuring that the fine-tuned characteristics of the brand are understood in the development of more than one product platform. Furthermore, each of these product platforms most certainly will also be used to deliver derivative products for other brands. This implies that each of the platform development teams must understand the different needs of the brands of the products to be based on the platform. The consequence is that the design solutions of a product platform must provide for both commonality and fine-tuned variety simultaneously. An approach to reasoning about the co-optimization of commonality and variety is presented in paper E. The co-optimization problem is illustrated through the creation of a variant and commonality design space that is illustrated in Figure 74.

The physically possible design space is illustrated by the white region in Figure 74. This physically possible design space is restricted by requirements in a product development program on utilization of common designs and parts as well as on requirements on the product variants (variety) that must be achieved. The design bandwidth is introduced in paper E as a measure of the flexibility (adaptability, mutability, or customizability) that a design solution must provide in order to meet the combined requirements on product variety and platform commonality.

Figure 74: Design bandwidth illustrated in the Variant-Commonality Design Space.

5.8.3 Sources of variety and a development method framework

While the previous sections in this thesis have introduced a number of different concepts that are intended to enable and support the development of platform-based products with a high degree of variety (i.e. product variants) these concepts need to be brought together into one common development method framework. Figure 75 is taken from paper E and presents a framework where an analysis of variable influence factors provides the sources of the required variety. The impacts of these sources are then to be accounted for in the succeeding step of generating design solutions (e.g. using a function-means based approach) as well as in the embodiment of the design solution variants (where the configurable component concept has been proposed in this thesis as an approach to handle this).

Figure 75: Development framework with sources of and embodiment of product variety.

The analysis of the variable influence factors will be used to find the sources of the required variety that will be defined and described through the parameters in the configurable component concept. Through this, a systematic approach to the identification and definition of the required parameterization of the configurable components can be achieved.

5.8.4 An integrated product model framework

Section 4.7.1 described the need to perform a simultaneous solution optimization for the three domains: (1) customer and market; (2) product; and (3) manufacturing. With the purpose of identifying and accommodating appropriate variety and commonality in the design solutions used in product platforms and the derivative products based on the platforms, an integrated framework for product, process, and market definitions is presented in paper G and illustrated in Figure 76. A detailed explanation of the elements of this framework is provided in paper G.

Figure 76: Integrated product model framework

The research work presented in this thesis and the attached papers has illustrated the need for a more systematic and methods based approach to the development of branded products that exhibit a high degree of customer oriented variety while these products at the same time are efficiently developed and manufactured through the utilization of common solutions in design and manufacturing platforms.

Continue ...

Go to table of contents.