Dr Hoda Elmaraghy

Dr Ahmed Deif

Dr Ayman Youssef

Dr Mo- Hamed Hanafy

Dr Mohamed Kashkoush

Dr Mohamed Abbas

Dr Abdulrahman Seleim

Dr Ahmed Marzouk

Dr Javad Navaei

Dr Abdo Al-Zaher

Dr Hamid Tabti

Christian Tönnes

Monika Filiposka

Jean-Philippe Marcon

Philippe Ducreuzot

Jeremy Babron

Khaled Lameche

David Garnier

Je

Marwa Amina Aissani

Saaidia Aroui

Fidèle Aimedee

Roxane Fepeussi

Adel Mekaouche

Akram Chibani

Frough Saïd

Anh Vu Moussavi

Laam Nguyen

Duong Nguyen

Khaled Arrouk

Djily Dang

Oleksii Viun

Nathalie Klement

Adoum Waibaye

Lazher Zaidi

Seifeddine Mejri

Bassem Hichri

Molly

Marélie Karis

Sophie

Carine Marion

Miriam

Anna Laura

Pauline Marc

Keywords: Systems Engineering, Changeable Manufacturing Systems, Design Framework, Design Methodology, Changeability, Reconfigurability, Flexibility Ingénierie Système, Systèmes de Production Changeables, Cadre de conception, Méthodologie de conception, Changeabilité, Reconfigurabilité, Flexibilité

Ce travail de thèse a été mené à l'Institut Pascal, l'University of Windsor (Ontario) et à Faurecia. Son aboutissement est le fruit de quatre années de travail, alimenté et stimulé par de nombreuses interactions avec différents interlocuteurs. Je voudrais rendre hommage à tous ceux qui ont un jour porté leur intérêt sur ces travaux.

Madame Claudia Eckert, Monsieur Pierre Castagna et Monsieur Alain Bernard, je suis reconnaissante des échanges que nous avions eus à différentes étapes de mon avancement. Je suis particulièrement honorée de votre présence dans mon jury de thèse. Je remercie mes différents encadrants pour leur

List of Figures

 [START_REF] Koren | Design of reconfigurable manufacturing systems[END_REF]. . Figure 1.5 Non-functional requirements [START_REF] Firesmith | The method framework for engineering system architectures[END_REF] [START_REF] Bi | Reconfigurable manufacturing systems: the state of the art[END_REF] . . . . . . . . . . . . . . . . . . . . . Figure 2.4 Interactions between product, process & system domains [Rampersad, 1996] . Figure 2.5 Domains influencing manufacturing system design . . . . . . . . . . . . . . . Figure 2.6 Classification of integrated manufacturing system design approaches . . . . . Figure 2.7 Interaction-modeling-based approaches for manufacturing system design . . . Figure 5.17 DSM between system engineering artifacts from example figure 5.16 . . . . . Figure 5.18 MDM between system engineering artifacts from example figure 5.16 . . . . . Figure 5.19 Design for changeability process model . . . . . . . . . . . . . . . . . . . . . . Figure 5.20 Outcomes of design for changeability process . . . . . . . . . . . . . . . . . . Figure 5.21 Extended scenario tree representation [Terkaj et al., 2009b] Introduction "Abandon the urge to simplify everything, to look for formulas and easy answers, and to begin to think multidimensionally, to glory in the mystery and paradoxes of life, not to be dismayed by the multitude of causes and consequences that are inherent in each experienceto appreciate the fact that life is complex."

List of Tables

M. Scott Peck 1.1 Context for manufacturing system design 1.1.1 History and evolution of manufacturing paradigms

The manufacturing of goods goes back to the dawn of time, through a long tradition of handicraft products. The word manufacturing derives from the words manus (hand) and factus (make). Until the Industrial Revolution, craft production remained predominant: the customer would place an order to the producer; the customized product would be created on demand and sold at a high price. A new race for manufacturing, industrial, and economic paradigms was initiated with the industrial revolution (1760 -1830). This period was marked with successive technological breakthroughs (e.g. Watt's steam engine), resulting in new inventions (e.g. machine tools with John Wilkinson, interchangeable pre-manufactured parts with Eli Whitney) and new ways of organizing large factory systems (e.g. division of labor) [Groover, 2007]. Above all, factory electrification influenced the arrival of the new era of mass production in the late nineteenth century, marked by limited product variety, high volumes and low-cost products. There is no doubt that the paradigm was also largely influenced by Taylorism. High-paced production, limited variety, and sequential and specialized tasks were all part of the global production strategy to produce high volumes of products at minimal costs. This initiated the broad industrialization era marked by economy of scale as an initial business strategy. A famous example of the highly limited variety was the success of Henry Ford's Model T car, with the famous quote "any customer can have a car painted any color that he wants so long as it is black". Progress in mechanical, electronic and information technology with computer-based systems has been widely applied for production purposes, still increasing automation in manufacturing systems. In the 80s, mass customization was the trendy new manufacturing paradigm, replacing the mass production paradigm. In addition to large volumes, product options or variants were proposed to customers based on an economy of scope. Customers began to be deciders rather than buyers. Currently, a new personalization paradigm is gaining ground; customers are becoming an integrative part of the development process by influencing the product design (e.g. 'Original Spin' by Levi Strauss). Today's information revolution within industry 4.0 drives this personalization paradigm. Smart factories are becoming agile and highly connected networks, of which customers are a part.

Figure 1.1: Changes in Manufacturing System Paradigms [Koren, 2010] & [START_REF] Boër | Mass Customization and Footwear: Myth, Salvation or Reality? A Comprehensive Analysis of the Adoption of the Mass Customization Paradigm in Footwear, from the Perspective of the EUROShoE (Extended User Oriented Shoe Enterprise) Research Project[END_REF] 1.1.2 Definition of a manufacturing system

No matter what the degree of automation or the type of manufacturing paradigm, the manufacturing function has retained a unique definition. Manufacturing can be modeled as a state transformation from initial materials (i.e. raw materials, parts or set of parts), energy and information to final added-value products, scrap, waste and useful information for surrounding sub-systems (scheduling and control, production planning, maintenance etc.) [Chryssolouris, 2005]. In today's industry, the same manufacturing function is the core of industrial enterprises where material and human resources are coordinated so that the goods can be designed, manufactured and then distributed.

The manufacturing system is usually defined as the organization of resources dedicated to this function in the factory, whereas the manufacturing support systems manage production operations at the enterprise level. Together they form the whole production system as defined in [Groover, 2007]. A manufacturing system is defined at the shop-floor level as a set of equipments (e.g. production machines, tools, material handling technologies positioning devices, but also automation and control technologies) and human resources performing a set of manufacturing operations (i.e. processing, assembly, material handling and storage, inspection and testing, control) with products moving through them. [START_REF] Elmaraghy | [END_REF] and [START_REF] Pujo | Concepts fondamentaux du pilotage des systèmes de production[END_REF]. The present work focuses on manufacturing systems at shop-floor levels as illustrated in figure 1.2b. A physical manufacturing system is thus composed of three levels: a machine/station/equipment level, a cell or sub-system level, and a system level [START_REF] Scholz-Reiter | Autonomous Processes in Assembly Systems[END_REF]. Manufacturing system components can be of different types: informational or material, static or flow.

Boundary of the manufacturing system design problem

The principal mission of a manufacturing system is the production of a type of product, namely a product family, for a given volume demand. The production context can be enriched by the variability and uncertainty of volume and product variety. Strategic decision (company strategy, market uncertainty, technological variability) and availability of resources are other important context elements that influence manufacturing system design. Since a manufacturing system is first and foremost designed for a manufacturing mission, the most influential activities are illustrated in figure 1.3. The activities preceding manufacturing system design are product design (the specifications can be encompassed by a liaison graph, a tree matrix, 3D models or Engineering Bill Of Materials (EBOM)) and process planning, which results in the sequence of manufacturing operations to be performed. Figure 1.3 shows two cases; either the system exists and the process plan is allocated to existing resources, or it does not exist and the process plan is preliminary data input for system design. This scheme reveals that the manufacturing system domain greatly depends on the process plan and product design activities. However, today's production context raises the question of the boundaries of manufacturing system design approaches. Products are more complex, becoming smart, connected, and serviceoriented resulting in a product-system perspective. In addition to technological breakthroughs, current production paradigms (mass customization and personalization) require the launch of products with a short lifecycle and high degree of personalization. Due to globalization, fierce international competition creates a fluctuating and unpredictable market demand. Changing needs and change propagation have revealed how interconnected the traditionally segmented design domains are. The phenomenon is particularly complex with the set of suppliers involved in the design process, as customers propagate order variability to manufacturing suppliers and so on.

Product design

Usually, a first-step strategy is to reinforce communication between them for better variability forecasting. This has particularly motivated authors to study co-design and co-development methods for products, production processes and manufacturing systems [Algeddawy and ElMaraghy, 2010]. The correlation between the three domains has been pointed out in preliminary work [Benkamoun et al., 2013a] through a classification of approaches which treats them either separately or together. But in the author's opinion, reductionist approaches aiming to decrease the source of complexity are in this context insufficient. Manufacturing systems should first and foremost be responsible for coping with highly changeable production contexts. This is why the scope of this work excludes the product design domain and focuses on designing system capabilities to respond to change. Product design specifications and the related production context are merely taken as input for the design problem; the process plan can become more detailed or even called into question during the system design phase.

Changeable manufacturing system paradigms

To cope with a highly changing context, manufacturing systems must be adaptable to varying market demands at an operational level. Several manufacturing paradigms which have appeared concurrently with the era of more product differentiation and customization (see figure 1.1) are described below.

Flexible Manufacturing Systems & Reconfigurable Manufacturing Systems

Manufacturing systems first evolved from Dedicated Manufacturing System (DMS) to Flexible Manufacturing System (FMS) able to manufacture more varieties of products in a pre-defined scope at lower volumes. FMS offers built-in generalized flexibility, within pre-defined boundaries [ElMaraghy and [START_REF] Elmaraghy | [END_REF]. A recurrent criticism of FMS is their restricted ability to manufacture part or product variety. Flexibility is built-in a priori, meaning that regarding changes, FMS might also have unused capabilities. The FMS paradigm has also been acknowledged as being inefficient regarding dynamic and uncertain changes in the production context since FMS -like DMS -has static capabilities. The product family is fixed once for all at the outset of FMS design. FMS is definitely not designed for important market changes.

With the requirement for adaptive, reactive and reusable systems, the paradigm of Reconfigurable Manufacturing System (RMS) was proposed in the nineties by [START_REF] Koren | Reconfigurable manufacturing systems[END_REF]. Koren defined the concept of reconfigurability at the system level as the ability of the manufacturing or assembly system to adjust, reactively, easily and quickly, the production capacity and functionality by rearranging or changing structure components to form new system configurations. A configuration can be physical (layout, machines, material handling devices, machine elements) or logical (rerouting, rescheduling, replanning, reprogramming) [START_REF] Elmaraghy | Flexible and reconfigurable manufacturing systems paradigms[END_REF]. To this end, the system has enablers to acquire flexibility through re-configuration phases as needed, when needed. One configuration includes the exact required capabilities for the present context, and changeability options to make the system adaptive to new production contexts. Reconfigurability has therefore the potential to prolong the production system lifecycle through rearrangement and reuse [START_REF] Mehrabi | Reconfigurable manufacturing systems : Key to future manufacturing[END_REF].

In that sense, a RMS is a manufacturing system able to acquire customized flexibility on demand through re-configuration phases, whereas an FMS encompasses built-in, a priori and generalized flexibility that cannot be adapted through production context changes [ElMaraghy, 2009]. Figure 1.4 illustrates the RMS capability to dynamically adapt its functionality, whereas DMS and FMS have static capabilities for a different variety scope. [START_REF] Koren | Design of reconfigurable manufacturing systems[END_REF]

Dedicated

Changeable Manufacturing Systems

Deciding between flexibility and reconfigurability paradigms is a question of strategy regarding the predicted future context evolution. Both relate to different types of investment; reconfigurability means investing in reconfigurability enablers, and flexibility is about purchasing more flexibility than the amount strictly required by the present production problem [Tolio, 2009]. The decision is therefore context-dependent. Moreover, the complexity of manufacturing systems creates different degrees of flexibility and reconfigurability that co-exist within a same architecture. The distinction between them is not always as clear as the theory. That is why the general term "changeable manufacturing systems" has been introduced as an umbrella concept encompassing FMS and RMS paradigms [START_REF] Wiendahl | Changeable Manufacturing -Classification, Design and Operation[END_REF]. In the same manner, the present work refers to changeable manufacturing systems. Changeability is simply defined as the degree to which a system is able to adapt to changing circumstances, regardless of the strategy used to achieve it (flexibility or reconfigurability) [Benkamoun et al., 2015b].

1.2 A systemic approach for manufacturing system design 1.2.1 Sources of complexity in systems A complex system is a common notion that refers to engineers' difficulties to fully understand, model and simulate a system. The word "system" actually suggests a complex object, since it is composed of related sub-systems which are in turn decomposed at a finer analysis level, to end with elementary elements [START_REF] Pujo | Concepts fondamentaux du pilotage des systèmes de production[END_REF]. These elements interact to achieve a stated purpose for the system within an external system boundary. The complexity of a product or system is due to different reasons, leading to various definitions of complexity in the literature. [START_REF] Elmaraghy | Complexity in engineering design and manufacturing[END_REF] summarize four causes for complexity: size, coupling, variety and multidisciplinary. Size refers to the instinctive idea that too many elements cannot be easily managed. As such, computational complexity theory in computer science refers to the quantity of resources required to solve a computational problem. From the second axiom of axiomatic design [Suh, 1998], the amount of information inherent within a system characterizes its complexity. In order to reduce system complexity, [START_REF] Fricke | Design for changeability (DfC): Principles to enable changes in systems throughout their entire lifecycle[END_REF] suggests actions to reduce design information: minimize the number of interfaces, minimize the number of secondary functions, reduce and focus on existing resources. Coupled dependencies is another major factor of complexity. Non-linear interactions among components can exhibit a degree of disorderly behavior, following the example of the entropy principle [START_REF] Elmaraghy | Complexity in engineering design and manufacturing[END_REF]. But connectivity complexity is necessary to describe products in terms of components and relations [START_REF] Jarratt | Engineering change: an overview and perspective on the literature[END_REF]]. Since a system requires interconnections between system elements to exist and ensure system performances, this makes total decomposition and decoupling impossible. Product families also induce dependencies between system variants sharing common modules with the product platform. The delimitation between variability and commonality can give rise to complexity in configuration management. In socio-technical systems, complexity propagates through different domains, as for instance in system engineering design: requirements, function and structural form [START_REF] Uddin | Complex product architecture analysis using an integrated approach[END_REF]. It is emphasized by the high number of stakeholders, actors and customers. In addition to some static definitions of complexity, dynamic complexity arises from feedback, time delays, non-linearity, stocks and flows [Sterman, 2001]. System dynamics modeling is useful to enhance learning in complex systems, whereas static and reductionist approaches are limited. The constant evolution of the system environment intensifies the complexity of systems acting in unpredictable ways during the system lifecycle. Accordingly, the changeability paradigm increases the perceived complexity of designers who would naturally prefer to ignore it. The present work on changeability argues for anticipating, preventing and facing future complexity resulting from changing environments.

Complex design problem

Irrelevancy of segmented approaches for manufacturing system design Interrelated design activities contribute to a consistent synthesis of manufacturing systems, although it is quite common in manufacturing system literature to restrict design to segmented sub-problems (e.g. resource planning, selection of equipment, layout configuration, distribution of operations among stations, assignment of resources or line balancing as possible sub-activities of a system design process). Nevertheless, the dilemma has often been raised in the community of the infeasibility of restricted design problems versus the need for the quantifiable verification of design solutions. It tends to reveal the gap between industrial needs and academic research. All of these reasons have led practitioners and researchers to adopt holistic views to tackle the manufacturing system design process; it leads to the integration of multiple domains, such as robotic engineer, logistic engineer, ergonomic engineer, automation experts, scheduling and control engineer and process planner.

Ill-defined & open-ended design problem

Design is a process aiming to construct the description of artifacts that will -together or alone -satisfy requirements, performance criteria and constraints. The German school systematic approach of [START_REF] Pahl | Engineering design: a systematic approach[END_REF] prescribes four stages in a design process: clarification of the task, conceptual design to choose the solution principle, embodiment design and detail design. Analogously, [START_REF] Ueda | Emergent synthesis methodologies for manufacturing[END_REF] distinguishes three kinds of problems that have to be treated differently: problems with a complete environment description and complete system specification (class I), problems with an incomplete environment description (class II) and problems with both an incomplete environment description and an incomplete system specification (class III). In these design problem taxonomies, approaches acknowledge the presence of incomplete and uncertain information about the system to be designed in the preliminary design phases (class III). The variety of input data from complex production contexts makes the design problem ill-defined and incomplete in the formulation of the need. Moreover, design projects often begin with ill-defined problems in the preliminary design phase. This preliminary design phase is decisive for the rest of the design process and for the final product itself. It has been recognized that 80% of the resources necessary to design a product are committed by decisions taken in the first 10% of the design activity [START_REF] Hague | Tool for the Management of Concurrent Conceptual Engineering Design[END_REF]]. Paradoxically, although the decisions made during conceptual design are critical and highly determinant, there is little support for these conceptual design phases. [START_REF] Wang | Collaborative conceptual design -state of the art and future trends[END_REF] reveals the scarcity of computer-assisted tools during the conceptual design stages, unlike the profusion of Computer Assisted Design (CAD) tools used for the subsequent quantitative and more detailed design phases. This statement is also true for the manufacturing systems area. The design process is critical at the conceptual stage, where the problem is complex to understand and define. Design approaches are open-ended, meaning that the goal is to find a satisfying solution. This is contrary to optimization approaches, in which the problem is completely modeled and looks for the best solution. Rare are the manufacturing system design approaches in the literature that start with the conceptual stage. The required knowledge about the design problem is often at a detailed or restricted level (e.g. type of workstation, type of process, type of equipment, type of layout).

Research domains for system engineering design methodology

Let us now consider the research domain of engineering design for complex systems. To cope with the design of complex systems and complex design problems, standards have been proposed to organize the different phases which products or delivery systems go through during their lifecycle. In the System Life Cycle standard [ISO/IEC/IEEE 15288, 2015], the successive phases are: concept stage (or pre-acquisition phase), development stage (or acquisition phase), production stage, utilization stage, support stage and retirement stage. The consideration of the entire system lifecycle, and not only on the product during the acquisition phase, testifies to the systemic view in designing system capabilities. The design problem is focused on at the development stage. This phase has been covered by design standards and models [ANSI/EIA 632, 2003], [IEEE 1220[IEEE , 2005]], [START_REF] Vdi | Systematic approach to the development and design of technical systems and products[END_REF][START_REF] Vdi | Systematic approach to the development and design of technical systems and products[END_REF], [MIL-STD-499B, 1969]. Design methodologies commonly adopt a top-down approach in engineering design, with a systematic scheme to reduce the apparent complexity. [ANSI/EIA 632, 2003] suggests a four-layer representation of end-products: system, subsystem, assembly and components. Design goes through a breaking-down process from an initial system level; the stopping criterion would be a sufficient level for a complete understanding of the system's structure.

Aside from these industrial standards, the field of Design Theory and Methodology (DTM) [El-Maraghy et al., 1989] has welcomed a large number of research approaches. [START_REF] Tomiyama | Design methodologies: Industrial and educational applications[END_REF] classifies them according to various criteria: general versus individual (independent or specific to a product class) and abstract versus concrete (theoretical or concrete prescriptions). Among the most formalized and frequently-used design methodologies for complex design problems, Systems Engineering has emerged over the last half-century and has been promoted by the International Council on Systems Engineering (INCOSE) organization (www.incose.org) (Association Française d'Ingénierie Système (AFIS) in France www.afis.fr). Coming from military engineering practices (e.g. the DodAF and MODAF framework) and aerospace sector (NASA), systems engineering practices have been disseminated to different industrial sectors in which designing complex products is a challenge (e.g. rail, avionics and automobile sectors). Systems engineering subscribes to design methodologies; it is general and concrete. The official definition of systems engineering according to is "an engineering discipline whose responsibility is creating and executing an interdisciplinary process to ensure that the customer and stakeholder's needs are satisfied in a high quality, trustworthy, cost efficient and schedule compliant manner throughout a system's entire life cycle. [...] It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem". In order to enlarge the scope of design to a holistic perspective with integrated viewpoints, this work subscribes to the Systems Engineering discipline. Applied to manufacturing systems, this research approach is at a crossroads between industrial domain-dependent activities and system engineering design methodologies and practices.

Challenges for a changeable systems design methodology 1.3.1 Designing changeability as a lifecycle system engineering property

Changeability is not specific to manufacturing systems, but can be applied to any system. In the discipline of system engineering design, the evolution of large-scale complex systems over a long lifetime has prompted designers to study lifecycle system properties [De Weck et al., 2011a]. These critical lifecycle system properties are referred as "ilities"; they are system properties that help to preserve value delivery during the system's lifecycle [START_REF] Ross | Defining changeability: Reconciling flexibility, adaptability, scalability, modifiability, and robustness for maintaining system lifecycle value[END_REF]]. These desired system properties, such as flexibility or maintainability, often manifest themselves once the system has initially been put to use. Changeability subscribes to this line since it characterizes the capability for coping with change at any time during the system lifecycle. The virtuous circle is such that changeability extends the system lifecycle toward changing contexts. Changeability is however not an absolute concept, but a relative one. System A will be more changeable than system B if it is faster and less costly to adapt to change requests.

From a design perspective, these properties are particularly difficult to implement, since they are not primary functional requirements satisfied by an independent solution. Some works call them "non-functional requirements" or "quality requirements", as they describe how the system "should be", rather than how it "should do" through functional requirements. Some examples from the architecture software domain with the method framework for engineering system architectures (MFESA) [START_REF] Firesmith | The method framework for engineering system architectures[END_REF] are illustrated figure 1.5. The main difficulty of designing lifecycle properties is their impact on the whole system architecture, making systemic approaches necessary. Direct design becomes impossible, and verification difficult. Whereas functional requirements can be directly mapped to allocated elements, non-functional requirements or quality requirements concern the overall system. A complete analysis of the system's complexity and its interactions is thus necessary to evaluate the impact of changeability on system elements and interfaces. Whilst a significant effort of definition has been made (robustness, scalability, flexibility, maintainability, survivability, versatility, changeability), design methodologies hardly support analysis and synthesis of these properties at the correct levels in complex systems [START_REF] Mcmanus | A Framework for Incorporating "ilities" in Tradespace Studies[END_REF].

Designing changeability means understanding change propagation in already complex systems. It causes a multiplication of the perceived complexity in design projects which will be more difficult to perform than current stand-alone projects. This actually explains the scarcity of design approaches for changeability in research, even less applied in industry. Nevertheless, it has been recognized that design for changeability or reconfigurability should be done at the outset [START_REF] Koren | Design of reconfigurable manufacturing systems[END_REF]. Because early design phases offer greater leeway for implementing successful changeability solutions, system engineering approaches are applied to support design from the early conceptual phases. In addition, designing changeability requires an estimation of likely future changes in order to avoid extra-capability that would be unused, unprofitable and unjustified economically speaking. It means anticipating what type of variability is likely to occur in the future, cost analysis, and consequences in the need for changeability, without restricting the design problem to a stand-alone engineering problem. Design should be systemic at the project scale, but also at the time scale. Figure 1.5: Non-functional requirements [START_REF] Firesmith | The method framework for engineering system architectures[END_REF]

Type of design support

A design problem is comparable to any other problem to solve. Assuming the delivery system is a solution to a problem, any design-solving approach can be composed of a problem domain (i.e. analysis of the problem definition), and a solution domain (i.e. synthesis of functional concepts into physical solutions). The transformation from the functional to the physical domain is the core of the design process, resulting in the definition of a physical system that meets problem requirements. However, the mapping from the problem domain to the solution domain is not always straightforward, due to the complexity of the problem and the solution system. The design process must be refined into different viewpoints, guidelines, steps, milestones and deliveries to support designers. To this end, different types of support for the design process exist, ranging from abstract frameworks, process models, methods and design tools to detailed parametric computer tools. This variety indicates how different the needs for design supports can be. For instance, architectural frameworks and process models are applied to wide-ranging design problems with a multitude of viewpoints to consider, whilst methods and tools are applied to detailed and quantified problems. As far as manufacturing systems are concerned, even though a plethora of design theories, frameworks and methodologies exist in the literature, none is satisfactory for supporting the complex design of those large-scale systems, and even less those required to be changeable. The expected contribution of the current research is a methodology that must systematize process models, sets of principles, formalisms and tool prescriptions to guide changeable manufacturing system design projects.

Initial motivations

The fundamental motivation of this work is to embrace the complexity induced by changeable manufacturing systems during their design project lifecycle, from the very first stages of any design project and prior to any segmentation of design sub-problems. The relevancy for reconfigurable and flexible manufacturing system paradigms is well established regarding fluctuating and uncertain production contexts, but the manner of designing them is still an open question. This research work treats design differently from the classical approaches. It is highly inter-disciplinary, since it aims to integrate the manufacturing system domain with the systems engineering and DTM domains. Based on the premise that changeable manufacturing systems fall under the definition of complex systems regarding size, dependencies, variety of configurations, multi-disciplinarity and dynamic changes, the needs for design methodology are summarized hereinafter:

1. The design problem should be treated from high-level objectives to detailed ones, namely from the conceptual phase 2. Simplistic assumptions prevent design methods from fitting real complex industrial problems 3. A holistic approach leads to better system performances than an emphasis on segmented individual problems 4. A satisfactory solution, rather than an optimal one, is sufficient for a complex problem These statements emphasize the purpose of this work: the proposal of a systemic methodology to support the design of complex and changeable manufacturing systems throughout the system and project life-cycles.

Outline of the manuscript

This document is logically organized around different research themes: manufacturing systems, system engineering design, changeability and embodiment type for design support. Figure 1.6 illustrates the outline of the manuscript. The state of the art in Chapter 2 links and cross-references design approaches from the manufacturing system domain to those of the systems engineering domain. Resulting from the analysis of research gaps, the research scope is presented in Chapter 3. The preliminary contribution offers a system engineering formalism for representing changeable systems in Chapter 4. Chapter 5 leads to the core of this research, namely a systemic design methodology for changeable manufacturing systems. Each part is illustrated by mini cases-studies and industrial illustrations. Chapter 6 validates the methodological concepts with the study of complex design projects from an automotive supplier company through different periods of time. A benchmark is given to compare the proposed methodology with classical design approaches. To conclude, Chapter 7 gives perspectives in suggesting future embodiment of the methodology in a semi-automatized support tool. Literature review "You don't fight for a 'new system'. You create something that makes the old system obsolete"

Introduction

Introduction

The trendy interest for designing Changeable Manufacturing Systems comes from the current production context marked by frequent, variable and uncertain changes. Because changes in manufacturing system design projects are being carried out much more frequently than before, traditional rigid design approaches coping with static demand and only focusing on performance improvements become obsolete. Needs for adaptation, agility and re-usability make the changeable manufacturing system paradigm a priority for industry so it can respond to highly changing contexts. Changeability increases the perceived complexity of manufacturing systems, but its design process is as much or more complex. Based on the initial motivations presented in the introduction (see section 1.

Changes in manufacturing system domain

In the current market context characterized by high product variety (functional variety with customer satisfaction and technical variety with manufacturability) and variable volumes, manufacturing systems must adapt to changing requirements. Moreover, the global competition requires the launch of products with shorter life-cycles in development and operation phases. In order to be sustainable, a manufacturing system lifecycle has to cover several product life-cycles. The context surrounding manufacturing systems is quite complex and brings difficulties for systems to absorb and even anticipate change propagation. This section reviews how the manufacturing system literature tackles the problem of changes and changeability; it then results in motivations for systemic analysis of changeable manufacturing systems addressed in the last section 2.1.6.

Changeable manufacturing system paradigms

Faced with the need to be responsive regarding change (e.g. product variety, process variety, fluctuation of production volumes), different manufacturing system paradigms have been developed. In the manufacturing system domain, flexibility and reconfigurability are common paradigms coping with change: the system either offers pre-built, static and immediately operational capabilities (i.e. flexibility) or the system gets a structural ability to dynamically go through new configurations (i.e. reconfigurability). These two main strategies are detailed and compared together hereinafter.

Flexible Manufacturing Systems [START_REF] Groover | Introduction to manufacturing systems[END_REF] characterizes manufacturing systems according to its degree to deal with product variety. With no product variety, a single-type model is designed for highest efficiency and composed of specialized equipments. A batch-model is meant for hard product variety (i.e. products differ substantially) in interrupting production with change-over in physical setup and/or equipment programming. A mixed-model system continuously produces a certain level of variation of products (i.e. small differences due to many common parts) with relatively short time for changeover (e.g. fixturing and tooling). FMS belong to this last category; they deal with immediate product variety through quick changeover of operation setup and hardware. Structurally, an FMS is defined as an "highly automated Group Technology (GT) machine cell, consisting of a group of processing workstations (Computer Numerical Control (CNC) machines), connected by an automated material handling and storage system, under the control of a distributed computer system" [Groover, 2008a]. [START_REF] Elmaraghy | Flexible and reconfigurable manufacturing systems paradigms[END_REF] presents various domains for flexibility such as machines, material handling, operations, processes, products, routing, production volume, expansion of capacities and/or capabilities, machine and system control, and production volume. FMS offer built-in and generalized flexibility within pre-defined boundaries [ElMaraghy and [START_REF] Elmaraghy | [END_REF], but all FMS do not have the same level of flexibility as they do not cope with the same range of variety. For classification purpose, [Groover, 2008a] differentiates the "dedicated FMS" composed of machines with specific processes from the "random-order FMS" composed of general purpose machines able to process parts in various sequences. In the same way, [Tolio, 2009] differentiates FMS with generalized -often excessive and unused -flexibility from Focused Flexible Manufacturing System (FFMS) having the right level of flexibility. The crucial point in design remains to find the best trade off between productivity and flexibility.

Reconfigurable Manufacturing Systems FMS are not designed for important market changes. The need of system responsiveness regarding the uncertain fluctuation of product variety and volumes has induced the idea of a dynamic system capable of evolving over time and circumstances. Investing in generalized and static flexibility may be risky when variability is unforeseeable, investing in system ability to change its behavior through new configurations can rather be a better strategy [Tolio, 2009]. [START_REF] Koren | Reconfigurable manufacturing systems[END_REF] have defined the concept of reconfigurability at the system level in offering the ability of the manufacturing or assembly system to adjust reactively, easily and quickly the production capacity and functionality by rearranging or changing structure components. Whilst FMS have static configurations, reconfigurability refers to the operating ability to switch with minimal effort, cost and delay to a new configuration [START_REF] Wiendahl | Changeable Manufacturing -Classification, Design and Operation[END_REF]. Its capacity and functionality are not fixed. In doing so, the system relies on enablers to acquire the flexibility as needed, when needed [START_REF] Mehrabi | Reconfigurable manufacturing systems : Key to future manufacturing[END_REF]. [START_REF] Koren | Design of reconfigurable manufacturing systems[END_REF] define key-enablers for RMS: customization, convertibility, scalability, modularity, integrability, diagnosability. Changeable manufacturing systems definition Some differentiate FMS from RMS based on the existence or the lack of structural change [START_REF] Groover | Introduction to manufacturing systems[END_REF], and others on the pre-built capability to cope with change [ElMaraghy and [START_REF] Elmaraghy | [END_REF]. Those criteria are not necessarily discriminating since FMS can also undergo structural changes (change-over, set-up) and RMS have pre-built capability to cope with change (i.e. reconfigurability enablers). For instance, the Festo Didactic transformable iFactory R [Festo-Didactic, 2012] goes through several configurations due to its modular structure. Its levels of flexibility depend on the effort that must be performed in going from a configuration to an other. If the software pre-registers operational configurations, then it is a flexible system. If extra design efforts must be performed in using reconfigurability enablers, then it falls into the RMS category [START_REF] Elmaraghy | Product variety management[END_REF]. [Terkaj et al., 2009a] state that both paradigms deal with modifications in manufacturing systems and the differences consist in timing, cost and number of steps necessary to implement a modification. They present a ladder for flexibility levels: the top level relates to a fully operational configuration and the lower levels to the steps that should be performed to achieve it. Due to the difficulty to define general statements for classifying FMS and RMS, [START_REF] Wiendahl | Changeable Manufacturing -Classification, Design and Operation[END_REF] define changeability as an umbrella concept including reconfigurability and flexibility paradigms.

Comparison

In order to avoid confusion between RMS and FMS terms, [START_REF] Järvenpää | Adaptation of Manufacturing Systems in Dynamic Environment Based on Capability Description Method[END_REF] uses the expression "adaptation of manufacturing system". A review of other terms used in engineering design domains is presented in section 2.3.2. In this research work, changeability is precisely defined as the system ability to adapt to changing circumstances, regardless of the strategy used to achieve it [Benkamoun et al., 2015b].

Changeable manufacturing system lifecycle

Any changeable manufacturing system undergoes changes or re-configuration phases to achieve new functions, extending in turn its life and utility. As a result, changeable manufacturing systems have specific lifecycle models which are different from traditional manufacturing systems. Initially, the green-field system design is performed (including modeling, analysis, simulation on digital mockup, validation), then comes implementation/realization, operation and maintenance. The market monitoring evaluates needs for change [Koren and Ulsoy, 2002], and if necessary, new requirements launch the redesign/reconfiguration phases (also called brown-field projects) for hardware and software systems (see figure 2.2). Because designing changeability is equivalent to designing any quality, [START_REF] Wiendahl | Changeable Manufacturing -Classification, Design and Operation[END_REF] prescribe the following generic design stages within the "design and implementation of changeability phase": definition of requirements, performance comparison and continuous adaptation. When change occurs, they suggest an additional "performance of the change phase" composed of planning, training and implementation of the changeover. In [START_REF] Bi | Reconfigurable manufacturing systems: the state of the art[END_REF] the "configuration design phase" implies that system components and their interactions are preliminary determined during the "architecture design phase". Then, the "control design phase" determines the process variables for operating the configuration (see figure 2.3). "Architecture design phase" is equivalent to "design of changeability phase", and "configuration design phase" to "redesign phase" with in addition, a modular representation of changeability possibilities. It actually refers to the modular definition of product variants formed by a combination of modules (i.e. configuration), themselves defined in the product platform (i.e. architecture). In the same way, [START_REF] Hofer | The potential of layout platforms for modular complex products and systems[END_REF] opposes direct design (determination of a modular architecture from scratch) from indirect design (task-oriented determination of a modular system configuration from a set of existing modules). The state of the art for the two phases is respectively detailed in sections 2.1.3 & 2.1.4.

Design for changeability

As soon as the RMS paradigm was introduced in the nineties, the importance of designing reconfigurability from the outset was emphasized by [START_REF] Koren | Reconfigurable manufacturing systems[END_REF]. Until today, although the RMS literature is very broad regarding reconfigurability characteristics and RMS definitions, limited attention is given to the involvement of reconfigurability knowledge in the design process [Deif andElMaraghy, 2006] [Rösiö, 2012]. Intensive works focus on enablers, with for instance methodologies for modular manufacturing systems [Tsukune et al., 1993] [Rogers and[START_REF] Rogers | [END_REF]. But no other systemic methodology than the lifecycle framework presented in section 2.1.2 was proposed in the manufacturing system literature.

Design of configuration

Most of the RMS design approaches focus on configuration design. They are reviewed under different classification criteria: requirements for a new configuration, criteria for configuration selection and evolution of demand through re-configurations.

Requirements for re-configuration The conditions to enter in a re-configuration phase regarding product evolution should firstly be defined. A new configuration relates to a change of product or production capacity [Koren and Ulsoy, 2002]. A new selection of system configuration can be associated with a single product in a single product-line [Son, 2000] or with a specific product mix and volume requirements in case of a mixed product-line [START_REF] Youssef | Optimal configuration selection for Reconfigurable Manufacturing Systems[END_REF]. With mixed product lines, grouping products is essential to enabling the production of a mix of products in the same line. Grouping products into product family according to some commonality and modularity criteria [Fixson, 2007] has the advantage of making the system robust to mixed-variety fluctuation. Some methods roughly associate product families with each configuration [START_REF] Xiaobo | A stochastic model of a reconfigurable manufacturing system[END_REF], whereas others select a set of product variants within a family for each configuration [START_REF] Youssef | Optimal configuration selection for Reconfigurable Manufacturing Systems[END_REF]. Based on their commonalities, [START_REF] Bryan | Co-Evolution of Product Families and Assembly Systems[END_REF] selects common product variants and maps them to specific configurations.

Criteria for configuration selection

The most common evaluation criteria to select configurations are: throughput, investment cost, floor space and system quality [Koren andShpitalni, 2010] [Hu et al., 2011]. Like non-changeable standard manufacturing systems, configurations are usually chosen for a fixed demand. The assumption is, implicitly or explicitly, that the reconfiguration scenario will occur in a long period of time (10 -15 years) which prevents designers from anticipating future production contexts. Still, short-terms flexibility regarding the product variety within the fixed demand can be another evaluation criteria [Webbink andHu, 2005] [Koren andShpitalni, 2010]. [START_REF] Hu | Assembly system design and operations for product variety[END_REF] differentiate flexibility criteria in volume (scalability criteria) from flexibility criteria in functionality (convertibility criteria). On the contrary, some approaches embrace the reconfigurability perspective in order to find optimal re-configuration scenarios between several demands regarding cost, time and effort. [START_REF] Youssef | Assessment of manufacturing systems reconfiguration smoothness[END_REF]] criticize the general tendency in RMS configuration design literature to neglect the effect of configuration selection on smoothness and easiness of the reconfiguration process and thus propose the metric Reconfiguration Smoothness (RS). From an established machine sequence, [Lee, 1997] select system configurations using some designed rules so that the reconfiguration and relocation costs are reduced. [START_REF] Bryan | Co-Evolution of Product Families and Assembly Systems[END_REF] add the reuse quality needed in reconfiguration processes.

Evolution of demand along re-configuration Among the configuration design approaches using reconfiguration criteria, the evolution of the production context causing requirements for new configurations is modeled in different manners. [START_REF] Youssef | Optimal configuration selection for Reconfigurable Manufacturing Systems[END_REF] distinguish deterministic evolution in demand [Son, 2000] [Bryan et al., 2007] [ElMaraghy and Youssef, 2008] [Spicer et al., 2002] from stochastic evolution [Youssef andElMaraghy, 2007] [Xiaobo et al., 2000]. Some approaches are reactive to the context's evolution in focusing on one period at a time [Xiaobo et al., 2000] [ElMaraghy and[START_REF] Elmaraghy | [END_REF]. Others are pro-active as they forecast the future reconfiguration scenarios and design the current ones in easing future transitions [Son, 2000] [Youssef andElMaraghy, 2007]. Finally, the co-design approaches act on the production context evolution in selecting products and configurations together [START_REF] Bryan | Co-Evolution of Product Families and Assembly Systems[END_REF]] [Algeddawy and ElMaraghy, 2010] [AlGeddawy, 2011].

Domains for system configuration

General definition domain Because of the usual segmentation between physical arrangement problems and logical problems in manufacturing system design, a configuration is defined most of the time as a physical arrangement of machines or stations. Some authors define a system configuration as an arrangement of machines/workstations with special relations/connections [START_REF] Hu | Assembly system design and operations for product variety[END_REF]. In some cases the complexity of physical configurations is limited by characterizing them with the number of stages and the number of identical machines/stations in parallel for each stage [START_REF] Tang | Concurrent Line-Balancing , Equipment Selection And Throughput Analysis For Multi-Part Optimal Line Design[END_REF]] [Bryan et al., 2007] [Ko and Jack Hu, 2009].

Plenty of taxonomies aiming to classify the various physical configuration types exist in the literature. [START_REF] Elmaraghy | Flexible and reconfigurable manufacturing systems paradigms[END_REF] formalizes a layout configuration code with four criteria listed in table 2.2: shape, segment flow direction, flow control and flow control junction. U-shaped lines enable more homogeneous workloads between stations. The number of operators supervising the line is reduced and the feeding is made at the exterior of the line. Coping with the variability of volume, flow lines with identical parallel stations and made of identical operation assignments become popular for scalable layout choices [START_REF] Youssef | Optimal configuration selection for Reconfigurable Manufacturing Systems[END_REF]. Designers prefer synchronous systems with symmetrical configurations in machining applications, but in assembly applications they consider asynchronous systems and complex configurations dealing with complex assemblies [Ko and Jack Hu, 2008]. The concept of delayed product differentiation copes with the product family paradigm and its changeability for customization purposes. It exploits the commonality between sub-assemblies and results in a production process delaying the points of product differentiation.

Layout characteristics Attributes Shape

Line, U-shaped, Loop, Network Segment Flow Direction Uni-direction, Bi-directional Segment Flow Control Synchronous, Asynchronous Flow Control Junction One-to-One, One-to-Many or Many-to-One Table 2.2: Layout configuration characteristics [START_REF] Elmaraghy | Flexible and reconfigurable manufacturing systems paradigms[END_REF] Changeability makes obsolete segmented design domains The variability of production demand causes complex physical configurations that in turn impact Line Balancing (LB) problems (also called logical layout). LB problems are: Single Assembly Line Balancing (SALB) in which each block performs one operation in a rigid single product line configuration, Mixed-model Assembly Line Balancing (MALB) with intermixed sequences of product variants and Generalized Assembly Line Balancing (GALB) with the generalization of various assumptions from preceding problems. LB depends on few hypothesis that considerably influence complexity: the type of layout and product homogeneity. Regarding product variety and homogeneity in the production line, [START_REF] Boysen | A classification of assembly line balancing problems[END_REF] consider different kinds of lines in the balancing problem (see table 2.3). In the majority of cases, designers prefer single product lines to solve balancing problems [START_REF] Hu | Assembly system design and operations for product variety[END_REF]. Although simple layouts like serial lines or U-shaped lines are generally used in balancing and re-balancing problems [START_REF] Boysen | A classification of assembly line balancing problems[END_REF], [START_REF] Algeddawy | Design of single assembly line for the delayed differentiation of product variants[END_REF] reveal the lack of integration between complex layout for delayed product differentiation strategies and balancing problems.

Kind of product line Characteristics

Mixed-model line Several models are manufactured on a same production system Multi-model line Batches for specified products are launched with setup between Single product line It can also be a mutli-product line with products almost identical Table 2.3: Line Balancing problems classification [START_REF] Boysen | A classification of assembly line balancing problems[END_REF] Critical analysis of segmented approaches: toward enlarged domains Because of change and complexity propagation from physical configurations to logical problems, few approaches have emerged arguing for enlarging configuration domains as reported in [Benkamoun et al., 2013a]. They intend to go beyond one single view of configuration (e.g. the physical arrangement of standardized RMS workstations or standardized reconfigurable manufacturing tools [START_REF] Youssef | Optimal configuration selection for Reconfigurable Manufacturing Systems[END_REF]). [START_REF] Tang | Concurrent Line-Balancing , Equipment Selection And Throughput Analysis For Multi-Part Optimal Line Design[END_REF] integrate LB with equipment selection problems. [START_REF] Algeddawy | Design of single assembly line for the delayed differentiation of product variants[END_REF] combine layout design, assembly sequencing, task assignment and decisions about station locations. [START_REF] Youssef | Optimal configuration selection for Reconfigurable Manufacturing Systems[END_REF] redefine configuration as an arrangement of machines, equipment selection and operation assignments. Configuration design can therefore be presented under two domains: physical (arrangement of stations/machines) and logical (assignment of operations to resources). Focusing on layout, [Delchambre, 1996] divides Line Layout (LL) problems into logical and physical LL problems. Logical LL problems are about task assignment to stations (LB) and resource planning, and physical LL problems are about geometrical arrangement in determining locations, relations and connections between stations, resources, conveyors, buffers on the shop floor. Based on the same classification, [START_REF] Rekiek | Assembly Line Design: The Balancing of Mixed-Model Hybrid Assembly Lines with Genetic Algorithms[END_REF]] study the configuration design. In [START_REF] Elmaraghy | Flexible and reconfigurable manufacturing systems paradigms[END_REF], physical configurations include hardware modification, addition, and/or replacement for layout, machines, material handling decisions and machine elements; and logical configurations include rerouting, rescheduling, replanning, reprogramming.

Motivations for systemic configuration definition

Plenty of configuration design approaches have difficulties to be applied in real-world and complex industrial problems. To top it all, changeability and change propagation accentuate the obsolescence of segmented configuration domains. Several statements are summarized about the restricted assumptions for manufacturing system design and segmented design sub-problems:

1. Existing academic algorithms require small amounts of input data, simplified, static and often non-realistic assumptions [AlGeddawy andElMaraghy, 2011] [Rekiek andDelchambre, 2006] 2. Dimensioning approaches assume design problems to be complete in their objectives, decision variables and constraints. A confusion between dimensioning and design is recurrent (e.g. "the design of a manufacturing system is the process of deciding the values of the decision variables of the manufacturing system" [Chryssolouris, 2005]) whereas the problem should precisely be formulated during the design process.

3. Coupled constraints and conflicting factors between configuration domains, especially during change propagation scenarios, testify holistic approaches to integrate design sub-problems (e.g. [START_REF] Youssef | Optimal configuration selection for Reconfigurable Manufacturing Systems[END_REF] highlights the lack of consideration of process constraints and capabilities of resources contained in workstations which prevents a feasible physical configuration)

4. Lowest configuration levels are not considered (e.g. at the machine level a configuration is composed of tools, fixtures or orientation of spindles, at the system level a configuration is composed of generic stations).

Designers and researchers from the manufacturing system community push for broadest and more holistic considerations of design problems. [START_REF] Bonney | A manufacturing system design framework for computer aided industrial engineering[END_REF] argue for considering the manufacturing system design as a complex process involving the integration of different inter-dependent functions, usually considered separately. In applying Axiomatic Design (AD) to manufacturing systems, [START_REF] Cochran | A decomposition approach for manufacturing system design[END_REF] claims that design methods must consider interactions among various components at different levels. [Wu, 2003] underlines the requests from companies to consider the relevant activities and to treat them as an integral part of the complete cycle. Defending the integration of coupled design problems, [Chryssolouris, 2005] states that the approaches only addressing resource requirements or buffer capacity problems miss the bigger design problem in which buffer capacities will affect the number of resources required and vice-versa. First and foremost in RMS research, [START_REF] Rösiö | Reconfigurable production system designtheoretical and practical challenges[END_REF]] observe that manufacturing system design methodologies that include reconfigurability do not concern all system constituents, through all phases and all activities. [Rösiö, 2012] claims that the traditional system design framework should be totally reconsidered in this new reconfigurable contest with holistic perspectives.

Systemic approaches for manufacturing system design

For a better appreciation of the complexity of manufacturing systems and manufacturing system design activities, a systems thinking approach [Daniel Allegro et al., 2013] drives the following study. This work intends to establish the boundary of the System of Interest (SoI) through process and product perspectives. The adjacent and influential activities in the context of manufacturing system design are firstly presented in section 2.2.1 (i.e. black-box representation). A review of involved and coupled design activities with manufacturing system design is then presented in section 2.2.2 (i.e. white-box representation). Following the process knowledge, comes the product knowledge represented with an ontology of manufacturing systems in section 2.2.3.

Adjacent domains with manufacturing system design

Presentation of the adjacent domains

The challenge of change management in the context of manufacturing systems comes from product (new models, new variants) and volume as they drive the whole manufacturing system design process. Problems relating to change management have been studied in various domains such as production control & planning (adaptative production planning and control [START_REF] Wiendahl | Changeable Manufacturing -Classification, Design and Operation[END_REF], agile manufacturing planning and control system [START_REF] Deif | Agile MPC system linking manufacturing and market strategies[END_REF], modular logic programming and function blocks [START_REF] Stambolov | Reconfiguration Processes in Manufacturing Systems on the Base of IEC 61499 Standard[END_REF], agent-based control approaches [START_REF] Kouiss | Organisations distribuées des systèmes de pilotage[END_REF]), design product (Product Family, GT), process planning (process family [START_REF] Jiao | Product family design and platformbased product development: a state-of-the-art review[END_REF], reconfigurable process planning [START_REF] Azab | Planning for Reconfigurable Manufacturing[END_REF]), and others [START_REF] Elmaraghy | Product variety management[END_REF]. The scope of this research is restricted to change management impacting manufacturing system design. From the perspective of manufacturing systems, product and process are domains with the most impact on manufacturing systems. Several frameworks highlight these dependencies, as for instance the assembly model of [Rampersad, 1996] (see figure 2.4). Some frameworks also add interactions with strategic decisions of the company (e.g. external driving forces as cost, quality, technological innovation, regulations, market demand, short delivery times [START_REF] Tolio | SPECIES-Co-evolution of products, processes and production systems[END_REF]).

Figure 2.4: Interactions between product, process & system domains [Rampersad, 1996] A schematic representation of the domains influencing manufacturing system design is presented in figure 2.5 and detailed below:

Product design represents and specifies products using tools as liaison graph, tree matrix, 3D models or Bill of Materials (BOM). It results in needs and constraints for operations and work plans. It answers the question "What product shall be manufactured?".

Process planning aims at selecting processes and sequencing them. It results in feasible sequences of operations and precedence constraints for the manufacturing or the assembly process. This step links product design to product manufacturing. It answers the question "How will products be manufactured? What operations shall be performed?"

Manufacturing system design is based on product design and process plans; needs and constraints for future equipments, tooling and fixtures lead to a physical solution. It leads to resources selection, decisions on their arrangement and assignment of operations to stations. It answers the question "How and with what operations will be processed ?".

Integrated design approach strategies

Change can come either from manufacturing system design, from process planning or from product domain. In order to cope with change propagation in a context of product and process proliferation, various approaches define the boundary for manufacturing system design in various ways regarding the adjacent domains. The following classification organizes the approaches regarding the concerned design activities with manufacturing system design, and whether they are co-development approaches or influenced-based. Figure 2.6 presents four types of approaches based on their boundary with manufacturing system design: co-development process planning and manufacturing system design, process planning influenced by manufacturing system design, co-development product design and manufacturing system design and product design influenced by manufacturing system design [Benkamoun et al., 2013a[START_REF] Benkamoun | Modularity principles applied to variety in assembly system design process[END_REF]. Co-development process planning and manufacturing system design [START_REF] Rogers | Modular production systems: a new manufacturing paradigm[END_REF] suggest a procedure to synthesize Modular Production System (MPS) which includes: 1-product analysis to determine the process modules and the sequence of operations (process planning) 2-representation of processes for MPS design (formulation of process plan for manufacturing system design) 3-MPS synthesis with identification of the process machine primitives and balancing regarding the production volume. They also plan to extend this procedure to geometrical configurations of the process machines primitives, so that manufacturing systems can be synthesized at a detailed level. [START_REF] Webbink | Automated Generation of Assembly System-Design Solutions[END_REF]] use a co-decision approach for assembly sequencing and system configuration design. System configurations are generated, followed by assembly sequences, then both are matched.

Product design influenced by manufacturing system design Since the complexity of processes is mainly caused by product variety, some works intend to reduce design product complexity regarding manufacturing perspectives. [START_REF] Zha | Knowledge-based approach and system for assembly oriented design, Part I: the approach[END_REF] propose an assembly oriented design process with three main stages: assembly modeling and design activity, assembly sequence planning, and assembly analysis and evaluation activity. Facilitating manufacturing process and assembly process are respectively the goal of Design for Manufacturing (DfM) (optimization of part design for the chosen process) and Design for Assembly (DfA) (minimization of efforts of assembly). To make easier process change in manufacturing systems, [Fixson, 2007] uses modularity and commonality for product architecture and reduces interconnections with other activities. In the same line, [START_REF] Jiao | Product family design and platformbased product development: a state-of-the-art review[END_REF] use modularity in product family regarding manufacturability; product variants share assets as physical components, processes, knowledge, people or relationships. In doing so, manufacturing processes have enhanced flexibility and responsiveness. [START_REF] Jiao | Coordination of product and process variety in mass customization with data mining approach[END_REF] adopt an association rule mining technique to identify relationships between product variants and process variations. [START_REF] Elmaraghy | A classification Code for Assembly Systems[END_REF] state that mapping product and system with a measure of system complexity would considerably help system designers. Accordingly, [START_REF] Hu | Product variety and manufacturing complexity in assembly systems and supply chains[END_REF] introduce a unified measure of product variety induced by assembly system design.

Process planning influenced by manufacturing system design [START_REF] Xu | A novel process planning schema based on process knowledge customization[END_REF] suggest a process planning scheme based on knowledge coming from universal knowledge on manufacturing processes, and also from specific geometric and technological capabilities of the manufacturing systems at shop-floor level and machine level.

Co-development product design and manufacturing system design Co-design approaches look for a perfect mapping between system and product design so that change does not amplify through the successive activities. [START_REF] Fujimoto | Assembly Process Design for Managing Manufacturing Complexities Because of Product Varieties[END_REF] present a systematic framework for assembly design, including product structure planning, process planning and assembly technology planning. [AlGeddawy, 2011] develops a new co-evolution model between products design and manufacturing system capabilities. It is inspired from a classification tool used in Biology which establishes the evolution course of living organisms. The model ensures concurrent and optimized evolution of products and manufacturing systems in maximizing the use of manufacturing capabilities and their adaptability. In addition to co-design approaches in which the product architecture is synthesized along with the manufacturing system architecture, further co-development approaches include selection of products concurrently to manufacturing system design. [Lee, 1997] suggests a co-selection approach for components with similar routes and manufacturing resources regarding reconfigurability criteria. [START_REF] Abdi | Products Design and Analysis for transformable Production[END_REF] come up with the idea that keeping market and manufacturing environments separate will restrain the adaptability of manufacturing systems. The system configuration design stage drives the reconfiguration of product family regarding system availability. In [START_REF] Bryan | Co-Evolution of Product Families and Assembly Systems[END_REF], product family selection activity and assembly line design evolve together.

Interaction modeling of co-development approaches

Co-development approaches from product design to manufacturing system design have various interaction models. Approaches rationalizing interactions are reviewed in this section (e.g. multiagent models, constraints negotiation, emergent synthesis), however, approaches aiming to capture interactions without rationalizing them are excluded (e.g. neural network, multi-state models, try/error via simulation, simulation plus search). The three studied domains involving interactions are: product design, process planning and manufacturing system design. In figure 2.7, the co-development approaches are clustered into four categories of interaction modeling: prescribed sequence approaches formalizing sequential process models of the various design activities, described sequence approaches giving more details about flow objects between activities, prescribed negotiation approaches presenting heterarchical models in which activities are able to negotiate constraints and objectives, described negotiation approaches offer more complete models regarding interaction flow enabling in turn automated applications. Maturity and completeness of the concerned domains are illustrated with shaded of grey boxes. A black box reveals the presence of various viewpoints (product design: conceptual design, CAD, shape, size, quality; process domain: technological process, sequence of operations, line balancing, tool path, Numerical Control (NC) data; manufacturing system design: equipment selection, tools, fixture and jigs selection, dimensioning of resources numbers, layout, machine design). In contrast, a grey box reveals only few consideration of viewpoints (e.g. process planning is limited to process selection, or system design to equipment selection, assuming that equipment already exists etc.).

System design Process Planning Product design c [START_REF] Bonney | A manufacturing system design framework for computer aided industrial engineering[END_REF]Cochran, 2000[START_REF] Nielsen | A resource Capability Model to Support Product Family Analysis[END_REF]Baqai, 2010Huang et al., 1995Zha et al., 1999Petrović et al., 2011Park and Balk, 1999Sun et al., 2001Chan et al., 2001Wang and Shen, 2003[START_REF] Frei | Designing self-organization for evolvable assembly systems[END_REF] Prescribed The analysis of figure 2.7 brings the conclusion that the more approaches tend to be complete in describing interactions, the more it is difficult to consider a broad scope of involved viewpoints. The largest frameworks regarding interactions with system design are found within prescribed approaches. The described approaches either encompass restricted viewpoints for manufacturing system design (e.g. layout, dimensioning) or exclude the system design domain in focusing on interactions between product design and process planning. This review reveals that interactions between manufacturing system design and supporting design domains (i.e. product and process domain) fail to be modeled in a complete way and tend to ignore system design complexity.

Ontology of manufacturing system design activities (process view)

The driving motivation of this research work is to capture the complexity of manufacturing system design. This section reviews manufacturing system design activity viewpoints and constitutes an ontology of internal activities involved in manufacturing system design projects.

Motivations for including process planning activities

The inputs of manufacturing system design problems can be strategic requirements (e.g. economy of scale or scope), productivity (e.g. efficiency of throughput) or investment costs. But the most driving requirement is the production context composed of: market demand, product family and volume, also characterized by variability and uncertainty degrees. The pre-process plans are used to describe product features and precedence constraints. As already stated before, process plans relate product features to their transformation process within the manufacturing system and give preliminary specifications for the conceptual manufacturing system design. But simultaneously, design decisions on capability of manufacturing systems (i.e. production methods, resources, arrangements) constrain the process planning activity. [Baqai, 2010] makes this explicit in stating that existing approaches for process planning require knowledge regarding usable production systems architectures; and approaches for system design requires knowledge of process plans to be performed on them: the design of A requires knowledge of B and "vice versa". The paradox of process planning being an input for system design and depending on manufacturing capabilities has pushed a lot of authors to work on the topic of collaboration between process planning and manufacturing scheduling. Manufacturing scheduling aims to select process plans and to assign manufacturing resources for specific time periods to the set of process plans. Agent-based approaches have been largely applied to this field due to their adaptability to real work dynamic manufacturing environment with the consideration of real time machine workload and shop floor dynamic [START_REF] Shen | Agent-Based Distributed Manufacturing Process Planning and Scheduling: A State-of-the-Art Survey[END_REF]. However holistic considerations between the various process planning viewpoints and manufacturing system capabilities are still rare in manufacturing system design.

Synthesis of design activities Design activities directly involved in manufacturing system design are classified in process (or logical) domain or physical design domain. The process activities relate to the various decisions included in process planning. The physical design activities deliver physical decisions. Five activities in physical design domain (D) and four activities in process domain (P) are listed:

• D1 Generic resource functionality for manufacturing, transport or material handling subsystems

• D2 Generic layout type
• D3 Arrangement of machines and dimensioning (number, location of resources)

• D4 Machine specifications (interfaces and behavior)

• D5 Machine parameters (programs, tools, fixtures configuration)

• P1 Pre-Process Plan: process classes based on product features and precedence constraints (e.g. [START_REF] Nielsen | A resource Capability Model to Support Product Family Analysis[END_REF])

• P2 Macro planning: optimal process sequences from process and product precedence constraints (e.g. [START_REF] Azab | Semi-generative macroprocess planning for reconfigurable manufacturing[END_REF])

• P3 Line balancing: operations groups and task allocation to resources, cells or stations ElMaraghy, 1993]: allocation of instructions to resources, devices, fixtures or tools (e.g. control code generated via Functional Blocks (FBs) specifications IEC-1131-3)

• P4 Detailed & Micro planning [
Coupling analysis between activities Based on various approaches that integrate two or more design activities being part of the previous classification, precedence and dependent relationships are now studied. In the physical design domain, it is observed that (D1) delivers generic resource profiles for (D2). (D2) can also influence (D1) based on some preferences or availability for layout. (D2) influences (D3) in specifying the layout workspace, and (D3) influences (D4) through interface requirements. (D4) is a critical activity that can force to reconsider (D2) based on equipment feasibility, and (D3) based on available interfaces and mobility. (D4) drives (D5) using resource capability regarding parameterization; (D5) can reassess (D4) based on capabilities for parameters. From a review of integrative approaches in process planning activities ( [START_REF] Battaïa | A taxonomy of line balancing problems and their solution approaches[END_REF]] [Zhang et al., 2002] [AlGeddawy and ElMaraghy, 2010] [Wang et al., 2003] [Sprumont and Muller, 1997] [Nielsen and Kimura, 2006] [Baqai, 2010] [Bonney et al., 2000] [Wang et al., 2003] [Zhang et al., 2002] [ElMaraghy, 1993]), (P1) → (P2), (P3) → (P4), (P2) ↔ (P3). In [START_REF] Wang | Architecture design for distributed process planning[END_REF] and [START_REF] Zhang | Research on flexible transfer line schematic design using hierarchical process planning[END_REF] (P2) → (P1). The crucial point on which this ontology relies on is the dependency between activities of (P) and (D). In some cases, process domain (P) dictates physical system domain (D) (e.g. ( P1) → (D1) (P2) → (D3) [Koren andShpitalni, 2010] [Wu, 2003], (P2) → (D4) [START_REF] Battaïa | [END_REF]Dolgui, 2013] [Sprumont andMuller, 1997]. Inversely, (D) can dictates (P) (e.g. ( D3) → (P3) [START_REF] Battaïa | A taxonomy of line balancing problems and their solution approaches[END_REF] [AlGeddawy and ElMaraghy, 2010], (D2) → (P3) [START_REF] Koren | Design of reconfigurable manufacturing systems[END_REF] (D4) → (P4) [START_REF] Frei | Designing self-organization for evolvable assembly systems[END_REF]).

Co-decision approaches assume bi-directional dependencies (e.g. ( P1) ↔ (D1) [START_REF] Järvenpää | Adaptation of Manufacturing Systems in Dynamic Environment Based on Capability Description Method[END_REF], (P3) ↔ (D4) [START_REF] Zhang | Research on flexible transfer line schematic design using hierarchical process planning[END_REF]] [Bonney et al., 2000], (P2) ↔ (D3) in [AlGeddawy and ElMaraghy, 2010], (P4) ↔ (D5) [START_REF] Wang | Architecture design for distributed process planning[END_REF]).

The dependencies between the various activities are summed up in the graphical map in figure 2.8a with the use of directional arrows, and in the coupling matrix in figure 2.8b. They clearly demonstrate the complexity of manufacturing system design processes.

Ontology of manufacturing systems (product view)

Manufacturing systems have been presented under a design process viewpoint, now a product viewpoint is adopted in providing an ontology for manufacturing systems [START_REF] Benkamoun | Architecture Framework for Manufacturing System Design[END_REF].

Structural hierarchy

Three hierarchical levels are differentiated within a manufacturing system according to the hierarchical representation of [START_REF] Scholz-Reiter | Autonomous Processes in Assembly Systems[END_REF] in figure 2.9.

Figure 2.9: Levels of assembly systems [START_REF] Scholz-Reiter | Autonomous Processes in Assembly Systems[END_REF] 1. At the system level (i.e. shop-floor), a manufacturing or assembly system is defined as a set of workstations or cells interlinked with storage and transportation systems. Together they manufacture a work-piece or sub-product family. The whole product is manufactured at an upper level.

2. At the sub-system level, a cell or a workstation is made of an arrangement of resources (e.g. human resources, facilities, robot, transfer system, machine and different devices) supporting a set of different processes or operations. A single facility or a workstation is in charge of manufacturing a sub-product element or feature. A cell or a workplace supports several manufactured features from a feature family, often grouped within one unit according to their similarities in the technology process.

3. At the machine level, the selection of components, devices, tools, grippers, data and programs and their arrangement are done according to the operating task of the equipment.

UML class diagram for manufacturing systems

Based on the three levels, an ontology is presented in figure 2.10 using a Unified Modeling Language (UML) class diagram. The three levels are represented through aggregation relationships between the different classes. Components of system and sub-system classes are attributes and functionalities are methods. The class diagram represents the possibilities of designing or representing an existing system according to the three pre-defined levels. A review of the different existing taxonomies relating to physical attributes is presented in table 2.4.

(Logistical) Storage system System -Shop floor Technological.Manufacturing(production_unit, raw-parts, sub-product, waste_material, control_data) Logistical. Storing(buffer_unit,raw-parts, sub-product, control_data) This ontology includes some particular cases. Firstly, system and sub-system levels may be merged if sub-system components are directly machine components (e.g. tools, grippers, sensors). For example, a manufacturing system composed of different CNC machines has two levels: the system level (CNC machines inter-connected by a conveyor) and the machine level (tools, spindles, grippers and data). Another particular case is the co-existence of two layers within the subsystem level (e.g. a production unit would have an internal transportation system or a buffer system to ensure the continuous supply of part and require other handling devices as robots).

System -shop floor level Classes of methods are decomposed into technological class (i.e. part transforming with manufacturing or assembly process), logistical class (i.e. storing and conveying parts, material or tools at system level) and informational class coping with informational operations (i.e. control and supervision of the system). This segmentation is justified by the later allocation of physical units fulfilling various process functionalities (i.e. production unit, storage system, manufacturing transport, control system, and production system control). Three kinds of attributes are considered: system flow objects (flow objects class), system components (component class) and arrangement of components (arrangement class), from which the layout (layout class) representing physical arrangements of facilities is inherited. Flow objects may be raw part, sub-products, energy, waste material and control data. The system components are the production system control (e.g. Manufacturing Operations Management Systems (MOMS)), production units (e.g. cells or workstations), storage systems (e.g. warehouse) and transportation systems between production units and storage systems. Waste material managing system, data network transportation (e.g. LAN network) and energy transportation system are also components of the system. Finally, the system is characterized by the physical arrangement of units within the system type (i.e. layout), and the logical arrangement representing the informational system (system control ).

Sub-system level: production unit class Based on the standard [VDI 2860[START_REF] Vdi | Systematic approach to the development and design of technical systems and products[END_REF], the general functions of an assembly station are: handling (defined as material or tools feeding in order to dispose and make in ready-position the involved components during process activity), joining, checking (testing quality, inspection), adjusting (refined tools, parts supply, product) and special operation (e.g. identification, labeling or any necessary post-process operation). The processing method is generic to the used technology process. These functionalities may be either from technological class (e.g. processing) or logistical class (e.g. handling). Handling is decomposed in sub-functions [VDI 2860[START_REF] Vdi | Systematic approach to the development and design of technical systems and products[END_REF]]: buffering, moving, changing quantity, fixing, checking. Instances from the transportation system and storage system as buffers may also be included in the production unit. The attributes of a production unit class inherit: from the flow objects class (i.e. flow objects going through the production unit) or from the component class within process control system (industrial control system as Supervisory Control and Data Acquisition (SCADA) or smaller as Programmable Logic Controller (PLC)), handling system for the micro-logistical task, identification facility, periphery facility (e.g. doors for safety, identification facility) and inspection facility checking quality on parts or product. The process enabler class component is the production facility. The arrangement of the physical components is derived from the layout class. [START_REF] Gudehus | Comprehensive Logistics[END_REF] Transportation system type (i.e. layout) Its characteristics are: level (floor level or overhead [Wan, 2006]), working network (aisle, conveyor, overhead or column network [Wan, 2006]), connectivity characteristic (strength of connectivity, the capacity and directionality [Wan, 2006]), motion (uni or bi-directional, synchronous or asynchronous [START_REF] Elmaraghy | A classification Code for Assembly Systems[END_REF]), the path (fixed or variable [START_REF] Elmaraghy | A classification Code for Assembly Systems[END_REF])

Table 2.4: Taxonomies of manufacturing system components Sub-system level: storage system class The basic purpose of a storage place is to keep stocks and provision of work-pieces, sub-products, raw parts, load carriers or tools. The usual steps for a storage process are: receiving storage units, identification and quality verification of units, determining location, dispatching units in storage places, holding units in a store place, removing units and control operations system. We differentiate storage objects (raw parts, tools, load carrier or sub product) from other components [START_REF] Gudehus | Comprehensive Logistics[END_REF] as storeplaces, storage devices fulfilling the work function of storing and retrieving units, load handling devices or internal transport system. Other attributes are the storage process control system, the identification facility which identifies the storage objects and the periphery facility for other purposes. The layout class is once again used to represent the arrangement of the listed physical objects representing a storage system type.

Sub-system level: transportation system class A transportation system relates to a technology used to move objects from one location to another (e.g. between production or storage units).

The main logistical class function of a transportation system is transporting. It can also include an identifying functionality to control transported objects, a control and a monitoring functionality through the control system. The components of a transportation system are the transportation devices which directly result from the chosen technology, the transported objects (e.g.. sub-products, raw-parts, tools or load carrier), the identification facility, the picking stations, the delivering stations, and the process control system. The transportation system type defines the transportation network.

Changeability in system engineering design

The review on changeability in manufacturing systems literature (see section 2.1) has highlighted the needs for broader and more holistic considerations for configuration domains, and for design for changeability and reconfigurations projects throughout system lifecycle. The ontology of manufacturing systems and manufacturing system design processes (see section 2.2) has also demonstrated the realistic complexity regarding the dependencies with product and process plan domains, the multiple viewpoints, and large possibilities in design. Rare are the design approaches in manufacturing system literature that tend to embrace this systemic definition for manufacturing systems and design processes as well; changeability is even less considered. The premise that manufacturing systems are complex systems brings us to study the problem from another research perspective, namely changeability in complex engineering systems. Change management is actually a key concept in system engineering design discipline. Change drivers are recognized to be volatility, variety and strategy in manufacturing systems [START_REF] Wiendahl | Changeable Manufacturing -Classification, Design and Operation[END_REF], and manufacturing systems are considered to be dynamic marketplaces, rapid technological evolution and variety of operating environments [START_REF] Fricke | Design for changeability (DfC): Principles to enable changes in systems throughout their entire lifecycle[END_REF]. This section subscribes to DTM approaches [START_REF] Elmaraghy | Design Theory and Methodology[END_REF]] that fit multi-viewpoint design, open-ended design problems, incomplete and conceptual design problems. Faced with the specificity of each manufacturing system design project, system engineering design methodologies have the advantage of offering generic principles and tools. A framework of system engineering design domains for architecture and configuration definitions is presented in section 2.3.1. A change ontology based on various references is synthesized in section 2.3.2. Section 2.3.3 reviews system engineering design processes for change and changeability.

Engineering design configurations

Definition for system configuration & re-configuration Enlarged domains for configuration definitions were introduced in section 2.1.5. Regarding the engineering design domain, the following generic definition applies to any engineering system or product, including manufacturing systems. Two views for the configuration definition coexist in the literature. The first one adopts a combination-based design perspective; the second one defines a configuration as a system instance resulting from engineering changes. For [IEEE 1220[IEEE , 2005] ] [ISO/IEC 2382, 2015] [Hagan, 2009], a configuration is an arrangement and organization of the parts. A system can decline different configurations through re-arrangement, assuming a collection of pre-existing artifacts and combination rules. In the second definition, a configuration merely refers to a set of functional and physical characteristics of a system [MIL-STD-480B, 1988] [DODD 5010.19, 1987] [MIL-STD-973, 1992]. In the Configuration Management (CM) discipline [IEEE 610.12, 1990], a configuration is a system instance resulting from system change during its lifecycle. A system configuration assumes a "reconfiguration process", also called "redesign process" or "system engineering change process". The two definitions can be reconciled into one by stating that a configuration is a variant of a system architecture implying changes of components whether pre-defined or not.

Survey on design viewpoints Design is conventionally defined as the mapping process from the design problem to the physical solution which satisfies the stated functional requirements and the identified constraints [START_REF] Elmaraghy | A New Engineering Design Paradigm -The Quadruple Bottom Line[END_REF]. Architectural frameworks for product representation during design process usually encompass additional viewpoints which are interesting to review in order to define systemic domains for system configurations. Various well-known design frameworks, methodologies and ontology from the problem domain to solution domain are considered: [IEEE 1220[IEEE , 2005]], Function-Behavior-Structure (FBS) by [Gero, 1990], Axiomatic design by [Suh, 1998], Cimosa by [ESPRIT Consortium AMICE., 1993], Aris by [START_REF] Scheer | ARIS architecture and reference models for business process management[END_REF], Sagace by [START_REF] Penalva | Sagace: la modélisation des systèmes dont la maîtrise est complexe[END_REF], [Micouin, 2006], Pera by [Williams, 1994] and [START_REF] Pahl | Engineering design: a systematic approach[END_REF]. Their prescribed viewpoints are synthesized in table 2.5. Their definitions are given hereinafter.

Needs This initial view illustrates the finality of the system in its environment. This stage deals with the teleology of the system , namely the goals ("what it is for"). It often focuses on the given service by the system to its context, according to a 'black box' representation.

Functional requirements Functional requirements commonly refer to formal and structured statements of what the system shall do, in contrast to behavior requirements that encompass a process view stating how they shall do it. Functional requirements can be decomposed into others through successive "how" questions (functional decomposition).

Behavior requirement In common understandings, a function is represented as an intended transformation of the system from a state A to a state B to fulfill a task. In that sense, functions should be linked to behavioral requirements specifying the interactions that should take place in the system to fulfill the needs.

Functional solution A functional solution is distinguishable from the physical solution since it is supposed to be solution neutral. Actually, it lies somewhere between the problem definition domain and the detailed solution domain. Because it is a first step towards the solution definition, a functional solution can also be seen as a generic or conceptual physical solution.

Physical solution

The physical solution is about how the system realizes the required functions at the physical level. System organs, components, their arrangements and their relationships are specified. Some frameworks explicitly distinguish between different granularity levels: generic (conceptual decision about a kind of physical solutions, technology choice for instance), embodiment (physical organization or even the representation of specific kind of objects as data, people, resources) and detailed (parametrization within the defined components). Confusions in definitions "Function" and "Functional architecture" are unclear terms as they can have several meanings in the reviewed approaches. In some cases a function is defined as the initial purpose of the system (e.g. FBS [Gero, 1990]). It can also be assimilated to a formal textual requirement that the final system must later verify (e.g. AD [Suh, 1998]). A function can also be seen as an expected transformation operated by the system; the flow-oriented representation formalism IDEF-0 based on SADT assumes that "a function is an activity, a process or a transformation identified by a verb or verb phrase that describes what must be accomplished". [Micouin, 2006] highlights the confusion of the term "function" since it can refer to "a transformation" (the function is characterized by inputs, outputs and its associated behavior), or to "an intended effect" (the function is characterized by its output result). A structural view can also be used to represent a set of functions (e.g. a logical architecture [IEEE 1220[IEEE , 2005] ] or a hierarchical function structure [START_REF] Uddin | Complex product architecture analysis using an integrated approach[END_REF]). For [START_REF] Chakrabarti | A scheme for functional reasoning in conceptual design[END_REF], function modeling addresses finding a solution early in the process, at an abstract level. As a matter of fact, a functional solution or architecture often fulfills the same role as generic or conceptual solutions. Diagram in SysML, IDEF-0, Flow-oriented functions structure, Functional Flow Block diagram (FFBD), SSFD. Each of them can instantiate various levels of genericity. For instance, flow interfaces can be purely functional (e.g. association links) or physical (e.g. spatial, material, energy and information [START_REF] Pimmler | Integration analysis of product decompositions[END_REF]).

Reference

Synthesis of viewpoints for configuration domains

Design viewpoints for changeability [START_REF] Ahmad | Change impact on a product and its redesign process: a tool for knowledge capture and reuse[END_REF]] present a complete literature review leading to the conclusion that change propagation methods are often restricted to specific domains. As a result, they suggest the Information Structure Framework (ISF) capturing information domains of design (i.e. requirements, functions, components, and detail design process), so that change propagation can be fully understood and managed. Sharing the same motivations for enlarging change and configuration domains, the framework proposed in this section is slightly different since it enlarges the design viewpoints and fits iterative, incremental and progressive design processes without being unidirectional. It will be taken as a reference for configuration design and design for changeability methodologies in the rest of this dissertation.

Ontology of change

The increasing complexity of systems and environments requires lifecycle properties concerned with wider impacts than immediate and primary functions. [START_REF] Weck | Life-cycle Properties of Engineering Systems[END_REF] call them "ilities" and justify their expanding list by the combination of multidimensional social and technical system complexity specific to our "epoch of engineering systems". In engineering design domain, changeability is understood as the ability of systems to easily change based on changing circumstances, no matter the kind of change. This work subscribes to the definition of change of [START_REF] Jarratt | Engineering change: an overview and perspective on the literature[END_REF]: "an alteration made to parts, drawings or software that have already been released during the product design process and life cycle". This section intends to synthesize an ontology of change from the literature and to emphasize the heterogeneity of terms. As a mere example, changeability can sometimes be referred to through the term "flexibility" [De [START_REF] Weck | Life-cycle Properties of Engineering Systems[END_REF]] [Cardin, 2014] (i.e. flexible design is the system's "ability to adapt, change and be reconfigured, if need, in light of uncertainty realizations") or the term "adaptability" [START_REF] Gu | Adaptable Design[END_REF]] [Gu et al., 2009] (i.e. adaptable design is the "ability to create a new or modified design based on changed requirements").

Change drivers classification Change drivers (change sources or change agents) define the factors for the change to occur. Change drivers can be initiated or emergent from the system [START_REF] Eckert | Change and customisation in complex engineering domains[END_REF]. [START_REF] Mcmanus | A Framework for Incorporating "ilities" in Tradespace Studies[END_REF] and [START_REF] Ross | Defining changeability: Reconciling flexibility, adaptability, scalability, modifiability, and robustness for maintaining system lifecycle value[END_REF] classify changeability approaches based on the location of the change agent: adaptability (the change agent is internal to the system) or flexibility (the change agent is external to the system). [START_REF] Fricke | Design for changeability (DfC): Principles to enable changes in systems throughout their entire lifecycle[END_REF] add agility as the system's ability to respond rapidly to change from external agents. In manufacturing systems, [START_REF] Wiendahl | Changeable Manufacturing -Classification, Design and Operation[END_REF] enumerate change drivers: volatility (volume fluctuation), variety (product variants) and new company strategy (decision level for change). For [START_REF] Francalanza | Deriving a systematic approach to changeable manufacturing system design[END_REF], the change requirements in the manufacturing system domains are product range, manufacturing and business requirements. There are as many types of change drivers as types, levels and viewpoints of requirements for manufacturing system design. Beyond the manufacturing system domain, stakeholders able to initiate change are customers, sales and marketing, product support, production, suppliers, product engineering, company management and legislators [START_REF] Jarratt | Engineering change: an overview and perspective on the literature[END_REF].

Change strategy classification In addition to the location of change agents, [START_REF] Mcmanus | A Framework for Incorporating "ilities" in Tradespace Studies[END_REF] and [START_REF] Ross | Defining changeability: Reconciling flexibility, adaptability, scalability, modifiability, and robustness for maintaining system lifecycle value[END_REF] classify changeability approaches in describing the effect of the form change on the system. It refers to the change strategy specifying "how" the system adapts to change. It can either be a change of the current level of a system parameter (i.e. scalability) or a change of a current set of system parameters (i.e. modifiability or convertibility). In the Integrated Real Option Framework (IRF), [START_REF] Mikaelian | Real options in enterprise architecture: A holistic mapping of mechanisms and types for uncertainty management[END_REF] suggest two types of flexible strategies: expanding capacity and switching technology. [START_REF] Weck | Life-cycle Properties of Engineering Systems[END_REF] add the extensibility as a system's ability to fulfill its original function and a different function or set of functions. [START_REF] Fricke | Design for changeability (DfC): Principles to enable changes in systems throughout their entire lifecycle[END_REF] distinguish change strategies according to cost, time and level of automation: ability to change easily (i.e. flexibility), ability to change rapidly (i.e. agility), ability to adapt the system without external actuation (i.e. adaptability), ability to be insensitive toward changing environments (i.e. robustness). In the manufacturing system domain, strategies of changeability can be classified based on the ready-to-use level of change solution. It has been seen in section 2.1.1 that reconfigurability and flexibility are common concepts under the changeability paradigm: flexibility is a pre-built capability that respond to change with at least a change-over phase; reconfigurability is the system's ability to adjust the production capacity and functionality reactively, easily and quickly by rearranging or changing structure components [START_REF] Koren | Reconfigurable manufacturing systems[END_REF]. [Terkaj et al., 2009c] define three basic flexibility levels dealing with change regarding timing, cost and number of steps necessary to implement change: flexibility (the system has the ability), reconfigurability (the system can acquire the ability and already have enablers), changeability (the system can acquire enablers). Although reconfigurability is a strategy based on the required efforts to implement it in manufacturing system domain; it is defined in system engineering design domain as the system's ability to reversibly achieve distinct configurations through alteration of system form or function [Siddiqi and de Weck, 2008].

Change enablers Change strategies imply decisions on change enablers that are responsible for instantiation of the changeability in the design. In addition to change type, [START_REF] Mikaelian | Real options in enterprise architecture: A holistic mapping of mechanisms and types for uncertainty management[END_REF] characterize real options by mechanisms (modularity, redundancy, buffering or staging). Those concepts are also present in the RMS literature, since [START_REF] Koren | Design of reconfigurable manufacturing systems[END_REF] establishe five enablers for reconfigurability: customization, convertibility, scalability, modularity, integrability and diagnosability. [Rösiö, 2012] differentiates critical characteristics which lead to a capacity or functionality change (i.e. convertibility, scalability) from supporting characteristics which reduce system reconfiguration and ramp-up time (i.e. integrability, diagnosability and modularity). She adds mobility and automatibility as supporting characteristics (see figure 2.12). Modularity and integrability are commonly referred to as critical "ities" for enabling changeability in flexibility and reconfigurability paradigms. In addition, [START_REF] Fricke | Design for changeability (DfC): Principles to enable changes in systems throughout their entire lifecycle[END_REF] add simplicity, independence and autonomy. These enablers are often developed independently in the literature. For instance, modularity in product and platform design research is a trendy topic regarding the race for product variety and personalization [START_REF] Elmaraghy | Product variety management[END_REF]. Despite these definition efforts, change enablers are rarely combined together and integrated in engineering design methodologies.

Figure 2.12: Reconfigurability characteristics [Rösiö, 2012] The change effects, strategies, and enablers are all summed up in figure 2.13 and link to criterion used for their classification. The dotted arrows illustrate ontological links from manufacturing system research. This ontology illustrates that despite the various use of terms, there is an agreement on the criterion used to classify them. Change objects Change can be allocated to various types of objects in manufacturing system. [Terkaj et al., 2009a] define four basic flexibility dimensions: capacity (scalability of the system), functionality (the system can manufacture different products), process (the system can obtain the same products in different ways), production planning (the system changes the order of execution and the resource assignment). [START_REF] Wiendahl | Changeable Manufacturing -Classification, Design and Operation[END_REF] distinguish product or product family, technological or logistical processes or facilities. [START_REF] Mehrabi | Reconfigurable manufacturing systems : Key to future manufacturing[END_REF] list system, software, control, machine and process. In [START_REF] Francalanza | Deriving a systematic approach to changeable manufacturing system design[END_REF], change objects are layout, machine, services and material handling. For a complete taxonomy of change objects, we refer to the ontology for manufacturing systems proposed in section 2.2.3.

Engineering change approaches

Managing change along product lifecycle is a surviving issue for today's companies. For complex systems marked by high coupling between system engineering artifacts, change propagation can finish badly if it is not well managed. [START_REF] Eckert | Change and customisation in complex engineering domains[END_REF] distinguish the following scenarios for change propagation: unending (avalanche) and ending change propagation (blossom, or ripple) (see figure 2.14). It is a common observation that the more change is tackled late in the design process, the more it has high impacts. Two strategies are distinguished for managing engineering change (see figure 2.15): a posteriori processes and pro-active processes that prepare the system with changeability capabilities. Iterations occur when effects propagate from the solution after evaluation, and force designers to fix problems quickly. This process is specifically used in patching/debugging scenarios. In riskier scenarios, formalized processes for change management are required. [START_REF] Jarratt | Engineering change: an overview and perspective on the literature[END_REF] present a stage-gate model for generic change processes. This process relies on the standard problem-solving cycle: problem formulation, problem analysis, synthesis solution(s), evaluation and implementation.

Design reuse

The difference between engineering change and design-from-scratch scenarios is the obliged consideration for impacts on the existing system. Most of the time, engineering design is adaptive or variant design from existing components or knowledge. This especially echoes today's societal challenges for sustainable development in which raw resources are used for cyclic development processes. An efficient design process should find the optimal balance between the global cost of developing components and the cost of reusing existing ones. That is why design reuse has been a trendy topic in design research literature. [START_REF] Eckert | Algorithms and inspirations: Creative reuse of design experience[END_REF] provide a model for evolution and adaptation in design involving selection of sources and new generated design with adaptations of the sources (i.e. modification, addition, subtraction or translation). Reuse of existing components, evolution of versions of design, or design patterns are examples of concepts focusing on different type of sources. Modification-based design approaches involve the addition, removal or internal modification of modules; parametric design, case-based reasoning and shape grammar [START_REF] Tomiyama | Design methodologies: Industrial and educational applications[END_REF]. Due to change and variety of customer needs, numerous approaches for variety management have emerged [START_REF] Elmaraghy | Product variety management[END_REF] in taking benefit of commonalities between product variants. Architecture design strategies for reuse have been developed as product family [START_REF] Jiao | Product family design and platformbased product development: a state-of-the-art review[END_REF] but also strategic processes for reuse as Product Line Engineering (PLE) or Product Family (PF) engineering. A PF (or a product line) is defined as a group of products that share the same platform, namely the same group of assets. The main interest of product platform for design is the reuse of common assets for new product variants of the same family. [Chalé Gongora et al., 2015] presents a new reuse strategy called "system and subsystems catalogue of building blocks" in which reuse does not only take place with product family assets, but also with project assets.

Pro-active design for changeability

The evolution of large-scale complex systems over a long lifetime has pushed designers to seek after changeability as a lifecycle system property. Design for changeability enables the system to pro-actively cope with engineering change in an easy and low cost manner. [Cardin, 2014] proposes a taxonomy of procedures supporting design for changeability (called flexibility in this research domain) in which various approaches from the literature are classified.

1. Baseline design: the initial design is performed from an engineering design process 2. Uncertainty recognition: uncertainty scenarios and change drivers regarding system lifecycle are captured 3. Concept generation/exploration: flexible/changeable systems design concepts are determined and synthesized 4. Design space exploration: detailed design and configurations are quantitatively evaluated in the design space domain (multi-attribute tradespace exploartion).

Based on this scheme of procedures, some approaches covering the core design stage for changeability (i.e. "concept generation" in stage 3) are reviewed in table 2.6 in both design engineering and manufacturing system design domains. Thorough review of exclusionary approaches supporting the stage (1), ( 2) or ( 4) is beyond the scope of this literature review and was already tackled in [Cardin, 2014]. Three models covering the stage 3 are observed without being exclusive to each other:

-a) Analysis b) Synthesis (especially present in the manufacturing system design literature) [START_REF] Al-Zaher | RMS design methodology for automotive framing systems BIW[END_REF]] [Francalanza et al., 2014] -a) Identification of areas with embedded flexibility b) Generation of new opportunities for flexibility [START_REF] Mikaelian | Real options in enterprise architecture: A holistic mapping of mechanisms and types for uncertainty management[END_REF]] [Cardin et al., 2013] -a) Change strategy generation b) Change enabler identification (the change ontology presented in section 2.3.2 can support these steps) [Cardin, 2014] [Francalanza et al., 2014] [Allaverdi et al., 2015] The maturity of the design stages regarding their supporting tools and methods is indicated by grey cells in table 2.6, and is described hereinafter.

Baseline Design (1) The baseline design is fully supported by engineering design literature (e.g. Systems engineering, AD, TRIZ, Pahl and Beitz, Quality Function Development (QFD) etc.); there is no need to elaborate them further in the scope of this work.

Uncertainty Recognition (2) Uncertainty recognition is supported by an uncertainty model using binomial lattice in [START_REF] Mikaelian | Real options in enterprise architecture: A holistic mapping of mechanisms and types for uncertainty management[END_REF]. The Engineering System Matrix (ESM) methodology in [START_REF] Hu | Generating flexibility in the design of engineering systems to enable better sustainability and lifecycle performance[END_REF] characterize uncertain drivers in terms of likelihood of dependency relationships, uncertain scenarios and cost of change from expert knowledge and historical data. [START_REF] Cardin | Empirical Evaluation of Procedures to Generate Flexibility in Engineering Systems and Improve Lifecycle Performance[END_REF] suggest interviews and discussions with designers/engineers/managers to elicit uncertainty sources. [START_REF] Al-Zaher | RMS design methodology for automotive framing systems BIW[END_REF] underline the need for evaluation of engineering changes based on data from product, process and system. In order to get anticipated knowledge about future architectural evolution, [START_REF] Fricke | Design for changeability (DfC): Principles to enable changes in systems throughout their entire lifecycle[END_REF]] list practices such as forecasting, extrapolation, scenario techniques or pattern recognition.

Design Space Exploration (4) The evaluation between flexible solution candidates is performed using expected Net Present Values (NPV) in [START_REF] Mikaelian | Real options in enterprise architecture: A holistic mapping of mechanisms and types for uncertainty management[END_REF]. [START_REF] Hu | Generating flexibility in the design of engineering systems to enable better sustainability and lifecycle performance[END_REF] suggest monte carlo simulation to generate and run stochastic scenarios leading to a distribution of possible NPV lifecycle performance. A computer/analytical Discounted Cash Flow (DCF) model using NPV metric is developed in [START_REF] Cardin | Empirical Evaluation of Procedures to Generate Flexibility in Engineering Systems and Improve Lifecycle Performance[END_REF], so that the anticipated lifecycle performance of flexible design concepts are quantified.

Concept Generation (3) The most interesting point regarding this research work is the tools and methods supporting stage 3. [START_REF] Mikaelian | Real options in enterprise architecture: A holistic mapping of mechanisms and types for uncertainty management[END_REF] use an ad hoc approach to identify real options candidates and prescribe the use of enterprise architecture models such as DSM [START_REF] Eppinger | Design structure matrix methods and applications[END_REF]. To identify candidate elements needing flexibility ("flexible design opportunity identification"), [START_REF] Hu | Generating flexibility in the design of engineering systems to enable better sustainability and lifecycle performance[END_REF] develop a bayesian network model, and predict the risk susceptibility of each element. For the "flexible design concept generation", they refer to [START_REF] Mikaelian | Real options in enterprise architecture: A holistic mapping of mechanisms and types for uncertainty management[END_REF]'s ontology without suggesting tools or methods to do so. In the analysis phase described by [START_REF] Al-Zaher | RMS design methodology for automotive framing systems BIW[END_REF], the impact of engineering changes and the identification of dependencies result in the development of a DSM. Change Propagation Index (CPI), originally introduced by [START_REF] Suh | Flexible product platforms: framework and case study[END_REF], is calculated for each component, so that multipliers (CPI > 0) are identified as candidate components for flexibility. The synthesis phase is described to be the mapping process from requirements to product's key elements. They are represented in an Hybrid DSM composed of design tasks and design configuration elements. [START_REF] Allaverdi | Identigying flexible design opportunities: getting from a procedural to an execution model[END_REF] present a comprehensive meta-model named Flexible Design Opportunity (FDO) Data Matrix, in which different types of elements relate to each other (i.e. change drivers, system requirements, change objects, system modules, transition and change strategies, change enablers). These factors are elicited during interview sessions. To generate decisions, approaches are usually framework or principles-based without integrating mature tools. In order to simulate creativity to generate flexible concepts, [START_REF] Cardin | Empirical Evaluation of Procedures to Generate Flexibility in Engineering Systems and Improve Lifecycle Performance[END_REF] suggest some ideation procedures: an explicit training (i.e. short lecture on the topic of flexibility) and a prompting mechanism to identify uncertainty drivers, generate flexible strategies, enable flexibility in design, and identify decision rules to manage flexibility. The prompting mechanism is generic enough to be usable in different domain contexts. [START_REF] Francalanza | Deriving a systematic approach to changeable manufacturing system design[END_REF] suggest a framework for the design of changeable manufacturing systems: 1-Analysis requirements from product, manufacturing process and business viewpoints 2-Synthesis of changeability levels and enablers through manufacturing system design elements 3 -Simulation and validation. Changeability principles are presented in [START_REF] Fricke | Design for changeability (DfC): Principles to enable changes in systems throughout their entire lifecycle[END_REF], but the guideline-approach acknowledges that it does not provide support to design of changeable architectures and to implement principles.

Research gap analysis

Whereas system design processes have gained maturity, and knowledge about changeability has been well explored in literature, there is still a lack of integration between these approaches. The problem of "systemic design of changeable manufacturing systems" has been tackled under different research angles, namely change in the manufacturing system domain (section 2.1), systemic design approaches in the manufacturing system domain (section 2.2) and changeability in the system engineering design domain (section 2.3). Five remaining lacking areas have been successively emphasized and are summed up hereinafter.

(1) Restricted configuration definitions In changeable manufacturing system literature, approaches suffer from poor and unrealistic configuration definitions (section 2.1.5). Segmented domains do actually reflect isolated manufacturing system design activities (e.g. arrangement of machines, machine specifications, process sequencing, line balancing). Reported motivations for systemic approaches (section 2.1.6) and the two established ontologies for manufacturing system design processes (section 2.2.2) and for manufacturing systems (section 2.2.3) demonstrate the need for holistic considerations especially when change propagate. Similar critical statements about restricted design viewpoints in engineering change design are reported in section 2.3.1.

(2) No methodology covers the synthesis of change drivers, strategies, enablers and objects Even though enabler concepts are recognized as relevant to support changeability in the ontology of change (section 2.3.2), they are not systematically integrated within complex architectures. No methodology continuously supports the generation of changeability strategies and enablers subsequent to the identification of areas for changeability (section 2.3.3). There is often a discontinuity between the analysis of changeability stage and enabler design stage; the synthesis activity seems to be restricted to human expertise and creativity. This lack explains the remaining difficulty for engineers to design and embed changeability in complex systems. Changeability is often perceived as belonging to a strategical/objective level rather than to an architectural design level.

(3) No lifecycle considerations in integrating engineering change and re-design for changeability Approaches for engineering change focus exclusively on either a posteriori engineering change or a priori design for changeability (section 2.3.3). Plus, design for changeability is often considered as a preliminary one-shot project. In reality, a posteriori engineering change (i.e. re-configuration) and a priori design for changeability depend on each other and occur all along the system lifecycle. In the manufacturing system literature, although changeability has generated extensive efforts about definition of paradigms (section 2.1.1), the majority of design approaches exclude design for changeability (section 2.1.3) but focus on re-configuration design. The very few configuration design approaches including changeability criteria are restricted to short-term flexibility (section 2.1.4).

(4) Lack of methods and tools for systemic design and engineering design for changeability The observation made about the lack of described approaches for intra-domain manufacturing system design (section 2.2.1) can be generalized: because systemic motivations raise concerns about incomplete, open-ended, conceptual, architecturally complex and thus unstructured design problems, describing methods and concrete tools fail to be applied, to the detriment of frameworks and prescribing approaches. With regards to engineering design, section 2.3.3 reveals that approaches covering changeable concept generation (stage 3) prescribe principles, frameworks and ontologies but do not integrate methods or tools whereas they largely do for stages 2 and 4. The only identified tools for stage 3 rely solely on DSM [START_REF] Eppinger | Design structure matrix methods and applications[END_REF] with change propagation analysis. They intend to describe architectural properties regarding change and support the identification opportunities for changeability, but are not enabler identification methods as often mentioned in literature.

(5) No manufacturing system design knowledge in systemic design for changeability processes It has been recognized that systemic approaches for changeable manufacturing system design should subscribe to system engineering design literature. But the risk of doing so is to push manufacturing system design knowledge away. The reviewed approaches subscribing to systemic design for changeable manufacturing systems also exclude domain-dependent knowledge and are therefore classified in section 2.3. This research gap between manufacturing system ontology and engineering change methodologies is beyond the scope of this work; it would have required the development and the management of an Knowledge-Base (KB) regarding existing changeable solutions in manufacturing system domain.

Thesis concept: methodology for changeable systems

The thesis concept is a systemic methodology to support the design and the reuse of complex and changeable manufacturing systems throughout the system and project life-cycles. Acknowledging the complexity of manufacturing system architectures, design processes and design of changeability properties, this thesis subscribes to an engineering system design approach. It is stated that changeability should not be limited to organic system components anymore, but enlarged to the whole set of design elements involved in the design process. Various requirements for the thesis concept are elicited as they refer to the identified research gaps:

Requirement 1 Design processes should apply from the conceptual phases to the detailed ones, and through the various design activity viewpoints (manufacturing system design dependent and independent). (1st research gap)

Requirement 2 System architecture and configurations should be defined regarding their various domain definitions, so that changeability can be designed and reused at the right level. (1st research gap)

Requirement 3 Design for changeability should integrate analysis and synthesis activities together. (2nd research gap)

Requirement 4 The methodology relies on a lifecycle model for changeable systems in which design for changeability (pro-active design for changeability) phases and re-design (a posteriori engineering change) phases succeed each other (see figure 2.15). Re-configurations phases can occur in both time scale and space scale. (3rd research gap)

Requirement 5 Faced with the reality of complex and shorter-time limited development projects, an efficient design support is a key enabler for the successful design of changeable manufacturing systems. The type of support for design should be at the same time generic enough for any manufacturing system design project and concrete enough for decreasing the perceived complexity of the design processes. It should also be able to be personalized in different design project instances and scalable to different degrees of design specification during the design project lifecycle. (4th research gap)

Research questions

This thesis aims to answer the following Research Questions (RQ); they relate to the stated requirements, themselves deriving from analyzed research gaps. Research questions are clustered within three areas: system engineering design, design and management of changeability and support design. The chapter 4 answers RQ1a & RQ1b and the chapter 5 RQ2a, RQ2b & RQ2c. A first answer to RQ3 lies in the thesis concept statement. The term "methodology" actually refers to a certain type of support design embodiment subscribing to several definitions: 1-it covers the system lifecycle [START_REF] Friorèse | Découvrir et Comprendre l'Ingénierie Système[END_REF]; 2-it includes a collection of related processes, methods, tools, standards and procedures [Estefan, 2007] [Paulk et al., 1993] [Bloomberg and Schmelzer, 2006]; 3it is "general and concrete", namely concrete design procedure at the process and activity level without restrictions to a specific class of artifacts [START_REF] Tomiyama | Design methodologies: Industrial and educational applications[END_REF]. Perspectives regarding future embodiment types (e.g. tools support, artificial intelligence, experts mechanisms) are specified in the conclusion chapter 7.

System Engineering design

RQ1a Considering changeable manufacturing systems as large-scale and long-term systems, which design process model should be taken as a reference to capture relevant viewpoints for their design ? (Req 1 )

RQ1b What types and levels of design artifacts should be formalized to support design in a systemic way ? (Req 2 )

Design and Management of Changeability

RQ2a How should changeability decisions be supported from analysis to synthesis ? (Req 3 )

RQ2b How should changeability capability be reused ? (Req 3 ) RQ2c Moving beyond a unique "one-shot project" for changeability, how should phases of "design for changeability" and "re-design in reusing changeability" be articulated in a lifecycle model for changeable systems ? (Req 4 )

Design support

RQ3 What type of design support embodiment will be successful regarding previous requirements? (Req 5 )

Evaluation criteria for the design methodology

The expected outcome is an integrative and supportive design methodology that should enable:

1. Increase ultimate changeability potential in systems 2. Guarantee a better consistency in the design process decisions to embed or reuse changeability 3. Reduce the apparent complexity with satisfactory support for designers System engineering formalism for change representation "I see life as increasingly complex, vivid, colorful, crazy, chaotic. That's the world I write about... the world I live in."

Julia Glass

Motivations for a new architecture definition

The complexity of systems is perceivable when change propagation becomes difficult to manage within the system. Designing changeability and taking benefit of it all along the system lifecycle implies being able to understand those propagated changes and take decisions accordingly. Facing the challenge of complex systems, the core question is what design views, what type of engineering objects and which levels are required to be explicit, so change propagation is relevantly represented.

In products or systems, change propagation is often considered in a physical way, and most of the time in a geometrical way [START_REF] Ahmad | Change impact on a product and its redesign process: a tool for knowledge capture and reuse[END_REF]. Considering large-scale systems, change can be initiated and propagated at any stage and level in the design process: problem domain, solution domain, conceptual stage, detail stage, and at any design view etc. The domain of representation for change in design cannot be limited to a physical view without taking the risk of leading to an unrealistic representation. Although several definitions of system architecture are restricted to a physical organization of physical components, [Ulrich, 1995] gives this definition: "a product architecture is composed of its functional structure, its product structure and also the transformation between them". The focus is not anymore on final solution components, but on any system engineering artifacts arising within the design process, from system's functions and to final structural specifications. Going further, the standard [ISO/IEC/IEEE 42010, 2011] for systems and software engineering defines an architecture as "fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution". The standard differentiates between the architecture as a conception of a system, not necessarily written down, and the described architecture regarding any SoI. An architecture is entailed in a document, a repository or a collection of artifacts for demonstrating how it meets the needs of system's stakeholders. This definition goes beyond a structure of physical components, a functional structure and a transformation between them. It goes also against a common distinction between system architectures and organic structures, referring to the organization of physical components.

Accordingly, change analysis literature has suffered from the same restricted architecture definition, but motivations for enlarging the study of dependencies from usual physical domain to other domain definitions have been observed. For instance, [START_REF] Eckert | Change and customisation in complex engineering domains[END_REF] study change propagation between direct parameters, functional parameters, behavioral parameters, or [START_REF] Ahmad | Change impact on a product and its redesign process: a tool for knowledge capture and reuse[END_REF] study it between requirements, functions, components and detail level. The proposed formalism aims to enlarge the spectrum of interaction types to any system engineering artifact which would be likely to trigger change propagation in a large-scale system as manufacturing system. In addition to enrich the representation domains for changeability analysis, a system engineering formalism has plenty of other benefits. First, it naturally decreases the perceived complexity of designers in making explicit the various system engineering objects. It also enables the use of supporting design tools; the potential for being supported by intelligent design tools is increased in rationalizing and formalizing complex design processes. Drawbacks have been observed through failures of system experts; traceability supports are not useful for designers in case the complexity of engineering knowledge fails to be represented.

Tracing system engineering artifacts first requires a definition of the design process model to which the formalism relates to (section 4.2). Based on it, the types of exchanged artifacts are presented (section 4.3) and a taxonomy of their relationships reveals their different propagation types (section 4.4). Tools for representing those dependencies are developed (section 4.5). Since this work constitutes the preliminary foundation for a later intelligent system design, traceability rules and requirements for services of the support system are finally specified (section 4.6). The left decent of the V-model illustrates the definition system process -from general needs to design specifications -whereas the right ascent represents the project integration process that successively refers to the preliminary left side deliverables -from implementation, integration, testing, to installation. The research interest for this work is about design process models, namely the left descent model. Needs are first formalized into a requirement baseline that characterizes the design problem. Then a functional solution is found as a composition of logical concepts and principles as a preparatory picture of the future physical system. The definition of the physical architecture is finally performed in the synthesis stage, ending with detailed design specifications that will later be required within the integration stage.

Two motivations explain the broad interest for the V-model in design problems for complex engineering systems. First, it encourages to spend time during the design phase to get a clear vision of solutions rather than precipitating the 'Integration Verification Validation' (IVV) phase that would cause unjustified costs and investments. Also, because analysis of logical descriptions precedes physical description, architecture definition is encouraged to be first elicited with solution neutral terms. It ensures that the designed system serves exactly the intended purpose. The required investments are functionally justified, which is a major issue with complex and costly system.

Limitations of the V-model

Despite its popularity, the V-model is open to criticism in both industry and research areas. Its sequential representation is useful for understanding purposes, but it fails to reflect the reality of non-linear design projects. Contrary to an ideal thinking, no design process is purely solutionneutral. German standard design processes [START_REF] Vdi | Systematic approach to the development and design of technical systems and products[END_REF][START_REF] Vdi | Systematic approach to the development and design of technical systems and products[END_REF] along with German research [START_REF] Pahl | Engineering design: a systematic approach[END_REF] assent to a progressive and refined design process from conceptual design solutions to embodiment and final detail design. Moreover, the design process is highly iterative between the problem domain and the solution domain. Often, a solution choice satisfies a set of requirements, it then influences new requirements which themselves are later satisfied by new solution choices, and so forth. Similar observations have motivated the formalism of lifecycle development models as incremental or evolutionary models. The fundamental principle is that requirements always vary unexpectedly during development projects. One shot projects do not exist and incremental improvements are always needed. Agile methods prescribe design projects to be organized within fix lengths iteration (called sprints); each sprint has components of analysis, design, and implementation. In the design theory research domain, several approaches state that a good design process is necessarily iterative between functional domain and physical domain. It comes from the apparent impossibility to disregard any physical solution during the functional analysis. In [Micouin, 2006], the interlaced processes between requirement engineering, functional design and physical design are opposed to pure functional design approaches in which existing operational characteristics are not considered. The FBS Framework [Gero, 1990] prescribes iterative processes between Function (F), Behavior (B), and Structure (S). AD [Suh, 1998] encompasses the zigzagging decomposition process between Functional Requirements (FRs) and Design Parameters (DP) in physical domain. Those dependencies are represented in a Design Matrix (DM) in which axiomatic statements for design can be verified.

Requirements for a new design process model

Based on the previous observations, a new design process model is suggested. The following statements and figure 4.2 describe characteristics it must encompass:

1-Iterative between problem and solution domain activities. A complex system is defined through several iterations.

2-Progressive. Incrementally, the design structure is more and more detailed from a conceptual level to the final detail level which corresponds to the satisfactory level for physical specifications.

3-Integrative between related design sub-problems. Independent design sub-problems can be treated concurrently, otherwise collaboration is required between them.

Problem Formulation

Proposition of a progressive and iterative design process model

Process description The progressive, iterative, and collaborative framework is presented in figure 4.3. From need formulation to system specifications, design activities continuously exchange information from generic ones to detailed ones. There are two main types of existing activities: analysis in the problem domain and synthesis in the solution domain. In the analysis phase, business managers and stakeholders are responsible for the problem definition activity formalizing initial needs as initial requirements. Then, requirement engineers are responsible for requirement analysis in deriving new requirements and documenting them into the Functional Baseline (also called System requirements Specification). In the synthesis phase, designer experts are responsible for allocating requirements to individual structural elements and detailing them within the element design engineering activity. Finally, the core of the synthesis process takes place in the architecture engineering activity in which system architects organize and arrange structural elements in order to form a consistent architecture. This scheme can be performed concurrently for various sub-problems and from different levels in the system. The process is incremental -excepting the problem definition activity which occurs only once at the beginning process -since new requirements can be derived from solution decisions. ). The behavior in the problem domain refers to the expected behavior, and the behavior in the solution domain to the actual behavior [Gero, 1990]. A structural view in the problem domain corresponds to a functional architecture that specifies structural requirements for the architectural solution. The alternation of views inherits from SysML formalism [START_REF] Friendenthal | A practical guide to SysML: the systems modeling language[END_REF]; it prescribes behavioral diagrams (e.g. use case, activity, state machine, sequence diagrams) and structural diagrams (e.g. BDD, iBDD). All along the design process, iterations refine the problem and solution formulations from conceptual to detailed ones as illustrated in figure 4.4. Naturally, the more the design project evolves through successive analysis and synthesis, the more it goes from conceptual design stages to detailed ones.

Requirement definition

A requirement is defined as an agreed-to obligation statement that specifies a need, a capability or a condition that should be satisfied, a function that the system must perform, or a performance condition a system must achieve [START_REF] Friendenthal | A practical guide to SysML: the systems modeling language[END_REF]. It characterizes the system in the problem definition domain. Complete and accurate requirement statements are therefore fundamental for the success of design projects. The different features characterizing requirements are presented in the following list:

Requirements attributes: unique identifier, short title, priority, risk, source [Young, 2004] Requirements necessary characteristics: necessary, singular, correct, unambiguous, feasible, appropriate to level, complete, consistent, conforming, verifiable, ranked for importance and stability, modifiable, traceable [IEEE Std 830-1998, 2009] Requirement engineering sub-activities: Need clarification, requirement elicitation and capture, requirement analysis, requirement verification and validation, requirement modification, allocation and management [START_REF] Fanmuy | Recommandations pour l'élaboration d'un référentiel d'exigences techniques[END_REF] Levels of requirements-driven design: stakeholders' requirements, program requirements, initial high level design requirements, single option high level design requirements, detailed design requirements

Requirements types:

-Business requirement initiates the design in specifying: problem, finality or goals, mission and objectives [START_REF] Penalva | Sagace: la modélisation des systèmes dont la maîtrise est complexe[END_REF].

-Functional requirement specifies what the system should do in terms of functionality, often referring to a particular aspect of the system (< the system must do A > or < the system should have A f unctionality >). Functional requirements directly drive system design. They are necessarily satisfied by structural solution elements.

-Behavioral requirement. Similarly, a behavioral requirement gives details on the use of a functionality in describing cases, modes, scenarios where functional requirements are realized. Behavioral requirements can result in new functional requirements, or refine already defined functional requirements (see figure 4.6). Like functional requirements, they prescribe what the system must do.

-Non-functional requirement, quality requirement, emergent property or -ities requirement, specifies an overall lifecycle system property of the system. It generally specifies what the system is supposed to be (< T he system should be X >), rather than stating what it is supposed to do. Examples of performance qualities in the manufacturing system domain are: ROI < 12 months ; production capacity = 14400 units/weeks; cycle time of production < 30 sec; changeover time < 1/10 production time per batch; equipment availability = 98%; T RS 80%. Those requirements cannot be exhibited or satisfied by isolated elements. They rather impact the whole architecture and depend on interactions between elements. Usually, architecture engineering casts non-functional requirements and derives them into functional and behavioral requirements, whereas functional requirements are satisfied during the allocation to structural elements and element design engineering.

Structural block definition

A structural block is a modular unit that represents an element of the system architecture, either an internal constituent of the system, or an interface with the system boundary. It describes and specifies the selected element in the solution domain. It can be a structural component in the physical sense, a design parameter, a program or an operation. As long as the level of definition of the structural elements is not judged to be satisfactory regarding the targeted application, the solution must be detailed. Regarding the context and the involved domain, their definitions fall into the responsibility of designer specialists. Three types of structural blocks are described: logical (software), physical and hybrid. It is here clearly stated that regardless its abstract level, a structural block belongs to the solution domain and responds to a set of requirements belonging to the problem domain. Reciprocally, requirements can also derive from physical solution choices.

Rational domain for change propagation representation 4.4.1 Interest for tracing system engineering artifacts

Enlarged domain definition for changeability Two types of architectures are defined based on the earlier defined framework (see figure 4.3). The solution architecture is defined in the architecture engineering activity: structural elements are arranged together modeling how the system shall be later implemented. The rationale-based architecture is defined all along the design process in which all successively defined system engineering elements are connected to each other. It traces the results of the iterative and progressive design flow, namely requirements and structural blocks created in the problem domain and the solution domain.

The resulting dependencies between these two domains induce vectors for change propagation. As they cannot be retrieved only by analysis of mechanical adjacent elements, a new formalism for coupling traceability between system engineering artifacts is proposed. It enlarges usual restricted representations in the physical domain to any type of system engineering coupling. Rationale-based system architecture reflects the mapping from problem-domain elements to solution-domain ones. The formalism constitutes the preliminary foundation for definitions of design domains for later changeability analysis and synthesis. In doing so, change can be initiated and propagated from any system engineering element of any type and at any level.

Design rationale To make artifacts traceability possible within the global project system, any structural block shall be represented according to its functionality and requirements it is related to, in addition to its operational or physical description. Design rationale approaches share the same goals in describing the intention behind the choices all along the design process. Degrees of design rationalization can be multiple since applications are context-dependent. The evaluation of need for traceability support and the decision of a taxonomy of engineering objects and relations is an important preliminary work to any industrial project. Domain-independent representation approaches that record and reuse design rationale are reviewed by [START_REF] Regli | A Survey of Design Rationale Systems: Approaches, Representation, Capture and Retrieval[END_REF]: tools for recording and visualization engineering objects are either browser of hierarchy structure, graph diagrams, or matrix. As an example of systemic design rationale for manufacturing system engineering, [START_REF] Cochran | A decomposition approach for manufacturing system design[END_REF] have developed the Manufacturing System Design Decomposition (MSDD) based on the AD approach [Suh, 1998]. It integrates relative design disciplines (i.e. information systems, manufacturing strategy, supply chain, human work system design, facility design process, equipment design and product design) and trace the manufacturing system design process in terms of relations between design objectives (i.e. Functional Requirements) and solutions (i.e. Design Parameters). The Systems Engineering discipline also recognizes that managing artifacts is crucial for developing complex systems. Requirement engineering is responsible for requirement elicitation. It defines the scope of the project, ensures that everyone is involved, justifies any expenditure of fund or effort, enables to report on progress and indicates when the project is finished. Configuration management tools also aim to trace project artifacts for better support of design processes.

System Engineering relationships Physical Rationale

Association Hierarchical Problem-Solution Requirement Different types of relationships between system engineering artifacts are reviewed in the taxonomy presented in figure 4.7 and deepened in the following paragraphs. They establish a vector type for change propagation in any engineering system.

Physical association relationships

Physical connectivity can be analyzed to infer on change propagation paths within the system. It is represented under the < associate > link. [START_REF] Eckert | Change and customisation in complex engineering domains[END_REF] review different kinds of parameters that < associate > elements between parts and sub-systems: geometry, torque, temperature, heat transfer, vibrations, material parameters, information etc. An example of linkage within manufacturing systems is given in figure 4.8.

Hierarchical relationships

Since the design process flow goes from the system level definition to the detail level, final architecture and components depend on their predecessor in the design process. The success of hierarchical representation such as SADT/IDEF0, hierarchical structures or the common four layer representation (system, sub-system, assembly, component) testifies of the top-down flow rationale occurring in design. The < compose > link illustrates the composition link between structural blocks, meaning that one element can be considered as a design parameter of another one. In addition to composition, design intuitively goes from abstract solutions (conceptual design) to detailed solutions (detail design) [START_REF] Pahl | Engineering design: a systematic approach[END_REF]. Inheritance relationships are also useful to follow the progress of the design process from abstract to proprietary instantiated solutions. They are traced using the < ref ine > link. Structural blocks can be characterized by genericity levels, in which each child < ref ine > its parents. For example in figure 4.9, a structural block can progressively be refined as a "production unit", a "CNC machine", a "5-axis CNC machine" and a "reference model from a specific constructor". All of these elements represent the same block in the system, but correspond to different levels of details. These composition and inheritance relationships (see figure 4.10) reveal dependencies between project structural blocks, causing a "top-down" change propagation pattern between system's blocks. The < satisf y > relationship is dedicated to blocks whose essential reason to exist are these requirements (see figure 4.12). It actually reveals the heart of design: design solutions are required to exist in order to respond to expressed needs. Inversely, any structural block is driven by a functional motivation. The < allocate > relationship makes explicit dependencies between requirement and existing block. It indicates that a requirement is referring to existing structural blocks. It might result in: 1-< derived > requirements (figure 4.13) 2-< ref ined > blocks that shall satisfy the allocated requirements 3-< specif y > relationship between the requirement and the structural block if the requirement is judged satisfactory for the specification formulation of the allocated block. Usually, behavioral requirements are likely to be used as design specifications for logical structural blocks (e.g. PLC, computer, software application, micro-controllers etc.).

Summary of the rationale link relationships

According to the previous taxonomy, the three types of link relationships in rationale-based architectures are: requirement-requirement relationships, requirement-block relationships, and block-block relationships. Figure 4.14 sums up the formalism. Figure 4.15 illustrates it with an example of a rationale-based architecture. The type of link relationships relate to specific activities in the design process. Rules concerning their creation are elicited:

-Allocation to structural element & element design engineering: all requirements shall be satisfied or allocated by structural blocks.

-Requirement analysis: an incomplete requirement result in a requirement analysis process for deriving and refining new requirements.

-Architecture design: all structural elements shall be arranged and connected together through physical or hierarchical relationships. DSM is a tool offering a representation of system dependencies between entities from the same domain. Weights for different levels of dependencies can also be attributed. MDM is an extension of DSM modeling in which element dependencies are visualized simultaneously in different domains. [START_REF] Eppinger | Design structure matrix methods and applications[END_REF] present various applications of DSM and MDM in three domains: product, process and organization. In accordance with the rationale-based architecture previously presented, dependencies must be traced between requirements and structural blocks. For this purpose, the MDM is applied to problem domain and solution domain (see figure 4.16). This tool is preliminary to changeability analysis and synthesis activities, later developed in chapter 5.

Problem domain

Solution domain

Problem domain Solution domain

Process for tracing system engineering relationships

The rationale-based architecture is traced all along the design process. In fact, intermediate design artifacts are required to support the progressive and iterative design process; tracing them improves the understanding of the design process, the reuse of existing design artifacts and enables to follow change propagation through the system's artifacts. Most of the time, rationale-based architectures are hardly complete since blocks and requirements may be implicit during the design process as they belong to the designers expertise knowledge. Another reason can be the multitude and the heterogeneity of ill-connected models. This complexity is actually inherent in the design process of complex products. Linking dependencies between all requirements or blocks turns out to be difficult. Two case scenarios for tracing system engineering artifacts relationships are considered:

-Direct traceability: artifacts are traced during the synthesis process (i.e. decomposition and inheritance of solutions, solutions satisfying problems, problem deriving or allocating to selected solutions) or the analysis process (i.e. decomposition and derivations of requirements).

-Indirect traceability: models act as informal definition of requirements and structural blocks.

As an example, an activity diagram for a manufacturing system (see appendix A.5) involves requirements on expected sub-behaviors to the system's components (robot, charging system, press, engraving machine and unloading system). From this model, implicit requirements and blocks are retrieved in the explicit rationale-based architecture in figure 4.17.

Act

Perspectives on services of a design support system

Driving knowledge in the system engineering process may come from two types of sources, either from the engineers' skills or from a supporting expert system. In this last option, the rationale-based architecture does not only result from manually traced artifacts, but also from the collaboration with the design support system. This section opens research gates on services that such support systems should provide.

Support system services

Based on the progressive and iterative design process model, the required services of an intelligent support system is described. Figure 4.18 specifies the services under two activity viewpoints: the evaluation and the analysis. It relies on the paradigm analysis/synthesis/evaluation for modeling system engineering process. Synthesis of system engineering artifacts is manually driven by engineers. Their role is to define and organize artifacts within problem and solution domains (see figure 4.3). The support system is responsible for analyzing and evaluating the requested project elements. Analysis defines design problem formulations and allocates them to the appropriate experts. Once design choices have been made, the design support system evaluates them in querying knowledge from the rationale-based architecture. For this purpose, four services are used:

Check existence rule () The method checks the formalism consistency between requested elements. If inconsistency is found out, the engineers' proposition is refused.

Dependency analysis ()

The method retrieves the elements impacted by engineers' decisions. Knowledge about involved artifacts with the design process is upgraded. If a data-mining algorithm is implemented, three phases can be differentiated: training phase, validation and test phase, and application phase (see figure 4.19).

Completeness evaluation () The method evaluates the completeness of the rationale-based architecture. If it is complete, the design process can be stopped.

Problem formulation definition () After retrieving information about the incompleteness of the rationale-based architecture, new design problems are formulated. It relies on the completeness evaluation () and the dependent analysis () that infer impacted artifacts. Based on that, the problem formulation is delivered as request to engineers. If the analysis is userdriven, the problem formulation definition () is not performed.

Support system

If The sequence diagram in figure 4.19 represents interactions between external actors (requirement engineer, system architect or design experts) and the support system according to the previously defined methods. Engineers have three possible options to initiate the evaluation process: enter a new project element, modify or delete an existing one. They are also in charge of feeding the system with knowledge on dependency between elements. On the other side, the support system has the responsibility to follow the successive analysis, synthesis and evaluation activities as prescribed earlier.

Rules for existence & completeness checking

In order to be usable, the rationale-based architecture is required to be complete, meaning fully traceable in forward and backward modes. In the forward traceability, any system engineering element must be traced toward successive refinement, derivation requirements and successive solutions, down to detail levels. In the backward traceability, any element must be justified and understood regarding its higher predecessors having caused or influenced its existence. Based on those needs, rules are formulated below.

Check existence () is performed with the evaluation of two rules in table 4.1.

Rules

A block must satisfy at least a functional requirement to exist A requirement must derive from at least a requirement or a block, or refine a requirement to exist Table 4.1: Existence rules Completeness evaluation () is required to alert designers at the end of the design process, and to inform about a new problem formulation definition (). As a matter of fact, relatively independent design problems must be formulated according to the incompleteness of system engineering artifacts. Table 4.2 gives a list of rules for checking completeness.

Rules

Comments A system is complete if all its elements are complete

Elements can be blocks and requirements

An element -block is complete if all of its allocated requirements are complete A refined block inherits from its father characteristics. A requirement is complete if only itself or all of its refined requirements result in satisfy relationships or specify relationships.

A requirement must be "atomic" as far as possible, meaning that it can be satisfied / specified by only one block. Once a block satisfies a requirement, it clearly says that the requirement is fully satisfied without having to discuss its completeness of realization. An allocated or deriving requirement to a block is complete if all of its refined requirements are complete toward a refining or composing block.

A requirement does not have a satisfaction obligation toward a certain solution unless it is a "child" requirement or is an allocated requirement. The completeness must be checked according to the block itself.

Table 4.2: Completeness rules

Conclusion

Studying and designing changeability with a system engineering perspective requires to enlarge architecture definitions. The progressive and iterative design process model, the formalism for exchanged system engineering artifacts and the taxonomy of their relationships are prerequisite to follow change representation in complex systems such as manufacturing systems. The representation domain for change propagation is not limited to a physical solution view, but enlarged to problem and solution domains. Systems are represented under a rationale-based architecture that connect system engineering artifacts arising from the design process, so that any link is a vector for change propagation. Tools for tracing dependencies are also prescribed as DSM and MDM. Nowadays, software editors are more and more going toward this direction as they guarantee traceability in requirements management, change & configuration management, and documentation of design project artifacts during system project lifecycle (Polarion R , IBM Rational DOORS R , PTC Integrity R , arKItect of Knowledge Inside R , RFLP -Requirements, Functional, Logical and Physical Design -traceability in CATIA Systems Master R ). The next step is to give more intelligence to support tools for design. Specifications of the support system for tracing system engineering artifacts dependencies have been given here in terms of services and rule-based approaches concerning existence and completeness checking. More perspectives are given in the conclusion chapter 7.

Chapter 5

Methodology for design & management of changeability

"If we don't change, we don't grow. If we don't grow, we aren't really living" Gail Sheehy

Introduction

Reduced lifecycle of systems and products is one of the key issues of our century marked by highly changing contexts and needs. The challenge for adaptability of manufacturing systems arises from high product variety (either functional or technical), volume fluctuation and short product lifecycle. For that, they are increasingly required to be robust or changeable so they can respond, namely resist or adapt, to new and changing needs. In large-scale system engineering projects, change can be initiated and propagate at any level in the design process from problem domain to solution domain, from conceptual stage to detail stage, and between domain-dependent or independent design views. In line with this, this thesis states that changeability shall not be only tackled in term of physical possibilities (i.e. physical connectivity of product components) but through a systemic view regarding the overall system engineering artifacts, themselves represented in the rationale-based architecture presented in chapter 4 [Benkamoun et al., 2015a].

This section relies on the previously defined formalism in which requirements (abstract or detailed) and structural components (functional, physical or detailed design parameters) continuously support the progressive and iterative design process flow between the problem elicitation and the solution formulation. Because their relationships are the vector for change propagation into system architecture, the taxonomy of their relationship types is also a prerequisite for the proposed methodologies in this chapter. Section 5.1 presents models for changeability management during the system lifecycle (i.e. during initial and continuous design phases). Two complementary processes are both necessary during system lifecycle. Redesign & reuse existing changeability process is detailed in section 5.2. The Design For Changeability (DFC) methodology is presented in section 5.3. All of these methodology prescriptions are illustrated through changeable manufacturing systems examples.

Concurrent process models for changeability management

Despite efforts to define changeability paradigms, concepts have rarely been integrated into design methodologies. Even though enabler concepts as modularity, integrability, independence or mobility have been pointed as relevant to support system's changeability in literature, they fail to stand alone as solutions. The scope, the level and connections of systems elements to which changeability needs shall relate to are critical decisions to ensure effective changeability regarding systemic view. Change propagation studies have also revealed the unpredictable and unending nature of change in complex architecture. Changeability must thus be designed at the outset of system lifecycle since this stage is marked by large and decisive design possibilities, but also all along system lifecycle through system's evolution and successive reconfigurations.

Representation of changeable systems

Changeability strategies can be deployed at any level in a system architecture. For instance at the system level, new process requirements might lead to deploy several machines coping with changing processes (i.e. flexibility) or to order a mobile robot able to adapt its travel paths (i.e. reconfigurability). At a sub-system level, a CNC machine is able to support several operations (i.e. flexibility), and may also be able to later change its level of automation thanks to robotic interfaces (i.e. reconfigurability). The ability for welcoming levels and places for changeability lies in the definition of the architecture of reference. In fact, the architecture of reference encompasses the changeable and reusable areas for system instances. Each system instance (or configuration) results from changed, redesigned or re-organized artifacts of the architecture of reference. Whereas a configuration specifies a concrete system, the architecture of reference is thus an abstract representation of current system capability, including changeability. Iteratively, re-configuration processes ensue from previous configurations and result in new configurations, but their easiness depends on their below architecture of reference.

Scales for re-configuration scenarios

Redesign or re-configurations phases can occur at two different scales. The system undergoes successive structural changes over the time scale. This temporal view is often adopted when only one system is considered. But reconfigurations can also take place in the space scale. As examples based on observations in some multi-national companies, common strategies are to build several versions of a same plant all around the world based on a generic plant concept. In this case, the architecture of reference induces several system configurations that will then have their own life-cycles. The two types of architecture of reference for these two scales of changeability are represented in figure 5.1. The architecture of reference in space scale results in two different configurations Conf 0 and Conf 0'. Each of them relates to its own architecture of reference in time scale, which will be reused for the later configurations.

Representation model of a changeable system

Each instance that results from a redesign process characterizes a new configuration of the system. Similar to PF and PLE paradigms in which a platform or a product line can lead to a set of product variants, the configuration is defined here as a variant of the architecture of reference. In enlarging changeability concepts to any system engineering project elements, the approach follows PLE path. In PLE, product variants of product line are represented as configured assets, where assets can be any element following from the engineering process (requirement, model, design source code, test case etc.). According to [START_REF] Put | [END_REF], any product can be represented by: common modules with the product line, instantiated modules from pre-defined variation points of the product line, and specific modules. Like a platform, an architecture of reference encompasses existing artifacts to form the changeable basis from which system instances can be defined. The platform concept is thus analogous to the architecture of reference, and product variants are like configurations of the system. The changeable system and configurations are represented figure 5.2. A system configuration is composed of common modules and changeable modules from its architecture of reference, and also its own specificities. The particularity of this model is that changeable modules are not necessarily pre-defined flexible modules, offering accessible knowledge on the existing variability, but they can be enablers providing structural ability to support change (i.e. reconfigurability [START_REF] Koren | Reconfigurable manufacturing systems[END_REF]). Changeability is embodied in the characteristics of the architecture of reference. The manner to design, then access and retrieve this knowledge is one of the main challenges for design and reuse changeability.

Review of reuse and leverage techniques for changeable system design

Redesign, reconfiguration and propagating changes are more common methodologies in literature than DFC. However this last one is a prerequisite to make rapid, easy and successful redesign projects. Considering changeability as a capability that shall be at the same time designed and reused through successive reconfiguration occurrences, the presented strategy encompasses both of these concurrent activities. The key idea for defining a new engineering process for changeability is that new configurations shall reuse existing changeability capabilities, and at the same time the architecture shall be able to undergo upgrades for changeability. This paradox in changeability design results in an iterative and convergent approach between "reuse" and "leveraging" activities.

Four possible strategies for configuration design (i.e. reuse process of existing changeability) and changeable architecture of reference design (i.e. leveraging process on configurations) are presented.

Two reuse strategies for changeable systems management

Opportunistic reuse Since a changeable system will undergo successive configurations, each configuration can be viewed as a reference for its deriving configurations. The reuse process is therefore opportunistic on the previous configuration source. According to the model in figure 5.3, common modules are the ones which have been copied without being changed, changeable modules are those which have been re-arranged, and the specific ones are the new modules added to the configurations. Within this strategy, any configuration can acts as an architecture of reference for successive system configurations. Reuse from a fixed architecture of reference In order to explicitly provide knowledge about common and changeable modules for a variety of system configurations, an architecture of reference must be independent from the successive configuration definitions. PLE has answered this problem by suggesting common generic product. In this strategy, configurations still derive from each other at an implementation level (see figure 5.4), but they all benefit from the same changeability characteristics of the architecture of reference. Only reuse strategy was presented so far for the sake of redesign processes. In introducing an independent architecture of reference, questions arise on how the architecture of reference shall evolve and leverage on the past or future implemented configurations. Leveraging aims at enriching the architecture of reference from possible future configurations.

Architecture of Reference

Reuse and a-posteriori leveraging At the end of re-configuration phases, configuration specificities are capitalized in order to upgrade the architecture of reference. In this way, two concurrent processes are performed: reuse changeability for re-configuration, and capitalization of configurations for upgrading the architecture of reference. This latest process is a-posteriori since it leverages on past configurations. Reuse and a-priori leveraging The architecture of reference can also a priori evolved towards future possibilities. When configurations are perceived to be likely to occur, enablers for facilitating future configurations shall be integrated in the architecture of reference. It is an a-priori leveraging process since it capitalizes on estimated future potential configurations. .6 illustrates the adopted strategy for upgrading changeability of the architecture of reference design, concurrently to re-configuration. Successive re-configuration instances derive from an architecture of reference (i.e. redesign process); in parallel, changeability capability of the architecture of reference is continuously upgraded (i.e. DFC process). On one hand, configurations are a-posteriori reused from the architecture of reference. On the other hand, estimation of potential future configurations are a-priori capitalized in order to upgrade changeability capability of the architecture of reference. This strategy is adopted for the rest of the chapter.

Architecture of

Architecture

The redesign process and DFC process are clearly distinguished since they do not seek to achieve the same objectives. For the first one, the final solution satisfies new problem needs in maximizing the reuse of existing changeability; in the second one needs for changeability are analysed and satisfied. Nonetheless, the reality of the projects is so complex that both of those views are included inside one project. For the sake of clarity, both methodologies are described in this chapter. Separating these processes highlights how different their objectives are; it prevents stakeholders from the temptation of highly prioritizing problem needs and considered changeability needs are only "Nice to Have requirements".

Life-cycle model for changeable system design

For any changeable system, two different design phases are differentiated in the whole lifecycle model in figure 5.7. The green-field project consists of the first and initial clean sheet design in which the space of decision is the broadest. It begins by an initial definition of a changeable system architecture before its development, and its operation (A0-1a & A0-1b). Once the initial changeable architecture of reference has been delivered, brown-field projects will emerge from predecessor projects all along the system lifecycle (A0-2 & A0-3).

In the green-field project, a nominal system architecture shall be first designed for nominal needs (A0-1a) following a classical system engineering process. Based on it, changeability should be designed at the outset along with the estimation of likely configurations, so that changeability and future redesign cost are optimum (A0-1b). Continuously during system lifecycle, successive reconfiguration or redesign processes occur that reuse changeability capability of the architecture of reference (A0-2). Concurrently, changeability capability of the architecture of reference is upgraded (A0-3). DFC activities (A0-1b) and (A0-3) follow the same scheme. The following sections focus on methodologies for those two activities: "redesign & reuse existing changeability" in section 5.2 and "Design for changeability" in section 5.3.

Redesign & reuse existing changeability

Process model

A redesign scenario aims to synthesize a design solution that answers initial new requirements by maximizing reuse of existing artifacts. For that, the solution can be seen as a variant of the architecture of reference benefiting from its changeability capabilities. This section reveals limitations of some process strategies for reusing existing knowledge, then it concludes on the adopted one for this work.

Limitations of pure top-down development models for reuse in redesign processes

Reuse is not specific to re-configuration or redesign: it is actually a core concept in design in general. Design solving problems can be modeled under two back-and-forth processes, namely the analysis and the synthesis processes. In the analysis process, the design problem is iteratively decomposed. Driven by the general system purpose, it leads to atomic functionalities in the problem domain. The synthesis process is the key step of any design problem. At this stage, a solution or a set of solutions from the physical domain are mapped to the functional domain, so that functional requirements are all satisfied. The alternation between analysis and synthesis activities were already presented with the system engineering formalism chapter 4. However, the crucial point is that solutions are synthesized in arranging and structuring together solutions principles that already exist. In this way, any synthesis process always relies on a reuse process. Designers pick physical existing elements to arrange (e.g. LEGO R ) or even reuse existing knowledge from its memory (i.e. "howto" knowledge). Two main types of strategies for approaching the issue of reuse during synthesis activities are hereinafter detailed.

Top-down strategy During redesign processes, models can follow a top-down product development scheme. As illustrated figure 5.8a, the process starts with analysis of the design problem and is followed by the synthesis looking for satisfying solutions in the solution domain. Feedback occurs from the solution domain to the problem domain with derivations of new requirements from chosen principles. However, pure traditional top-down design process flows tend to evaluate the reuse of existing system capabilities at only the very last synthesis stages. Solutions risk of being infeasible since the design problem has not been defined in taking into account possibilities from the existing artifacts. These static design models are often criticized since the existing system capabilities are only verified at the very last synthesis stage. Bottom-up strategy On the contrary, some other strategies begin with synthesis possibilities, then analyse them in the light of problem requirements as illustrated figure 5.8b. It is based on the belief that any system is the result of sub-elements arrangement. The design process reasons on local interactions of solutions elements. It results in stable organizations, turning into feasible new configurations. If the function meets the requirements, the structure is selected as a satisfying solution. If not, feedback is sent to the feasible structures generation step. This bottom-up approach is actually inspired from nature with the emergence synthesis concept: a stable global order is created from complex and dynamic local interactions [START_REF] Ueda | Emergent synthesis methodologies for manufacturing[END_REF].

Concurrent strategy for iterative and progressive redesign process Reusing existing capabilities is a difficult challenge for the two presented approaches. On the one hand, pure top-down approaches are unsuitable for redesign process as they assume the design process to be first creative, before evaluating feasible combination of existing artifacts. The process may at least be applicable in green-field design, but for redesign process it turned out that this "design from scratch" scenario is quite utopian since existing or feasible resources always constrain the design possibilities. On the other hand, pure bottom-up approaches may fail to be used in complex environments since the database of reusable artifacts are often incomplete, dynamic and do not enable combinatorial arrangements of artifacts. Hence, the strategy figure 5.9 suggests that the redesign process shall be concurrent to the evaluation for reusing changeability capabilities during analysis and synthesis activities. The adopted model is composed of an implicit collaboration between the system engineering process driven by designers as defined in chapter 4 (top-down) and a reuse of changeability process from existing architecture elements (bottom-up). The system engineering process follows the framework proposed in section 4.2.4 going from "requirement analysis", "allocation to structural elements" to "architecture design", and resulting in the rationale-based-architecture. Concurrently, each time a new set of elements is released from the system engineering process (requirements, structural blocks and architecture), it is evaluated according to the potential reuse of changeability encompassed in the architecture of reference. It results either in negotiation or acceptance of requirements elicitation for changing the architecture of reference. The overall process ends with the specification of a new configuration solution. This model can be seen as the premise of a collaborative-agent architecture of a design tool. The methodology for reusing changeability is detailed hereinafter.

Process for reuse changeability capability

The main objective of any redesign process is to analyse existing potential for changeability in the architecture of reference, and reuse it along the design process for a new configuration design. Each redesign decision shall benefit from the existing changeability so the re-configuration cost is minimized. The need for collaboration between classical system engineering design process and the process for reusing changeability has been highlighted in the previous part. The diagram in figure 5.10 presents the various steps that reflect complementary viewpoints for reusing changeability: 1 -identification of reusable elements according to the analysis of similarity, 2 -the specification of solution with either retrieving flexible solution (i.e. flexibility paradigm), or change elicitation (i.e. reconfigurability paradigm), 3 -change propagation analysis caused by previous defined changes.

In the end, alternative configurations should be compared regarding their re-configuration costs and induced benefits. The final configuration solutions are synthesized as variants of the rationale architecture of reference that has undergone several changes. Due to the iterative nature of this process, a description of collaborations between activities has been preferred rather than a sequential state-flow scheme. Each of these activities are hereinafter described: similarity analysis (section 5.2.3), retrieving flexibility (section 5.2.4), change elicitation (section 5.2.5) and change propagation analysis (section 5.2.6).

Reuse of changeability capability

Solution for change

Similarity analysis for artifacts retrieval

For feasibility reasons, it is assumed retrievable artifacts have been stored in the architecture of reference to map specific requirements, meaning that they were created to be reusable. Reusable artifacts solutions can be isolated structural blocks, or rationale-based sub-architectures that satisfy a set of requirements. Reusing them requires to perform a similarity analysis process. When requirements are mature enough to be mapped to systems engineering artifacts, the potential for reusing existing artifacts is thus evaluated in looking for the most similar elements existing in the architecture of reference. Motivations for using a KB are first presented. A taxonomy of module types according to different levels of reusability is given. Then the way reusable elements can be retrieved is presented. Methods are differentiated between unsupervised and supervised identification of reusable elements.

Motivations for reuse from a knowledge base (KB)

The underlying motivation of the configuration design process is to maximize the benefits provided through previous changeability investments by reusing them. Identifying reuse possibilities from architecture of reference is therefore essential in configuration design. It prevents designers from redesigning from scratch, but giving them feedback with knowledge about changeability capability of the architecture of reference. However, it prerequisites existing knowledge about design possibilities within the complex engineering process from a KB. If knowledge is not retrievable from a KB, configuration design problem will be too complex for designers to keep a systemic view during analysis and synthesis processes. Designers will fail to manage consistent, cost and time-justified configuration design projects. Storing artifacts should be justified by their level of reusability, according to the changeability purpose. In product design, a product family (or a product line) is defined as a group of products that share the same platform, namely the same group of assets. The main interest of product platform for design is the reuse of common assets for new product variants of the same family. Herein lies the same motivation for representing the architecture of reference as a KB. In some works, reuse strategy can be enlarged to any type of knowledge. For instance, [Chalé Gongora et al., 2015] propose a new reuse strategy called "system and subsystems catalog of building blocks" in which reuse does not only take place within product family assets, but also project assets. Using an a-posteriori reuse strategy of changeability, artifacts ensuing the DFC process should be differentiated in the architecture of reference from project artifacts.

Classes of modules regarding the perceived need for reuse

The architecture of reference embodied in a KB encompasses different types of reusable artifacts. Figure 5.11 offers a classification of system elements from the most reusable to the least. It is assumed knowledge was formalized in this way in the architecture of reference according to preliminary changeability strategies.

-Fixed core platform: common core elements within any system variant of a system family.

-Platform modules: modules that have to be instantiated (or parameterized) in any system variant.

-Platform optional modules: available modules that can be used in some system variants without being common to all variants.

-Project specific modules: specific to a custom solution, but pointed out as being reusable in any project. Based on this classification of architecture of reference elements, analysis of similarity shall follow the algorithm Table 5.1. Four types of actions (in bold) depend on the similarity of system requirements with existing system elements. From the least costly (i.e. ready to use) to the most costly scenario (i.e. effort of development for adjusting):

1. Implement a platform module () 2. Instantiate a module from the platform module class () 3. Design a module class according to fixed core platform constraints () 4. Instantiate a module from the project module class () Let us note that the similarity metric will be dependent on application cases. Input 1: system requirement Input 2: fixed core platform; platform modules; platform optional modules; project modules Output: design decision for maximizing reusability If system requirement and fixed core platform are consistent If system requirement is similar enough to at least one platform module If one of the platform module is already instantiated Then implement platform module Else instantiate a module from the platform module class Else design a module class according to fixed core platform constraints Else If system requirement is similar enough to at least one project module Then instantiate a module from the project module class Table 5.1: Similarity analysis algorithm

Identification of reusable elements

The artifacts can be retrieved from different classes of the architecture of reference KB. In the case of a supervised approach, it is assumed that labels are given to elements in order to enable immediate mapping (e.g. the requirements "forming, welding, identification" would be labelled as "process plan"). Because of the preliminary amount of efforts required for specifying classes and labels of artifacts, unsupervised approaches are more trendy to use, especially for complex system. If there is no direct knowledge about reusable modules, expert systems can thus be deployed to automatically retrieve requirements allocated to solution in using text-matching tools in the whole rationale-based-architecture of reference. For example, in the Requirements Quality Analyzer tool of the Reuse company R , text information retrieval systems and semantic techniques are applied to requirement analysis tools.

For illustration purpose, a manufacturing system is presented in figure 5.12 from which elements are a shop stock, a manufacturing cell and a lift truck traveling between them as a means of the input flow of the cell. Figure 5.13 illustrates the rationale-based architecture of the system with requirements (R) and structural blocks (SB). The main components of the cell are: a forming press, a welding machine, a laser identification machine, a buffer stock for the final parts and an operator for the logistic flow. Let us assume that new needs for manufacturing a new product target a redesign process. From that four initial requirements (i-req) within the systems engineering process outcome. They are then allocated to similar and reusable elements of the architecture of reference.

-i-req 1: The system shall process the process plan B allocates to R12 -i-req 2: The cycle time of production shall be 1 part every 20 seconds allocates to R11

Pre-built and directly retrievable flexibility

Once similar elements are retrieved, their flexibility capability to respond to change is evaluated. As it has been stated before, reusing flexibility means that variability has been fully pre-defined and is ready to be used from the architecture of reference. For each changeable element, knowledge about flexibility shall hence be retrievable in terms of variation points in the architecture of reference. The variation points represent alternative connections to requirements or structural blocks in the rationale-based architecture. Let us note that the allocated system engineering artifacts are not necessarily stand-alone solutions; in fact they may range within more or less conceptual levels of definition. As an example of pre-planned impacted elements for flexibility capability on different elements, we consider i-req 2 "The cycle time of production shall be 1 part every 20 seconds". The allocation of i-req 2 to a flexible scenario for scaling-up the production volume has already been planned in the variation point at requirement R11 on production volumes (see figure 5.13). This allocation induces the activation of the requirement R11b ("Production volumes 1 part / 30 sec < X < 1 part/15 sec") and the activation of the cell characteristic requirements R81b "They shall be two cells -instead of one-at location X and Y". The deriving elements can be directly deployed. The requirements i-req 1, i-req3, i-req4 are respectively allocated to R12, SB3 and SB2 due to similarity analysis performed in the previous section. I-req 2 is allocated to R11, from which the variation point is retrievable due to pre-existing knowledge on available flexibility. We can see that for a change of production volume requirements R11b and R81b were planned to offer variability. Because new artifacts are defined in a change architecture oriented way, the initial requirements are allocated to systems elements thanks to the analysis of similarity. The initial requirement takes the role of entry point for requested change in the architecture. The allocated system elements may encompass variants that offer flexible solutions coping with initial requirement. Again, flexible solutions are not necessarily complete and more development can be required to result in a satisfying detailed solution.

Artifacts change elicitation for reconfiguration

Built-in flexible strategies are first evaluated as they are supposed to have been thought as easier and less costly strategies to reuse existing variation points. Regarding initial needs, if there is no flexible strategy or if it is insufficient to be used as is, designers identify and formalize changes that architectural artifacts should undergo to satisfy changing needs. Decisions for architectural changes should be elicited on artifacts of the architecture of reference. Unlike flexibility, this process implies: longer development process since no immediate and predefined solution exists to cope with change request, longer ramp-up phase between development and maximum system capacity utilization, and as a result, longer interruption of the operational phase. The ability to undergo structural changes for a new configuration precisely depends on a reconfigurability strategy. It encompasses architectural properties designed to enable structural changes and re-arrangements of system components. The way reconfigurability can be designed is reviewed in the next complementary section 5.3 on changeability design. Depending on pre-thought reconfigurability in the architecture of reference, change elicitation scenarios will be easier and less costly. Four types of elementary change scenarios leading to a new configuration are distinguished:

1. Nothing: The element is kept.

Modification:

The element is modified without altering its interfaces. Usually re-configurations and structural modifications are restricted to a physical sense. As an example, figure 5.14 shows addition and deletion of workstations in a manufacturing system . With a system engineering perspective, any element of the rationale-based architecture can undergo those change scenarios. A configuration is therefore the result of successive change scenarios applied to system engineering elements of the architecture of reference. For instance, the initial requirement i-req1 "The system shall process the process plan B" in the example in figure 5.13 is derived into successive changing scenarios in figure 5.15. It starts with i-req 1 allocated to R12. As long as the requirement i-req 1 is not satisfied, change scenarios are specified on system engineering elements. Requirements and solution structural blocks can thus undergo change. In the current example, requirements R1, R10 and R6 are changed, and the laser identification machine is replaced by a bar code machine. In this way, the initial requirement i-req 1 is satisfied. Literature has often opposed flexibility paradigm to reconfigurability paradigm stating that the first ones enable changeability with pre-built solutions whereas the second answer change with structural re-configurations. The reuse of these two paradigms have been presented hereinabove. They can actually be combined since reconfigurability is rarely designed without a range of configurations and related scenarios in mind. In summary, pure flexible solution is a ready-to use solution that is easily retrievable to designers; a pure change-elicited solution is the result of change specifications assuming reconfigurability is preliminarily enabled; an hybrid solution results from a change-elicitation process during which pre-built knowledge on possible artifacts to reuse and arrangements are retrieved to designers. The core idea for this third strategy, is that not only engineering elements can be retrieved to designers for answering needs, but also their structural possibilities of arrangements. An example is the Festo Didactic transformable iFactory R [Festo-Didactic, 2012] since a set of modules and combinations have been pre-designed to form different layout configurations. A typical re-configuration process would be a change elicitation process of the different modules in the architecture of reference, while benefiting at the same time from knowledge about feasible combinations.

Addition

Legend

Change propagation analysis

Changeable solution: a mix of partial flexible and change solutions Delivered configurations can be incomplete either from a change elicitation process, or from a reuse process of pre-built flexible solutions. A first reason for incompleteness could be the lack of details about the defined solution. Depending on the required level of specification, the design process should continue. The solution can also be incomplete for complexity reason in the architecture, meaning that the redesign solution is partial and result in turn on change propagation in the overall architecture. The propagation of change in the overall architecture can bring new requirement requests and thus keep carrying on the design process. For complex systems, any partial solution that arises from a change elicitation scenario or a flexible solution is likely to propagate change in the overall architecture by delivering new requirements or constraints. In the end, the complete final redesign solution is an hybrid integration of partial flexible solutions and partial structural changed solutions. The overall changeability cost will depend on these partial costs. The evaluation of the global changeability cost of configuration should be continuously updated as the sum of partial cost of changing scenarios within the overall architecture. In doing so, expensive re-configuration scenarios can be excluded during redesign processes.

Flexible and reconfigurable solutions as sources of change propagation

Interest for change propagation When no unique and complete flexible solution has been planned to respond to change -which is quite common in redesign of complex systems, change elicitation and partial solutions are put together to form the new architecture. Because each of the partial solutions must satisfy the preceding change requests, the overall changeability relies on architectural characteristics that act as absorbers of change propagation (i.e. modularity, integrability, diagnosability and mobility).

More precisely, a compromise must be found between the induced cost for change by a solution and the cost of the solution itself. Changeability costs can be evaluated by analyzing change propagation induced by the successive solutions in the overall architecture. The difficulty is that changeability knowledge can not be fully retrievable but is implicit in the architecture of reference, it can only be estimated through observations of the change propagation in the architecture. Designers should be then able to re-consider design choices based on the evaluation of changeability cost.

Coupling matrix knowledge Knowledge about impacted elements by a change is not easy to retrieve from designers experience, hence the use of a coupling matrix is required to support changes propagation analysis. After each change elicitation, propagating change into the overall architecture is analyzed through this tool. Changeability, which depends on the indirect costs induced by the overall system capability to welcome change, can thus be evaluated in this phase. Consistent with the system engineering formalism presented in chapter 4, we report dependencies between the artifacts of the rationale-based architecture into a MDM [START_REF] Eppinger | Design structure matrix methods and applications[END_REF]. A MDM matrix representation is relevant to highlight coupling between elements belonging to different domains -in this case within and between problem domain and solution domain. Different type of clusters can be identified according to the system engineering design artifacts formalism presented in section 4.3: requirements coupling, requirements -structural blocks coupling, and structural blocks coupling. Based on the different types of relationships in the rationale domain (section 4.4) an example of rationale-based architecture is given in figure 5.16. It represents a manufacturing system composed of a set of AGV, a shop-stock and a shop cell connected to a manufacturing cell. Each of these structural elements relate to requirements. Dependencies between artifacts are illustrated in a DSM in figure 5.17 without domain distinctions. Coupling between problem and solution domains are represented in the re-structured matrix MDM in figure 5.18. The interdependencies result in clusters in which modules (i.e. strong cohesion areas where change propagates) and interfaces (i.e. low coupling areas where change is likely to be absorbed or limited) can be identified. In figure 5.18, the identified modules correspond to the dotted red squares in figure 5.16. Once an independent module is found, it is advised to continue the coupling analysis in a new MDM model according to the specified encapsulation. Supporting tools and heuristics can be deployed in this context of module identification, with for instance an algorithm to assess the likelihood of change propagation [START_REF] Ahmad | Change impact on a product and its redesign process: a tool for knowledge capture and reuse[END_REF]]. In the current example, the identified modules listed in figure 5 Impacted elements identification The elements sharing connections with the source element are observable through the MDM representation. It is here assumed that a MDM exists, or can at least be generated from the rationale-based architecture of the architecture of reference. Propagation of change caused by previous solutions can thus be identified, arising in turn in new needs for designers or even questioning previous solutions due to their engendered costs. Depending both on the nature of impacted elements and the type of change, elements act as propagators, amplifiers or absorbers of change. Decreasing changeability cost depends on the capability for absorbing change propagation in the system and the costs of their satisfying solutions.

If the source element impacts several elements then they can all be considered as one impacted module with internal elements that must be satisfied together. This situation can bring difficulties for problem solving when several criteria are impacted by the change decision. An example of such coupled problems in figure 5.16 is represented by a change on DP1 impacting the set (DP2, DP3, Req2, Req3, Req4). The process stops once change has stopped to propagate, and the candidate configuration is judged complete and satisfactory regarding the initial requirements.

X Blc 4 X X Req 6 X Blc 3 X X Req 5 X X X Blc 1 X X Blc 2 X X X X DP1 X X X X DP2 X X X X DP3 X X X X Req 2 X X X Req 3 X X X Req 4 X X X
X Re q6 X Re q5 X X X Re qX Re q2 X X X Re q3 X X X Re q4 X X X X X X X X X X X 1

Design for changeability

Changeability capabilities should be designed at the outset when a new system is designed (A0-1b in figure 5.7). Moreover, changeability should also be continuously upgraded in the architecture of reference during the system lifecycle (A0-3). At the initial design project, because no preliminary system exists the potential for DFC is the highest. At this stage, the architecture of reference does not yet include changeability capability, but similarly to the continuous upgrade process during system lifecycle (A0-3), the architecture of reference is upgraded from the nominal architecture specification in (A0-1b). The presented DFC methodology can thus be applied to the activities (A0-1b) and (A0-3).

Process model

The model of the DFC process is presented in figure 5.19. DFC is first of all about forecasting what future changes might be (Forecast likely change scenario activity), then what future configurations are likely to result in through the reuse of existing changeability capability (Forecast future likely design process). The Forecast future likely design process actually embraces the same process as redesign & reuse existing changeability presented in section 5.2; the only difference being that in this case, DFC is based on an estimation of future needs. Each time configurations are forecasted, needs for upgrading changeability are delivered to the Upgrade changeability process. It follows the classical scheme through analysis, synthesis and evaluation. In changeability need analysis requirements are elicited about strategy, scope and location of changeability. Solutions are finally the result of change enablers synthesis, necessary to upgrade changeability. Once several solutions have been delivered, they are stored as a set of alternatives to upgrade the architecture of references based on configurations and scenarios needs (Arch N ; Conf 0 ..Conf i ..Conf n ). The solution candidates are evaluated and compared to each other according to the required investment in the architecture of reference Cost(Arch N ) and reconfiguration costs (Arch N → Conf i ) during ROI Evaluation process. It is assumed that for each architecture of reference solution, only one configuration corresponds to one forecasted scenario. If no solutions are judged as good enough to offer a satisfying level and range for changeability, then alternatives solutions keep being generated. The process finally results in an identified upgrade of changeability for the architecture of reference with the highest ROI. It must be stated that an efficient solution will be delivered if the forecast of configurations process and the upgrade of changeability process are performed in a jointly manner. For the sake of simplicity, the collaborative scheme between upgrade changeability and new configurations generations is not developed in the following methodology but simply assumed. Because the evolution of new design problems is what will deeply impact the system design activity and should therefore justify changeability investment, an estimation of future scenarios is preliminarily performed. DFC process relies on an anticipated leveraging strategy as it has been presented in section 5.1.2. For that potential future configurations should be estimated to be a-priori leveraged on. To evaluate the range and type of required type of changeability, [START_REF] Rhodes | Anticipatory capacity: Leveraging model-based approaches to design systems for dynamic futures[END_REF] state that a mindset able to predict design scenarios about plausible unfolding futures is required. In the same line, a representation of the evolutionary perspective of production problems over the whole system lifecycle is represented under a scenario nodes form by [Terkaj et al., 2009b]. Each node contains the information allocated to a certain time period, characterized by a parent node, a time-scale and by a realization probability. Variability of production problems can be represented by a composition of short-mid-term nodes inside a long-term node as represented in figure 5.21.

Figure 5.21: Extended scenario tree representation [Terkaj et al., 2009b] In order to elicit needs for changeability, a profile for changeability driver requirements is proposed. It enables structured formulations of scenarios. It is an effective tool to encourage designers to think in a future-oriented way either for preventive or necessary reasons. This profile is manufacturing-domain dependent since it lists the potential change drivers that may apply to manufacturing systems. Requirement stereotype follows a classification of change drivers either from product demand (product family, product variant, product mixed product volume), from process domain (manufacturing, logistic, store) or from any external strategic motivation. Some examples from manufacturing system design projects are presented hereinafter and illustrated in figure 5.22.

-Product demand domain -<Product family change stereotype>The robot gripper shall be changed -<Product variant change stereotype>The AGV shall transport different types of parts for different product variants -<Product mixed change stereotype>The variant 1 is variable in a range of volume A, and the variant 2 is variable in a range of volume B.

-<Product volumes change stereotype>The transportation control shall be scalable from one to several AGVs -Process domain -<Standard change stereotype>The identification control shall be independent from the chosen technology -<Manufacturing process change>The press shall have changeable tools and fixtures -<Logistic process change stereotype>The system shall be independent from the input flow: the parts could be brought by type or kit -<External strategic motivation stereotype>The internal stock place shall be optional Design processes and resulted configurations might be estimated according to the forecast of change needs. The simulation of the redesign process merely follows the earlier defined redesign process model in figure 5.9 and deployed in section 5.2.

Change requirements

Once configurations have been estimated, they are analysed under their induced reconfiguration process, namely the changes the architecture of reference is required to go through. For each forecast configuration, the elements of the architecture of reference which are at stake by the new configuration or the re-configuration process are identified (e.g. involved external technician for upgrading a machine). This identification can notably be conducted through change propagation analysis in the rationale-based architecture of reference. It results in a formulation of change requirements allocated to specific artifacts of the architecture of reference, themselves belonging to different domains and levels.

Change requirements are formulated according to the desired types of change scenarios. It can either be a change of the current level of a system specifications parameter (i.e. scalability) or a change of a current set of system specification parameters (i.e. exchangeability, addition or deletion). A change requirement captures the need of changeability for an element m with external interfaces i of the rationale-based architecture, stating decisions about the changeability strategy. The four types of change requirements for any (m, i)

Changeability strategies

Overview of changeability strategies

System changeability strategies are synthesized in figure 5.26 according to whether they absorb a new change without requiring a new implementation (i.e. flexibility) and whether they require implementing change in rearranging or changing structure components [START_REF] Koren | Reconfigurable manufacturing systems[END_REF] (i.e. reconfigurability with extensibility or convertibility). Within flexibility strategies, we differentiate modules that entail several functionalities -type swiss army knife -also called built-in dedicated flexibility, from the ones that respond to change with a change-over phase (e.g. "plug and produce" manufacturing paradigm). Due to their different ready-to-use levels, these changeability strategies can also be differentiated according to their uncertainty and time scale for change: flexibility is for a planned change type "plug and produce" (i.e. short-term changeability) and reconfigurability is for an hypothetical and fuzzy future change for system convertibility or extensibility. Hence the decision for changeability strategies depends on the uncertainty, the time scale of future needs and internal strategic decisions.

Decision on changeability strategy

The difficulty in DFC is to decide on the right level and the extent for flexibility and reconfigurability. The DFC activity affects the whole set of future configurations and associated change requirements. At this stage, changeability strategies are allocated to change requirements and then synthesized together. The decision on type of changeability for elements of the architecture of reference depends on the analysis of the following criteria: detailed knowledge of the requested changeable elements, variability between the requested changeable elements, and uncertainty of the future changeable elements. Two heuristics are defined to orientate designers toward a flexibility or reconfigurability strategy.

1. If there are details and high-certainty about future developments, flexibility should be fully implemented, so that it is ready to be used when the predicted changes occur. If there is uncertainty about the future system embodiment, abstract elements, modularity and interfaceability should be designed to increase the system capability to change its own structure (i.e. reconfigurability).

2. If change concerns similar and detailed variants (e.g. car color shall be painted with box color yellow and box color blue), flexibility will be the best choice to answer specific and restricted variability. However if the variant impacts high-level, generic and different type of changes (e.g. process, level of automation etc.), this large variability should be answered by an open and reconfigurable system.

As an example, a synthesis of required changeability investments of an AGV is represented in figure 5.27.

Block AGV

Synthesis of changeable enablers

Once the problem is defined in previous analysis activities, now comes the critical mapping process in which solutions for changeability are selected, re-arranged, designed. Modularity and integrability are critical enablers for changeability referring to system's architectural properties. They enable changes as addition, removal or internal change as reported in table 5.2. Even though enabler concepts have been pointed as relevant to support system changeability, they are rarely integrated into DTM [START_REF] Elmaraghy | Design Theory and Methodology[END_REF]. In fact, these concepts are not stand alone solutions but involve architectural considerations in order to reduce change propagation in the overall system. The scope, the level of impact to which they relate to encompass critical decision to ensure effective changeability.

Modularity Integrability

The module to remove/add/change shall have the just necessary functionalities that are required to avoid unnecessary impacts

The interfaces between the system and the module shall facilitate the removal/addition/internal change Table 5.2: Enablers for change scenarios

Design for modularity

Modularity aims at making modules as independent as possible. It limits the coupling of components across the total system. Change propagation is delineated to highly coupled system modules impacting each other. The rest of system's module has low cohesion, and usually few interfaces, with the changing modules. Modularity enables easier reuse and manipulation of elements, and thus contributes to reconfigurability. For that, the independence principle should be maximized as stated in the first axiom of AD [Suh, 1998], preferring uncoupled and decoupled design rather than coupled. If the architecture is not meant to be changeable, then minimizing decoupled design is debatable in terms of costs. For this purpose, tools represent architectures and element dependencies such as the "coupling matrix" presented in section 5.2.6. A module should then be identified as a set of systems engineering components with relatively low coupling at its interfaces.

Design for integrability

Change propagation is limited in minimizing coupling between elements (i.e. modularity). However, coupling can be needed and unavoidable in complex systems. Components are integrated to form the whole complex system and thus provoke elaborated systemic behaviors. Integrability is a key concept surrounding modularity; it characterizes the compatibility between changing modules and the rest of the system. It can be defined as the capability of an interface to receive a changing module without being altered. For that interfaces can be proprietary or common to different module types. In accordance with the modularity paradigm, a module is composed of other modules and interfaces, and defined by a highly-coupled change propagation area and low-coupled interfaces with the rest of the system (see figure 5.28). In order to guarantee integrability and independence of modules, and thus overcome change propagation in complex systems, margin concept has been introduced by [START_REF] Eckert | Change and customisation in complex engineering domains[END_REF]. Margins are interfaces at the boundary of the defined modules which have the capability to absorb changes within a certain scope characterized by attributes limit min and limit max (see figure 5.28). They offer robustness to propagation changes and thus increase module independency. In order to recognize them, it is suggested that critical components shall be flagged as required to act as margins. They can be from different types:

1. Generic and common (or open, standard) interfaces are necessary to enable compatibility with changing artifacts.

2. Buffer offers built-in scalability in making possible variation of modules numbers (e.g. storage space limited to 15 programs).

3. Tolerances gives variability for precision of parameter (e.g. fixtures can have a positioning tolerance of 0.5 % to keep a good precision).

4. Clearance encompasses additional capability for variability of scenario that will not necessarily be used (e.g. space security, empty space for additional machines). In order to grasp the interest for using margins in redesign phases, the example of a change occurring in the transportation system in figure 5.16 is reviewed. This example falls into the hybrid strategy for change elicitation presented in section 5.2.5. A change of requirements (req2, req3 or req4) may impact DP1, DP2 or DP3 according to the nature of change (see figure 5.29). Margins allocated to DP1, DP2 or DP3 are retrievable designed solutions that offer absorption capability and thus integrability.

Abstraction level for modules and interfaces synthesis

The identified changeability strategies result in interface and module requirements for the architecture of reference. Deciding between implementing dedicated modules and abstracting modules depends on the considered time scale, the completeness of future knowledge, the changeability strategy, and investment strategies. Different scenarios for changeability strategies identified in figure 5.26 are considered under module and interface needs (figure 5.31).

-In case of no system change, modules dedicated to several functionalities will require dedicated interfaces (e.g. a machine for drilling and a machine for turning).

-In the short-term change-overability scenario, the dedicated modules will require an interface dedicated to the range of modules it can be plugged to (e.g. a machine tool with a tool holder for different size of tools).

-Long-term change scenarios call for the abstraction of modules since knowledge concerning the future module is incomplete and fuzzy. Therefore, interfaces are either dedicated to a module class -the interface being a constraint for the future module (e.g. machines shall communicate with Profibus standard) -or generic to a class of interfaces (e.g. platform requires a generic transportation functionality as input). Once module types and levels have been defined, the last step is to assign them to a class of reusability according to scenario characteristics (time of period, parent node, time-scale and realization probability). The class of reusability (see figure 5.11) should be used to make optimal the ratio between {effort, time, cost} for structuring knowledge and {effort time, cost} to reuse it. After that, designed changeability solutions are candidates for the architecture of reference Arch n . The process ends with the evaluation of the selected alternatives.

Decision criteria for changeability upgrade

A general formulation of decision criteria for changeability upgrade is presented in figure 5.32. Reasoning from current changeability capabilities in the architecture of reference Arch 0 , different re-configuration scenarios (Arch 0 → Conf i ) are formalized according to the forecast of configurations Conf i satisfying the future change scenarios; it induces knowledge about the reconfiguration Cost(Arch 0 → Conf i ) which depends on the changeability of the architecture of reference Arch 0 . Because changeability is a relative concept, the core interest for upgrading the architecture of reference into Arch n is to make benefit of this investment according to the future configurations (Arch N → Conf i ) in comparison with configurations without this architecture upgrade Arch 0 → Conf i . Designing and investing in "ities" requires strategical perspectives of future system lifecycle evolution. The investment of time, effort and money for changeability must be justified regarding the various stakeholder and designer views. The ultimate criteria for justifying additional changeability in the design of Arch n is to maximize the ROI of such investment, as detailed in the following system.

Conclusion

This chapter has proposed a systemic design methodology for complex systems such as Changeable Manufacturing Systems. Because the complexity of engineered systems cannot be simplified, the methodology was system engineering-based and supports design for changeable systems during their whole lifecycle. DFC is crucial to achieve the desired performance of large systems as they evolve over a long lifetime. It is also necessary to reuse and leverage on existing changeability during redesign processes. The lifecycle model for changeable systems alternates between DFC phases and redesign phases that take benefits from existing changeability capabilities. Hence two methodologies were respectively developed. General principles have been incorporated to the methodology for upgrading changeability of a current system, going from need analysis, through enablers' synthesis such as modularity and integrability. Different strategies for reuse changeability were also presented and prescribed for Knwoledge-Base-System (KBS) developments.

Chapter 6

Case-studies for concept validation The Goal, E. M. Goldratt

Presentation of the industrial context

Company context

A major re-structuring plan was followed up in a French plant of the multi-national company Faurecia Automotive Seating. Faurecia Automotive Seating designs, develops and produces seats for different automotive customers as Nissan, General Motors, Volkswagen, PSA. The plant under consideration was responsible for producing seat frames. The product variety ranges from seat cushion, to backrest product families, plus other specific manufactured mechanisms (see figure 6.1).

Time horizon for design projects

The restituted case-studies are highly inspired from the company context. Not all the aspects are retrieved and some of them are simplified for comprehensive purpose. The lifecycle of the SoI is split into four phases: the current configuration in the plant at the time of the project in 2014 (n -1), the designed configuration implemented in the pilot line in 2014 (n), the configuration deployed in the plant in 2015 (n + 1), and the estimated future operational configurations for 2018 and later (n∞). The redesign processes that reuse existing changeability are illustrated from (n-1) to (n), and then from (n) to (n + 1). The DFC processes are studied at period (n) toward future periods (n + 1) and (n∞). The redesign projects were mainly driven by the production strategy facing the threat of outsourcing. The first change driver for this large-scale redesign project was the automation of almost all the logistical operations, so that the plant concept was able to stay competitive in high-cost countries. Various other identified improvements for better performance have also driven the redesign process (e.g. the simplification of flows in the plant).

Backrest Cushion

System of interest

Several redesign projects for sub-systems of the plant were followed up in the company through meetings. These projects are presented within a three-layer hierarchy in figure 6.2: plant, segment line and manufacturing system levels. The plant level focuses on material flow and the segment line is dedicated to cushion frames assembly. It includes manufacturing systems such as press cells performing the assembly processes for tube expanding, assembly lines performing the screwing and lock-bolt processes and transportation systems transporting raw materials and final sub-assemblies.

Although the various levels create together a unified system, redesign projects were led within separate projects for each of the sub-systems. Nevertheless, the evolution of sub-systems impacted the others during redesign or DFC processes. Two challenges have been elicited: 1 -the engineering processes must be concurrent, so that the changes coming unsynchronously are efficiently communicated to teams working on adjacent sub-systems 2 -the DFC process must be systemic, so that changes and their impacts are tackled together. The industrial design projects on which both DFC processes and redesign processes have been applied are illustrated in figure 6.4. Changeability is often reused in a pragmatic way without any formalization for redesign, and without preliminary design for changeability considerations. This chapter offers insights on how redesign and DFC processes support real industrial contexts in the plant (DFC process in section 6.2), in assembly lines (redesign and DFC processes in section 6.3), in press cell and in transportation system (redesign process in section 6.4). In conclusion, the methodology DFC is retrospectively validated in simulating the potential benefits Arch n would have brought in comparison with what actually happened (section 6.5). The initial configuration (n -1) focuses on material flow through the whole seating plant (see figure 6.5). From a mass stock area, pallets containing raw materials are received, listed, then the materials are removed and themselves referenced. Orders are prepared in trolleys, and brought by logistic operators to the picking zone. At the picking zone, the trains take the trolleys and transport them to the production units (i.e. manufacturing cells or assembly lines). There, an operator unloads the material and feeds the production unit. The same operator prepares and lists empty output pallets and fill them with the final parts. They are then stored in the shop-stock area where the fork lifts load them and finally transfer them to one of the two TPA (Truck Preparation Area). The complexity of the material flow is represented in figure 6.6. The configuration is restricted to logistic viewpoints. It is characterized by the flow layout and means for transportation (manual, semi-automated or automated) going from departure locations to destination locations:

-Mass stock flow (pink): going from "mass stock" location where raw materials are stored to "picking zone" location where logistical operators prepare boxes and pallets in trolleys.

-Input flow of raw materials (green): trains bring trolleys with materials from "picking zone" locations to "production units" locations.

-Output flow of finished goods (red): forklift-trucks transport final parts from "shop stock" areas (blue) inside each production unit to one of the two "truck preparation area (TPA)" (in purple). Internal flow within production units are beyond the scope of the studied configuration.

In order to perform the configuration design process, the rationale-based-architecture of reference Arch n-1 for input flow is illustrated in figure 6.7 and for output flow in figure 6.8, according to the formalism presented in chapter 4.

Presentation of the approach

The inputs of the DFC process are the current configuration of the plant Conf n-1 and the estimations of future ones Conf n , Conf n+1 and Conf n∞ . The result of the process is an upgraded architecture of reference Arch n+1 with new changeability capability (see figure 6.9) (the period n is not considered for implementation). No distinctions are made between the deployed configuration Conf n-1 and the architecture of reference Arch n-1 since no preliminary DFC strategies were performed before this stage. The DFC process is composed of the analysis of the changeability needs (section 6.2.3) and the synthesis of the changeability solutions through integrability (section 6.2.4) and modularity (section 6.2.5) concepts.

A0 Design for Changeability Forecasted Conf n∞

Architecture of reference An+1

Conf n-1 Figure 6.9: DFC approach from n -1 to n + 1

Changeability need analysis

Forecast future scenarios according to change drivers Future scenarios are forecast and formulated based on the profile for changeability drivers presented in section 5.3.2 in chapter 5. They are illustrated in a scenario tree as shown in figure 6.10 with indications on time scale and probability of occurrence. The short-term changes from current scenario n + 1 are listed from 1 to 2, the long-term changes from 3 to 6:

1. <Technology Change>The traceability function of the information system is upgraded without a clear view on the final solution. The production order given by a physical kanban is little by little planned to be dematerialized into a virtual kanban. A more systematic traceability of production operations will also induce changes in the information system and the MES (Manufacturing Execution System).

2. <Product Volume Change>The variability of volume is more and more difficult to plan in advance. The system must be quickly scalable for that.

3. <Product Family change>The segments dedicated to production units may one day be transformed to produce new product families.

4. <Product Variant change>Within each segment line and each product family, the product variants are highly likely to evolve in period n + 2 (near futur) and also period n∞ 5. <Logistic process change>New areas of stops for input flow are very likely to emerge if production units change 6. <Logistic process change >Transportation between units and TPA are likely to be automated in future, depending on the decision of a pull or push flow solution Now needs and solutions for changeability are specified, the synthesis of the required changeability enablers is the next step. The next sections focus on Scenario 4 and 5 which both relate to reconfigurability strategies and cause indirect changes.

Changeability enabler: Integrability of transportation layout input flow

Integrability strategy principle The input flow transportation path in the architecture Arch n-1 is illustrated in green in figure 6.6. Its modified rationale-based architecture is represented in figure 6.11 in which structural blocks (circle) and requirements (square) relate to each others. It follows each production unit stop location and has to adapt to each of their layout specificities. According to the change requirements derived from scenario 5, extensibility of areas of stops shall be enabled to cope with the evolution of production unit's locations. Hence, an open and standard strategy of interface has been reaching in deciding for a rectilinear transportation layout. The principle key is to enable potential future extensibility of areas of stops to cope with the evolution of production units. A generic and common straight line shape ensures stable interfaces exactly like a universal bus would act. It provides highest integrability than a complex path that fits each production unit specificity. Indirect required changes Changeablity enablers are not turnkey solutions. Even though the new transportation path shape enables a better integrability, the intermediate interfaces between the transportation shape specification and the production units shall cope with these changes, requiring in turn indirect changes. Figure 6.12 illustrates the need for adaptation and upgrade of interfaces between the new changeability enabler (i.e. the open transportaion flow layout) and the rest of the system (production units and others). These interfaces must be first identified, then required upgrades new architecture definition Arch n+1 must be elicited. Because interfaces has to be designed through the identification of modules with high intra coupling, a DSM in figure 6.13 represents surrounding system engineering artifacts (i.e. requirements and organic structural blocks) between the production units (Block B1.10) and the requirement on the input flow layout (Requirement R1.1, allocated to the block "train" Block B1.3). The elements refer to the rationale-based architecture of figure 6.7.

X 1.1 X X X 1.2 X X 1.6 X X X X
1.15 Picking area X 1.10 Producti on units X Figure 6.13: DSM of elements connected to the transportation path shape Arch n+1 [B1.3, R1.1] is the first module on the top left in figure 6.13. From it, it is observed that a change of production unit location (Block 1.10) directly affects the requirement R1.6 of "transporting parts from picking zone (Block 1.15) to production units". These dependencies create another module [B1.10, R1.6, B1.15] (at the bottom right in figure 6.13). In turn, change propagates through the module [R1.6, R1.2: "The input flow layout shall follow the input places of production units", R1.1].

The module on the top left [B1.3, R1.1] defining the transportation path shape of the train acts as an absorber thanks to its integrability. From this DSM, the module [R1.6, R1.2, R1.1] is considered to be the interface between the transportation flow layout and the production units that must be upgraded. A list of actions to take for interface upgrading is given in terms of change elicitation of engineering elements in table 6.2.

Changeability enabler: Modularity of output flow

Modularity strategy principles In Arch n-1 , the output flow of final products goes from shop stock within each production units to either TPA 1 location, or TPA 2 location. The allocation depends on customer orders but is not clearly predefined. In figure 6.6, the output flow (in red) is common to all the shop stock sources (in blue) from which distinguished product types are produced. The rationalebased architecture of reference Arch n-1 for output flow is represented in figure 6.8. A representation of dependencies is represented in the DSM in figure 6.14. For illustration purpose, only three shop stocks are represented, but in reality they were five. The physical coupling analysis reveals that change in any shop-stock may affect the global output flow transportation system, and in turn affects TPA1 or TPA2. In order to avoid change propagation between the different shop-stocks, a modularity strategy is deployed to minimize intra-modules coupling and to maximize inter-modules coupling. As [START_REF] Fricke | Design for changeability (DfC): Principles to enable changes in systems throughout their entire lifecycle[END_REF] present in its correlation matrix of principles, modularity is strongly supported by the key principle of independence, which in turn has a harmful interrelation with the simplicity principle. This result is visible in figure 6.15 where the modularity strategy is applied to the output flow architecture Arch n-1 . The modularity strategy induces the creation of modules in which each shop stock (i) relates to dedicated output flow (i) and TPA (i). It creates major decoupled relationships between those changeable areas. It results in simpler and more direct output flow from the shop stock areas to the TPA areas. Independency decreases complexity of the layout, and because the distance is reduced, the adjustment to internal changes can be more reactive within each modules.

Shop-Stock

(i-1) Shop- Stock (i) Shop- Stock (i+1) Output flow TPA1 TPA2 Shop- Stock(i-1) X Shop- Stock (i) X Shop- Stock(i+1) X Output flow X X X X X TPA1 X TPA2 X Figure

Shop

- Stock (i+1) Output flow (i+1) TPA (i+1) Shop- Stock (i+1) X Output flow (i+1) X X TPA (i+1) X Shop- Stock (i) Output flow (i) TPA (i) Shop- Stock (i) X Output flow (i) X X TPA (i) X Shop- Stock (i- 1) Output flow (i- 1) TPA (i- 1) Shop- Stock (i- 1) X Output flow (i- 1)
X X The initial configuration Conf n-1 is represented in figure 6.18 with two assembly lines side by side. The configuration includes three operators at each assembly line, and one logistic operator responsible for preparing and supplying raw materials from the input storage to the two assembly lines. The initial need causing the redesign process from the manual configuration Conf n-1 was the automation of processes. In the rationale-based architecture in figure 6.19, the initial requirements are represented as requirements (striped squares) or structural blocks (striped circles). Operations 1 & 2 are required to be automated (←→ "shall be semi-automated") and operations 1 & 2 must be manually prepared, (← + "an operator shall prepare operations 1 and 2"). Operator 1 is allocated to a new workstation 2 interacting with the Robot Pump Assembly of station 1 and Robot lock bolt of station 2. Because of humans' flexibility, the additional required changes are absorbed by the operator. The second operator is still in charge of operation 3. Another need is the extension of the number of assembly lines going from two to four (←→ "number of AL (Assembly Lines) = 4"). Finally, due to the DFC process having occurred at the plant level (see section 6.2), the input storage is not anymore fed by the input flow train (see figure 6.18) but is now directly connected to the downstream press cell. Therefore, the "input flow transportation system" must be exchanged with ←→ "Intermediate shop stock with press".

Analysis of change propagation

The requirements and structural blocks impacted by deriving changes are represented in grey figure 6.19.

The white system elements are the ones that are directly retrievable from Arch n-1 only with few interface adjustments. "The station must work with the two variants pump with no change-over". This results in flexibility with two variants of assembly programs at the process level. At the machine level, two dedicated grippers, two variants of greasing systems and two variants of design parameters for pressure of free play compensation forces in the pneumatic mechanism are implemented. Another flexibility strategy enables both manual an automated modes. A future need is forecast to be a third variant of pump already known in the product domain. The consequences in terms of process and machines are not fully planned. This is a mere illustration of an identified need of design for reconfigurability where uncertainty about deployment is high. Design for reconfigurability in space and time scale The assembly line must be scalable to be deployed in three or four spatial configurations on the space scale, and also reconfigurable on the time scale. In order to enable future station adjustments, independency between stations must be increased. A margin buffer strategy is developed with buffer stations which are inserted between each process stations (see figure 6.22). This interfaceability solution responds to balancing variations in the assembly lines, but also potential extensions or additions of future stations. Another strategy is the clearance space margin in planning more cable length than needed in the torsion bar station (manual work station 1) (see figure 6.23). The goal is to make the station easily movable, and thus changeable.

Assembly lines control programs

Control programs have dedicated versions for the different assembly line configurations. To improve the logical reconfigurability of these programs, modularity is deployed in clustering control modules and rearranging them for each configuration deployment. A first solution proposed by a supplier was a global switch between different control programs dedicated to each assembly line configuration. It caused difficulties to imagine a modular programming as previously described since there were no independence to isolate modules. This is actually a common problem between contractor and suppliers: the architecture of a global system designed by the contractor may fail to be reconfigurable due to the lack of DFC considerations in the supplier's developments. It is incumbent upon system architect (the contractor) to specify interfaces, so that DFC can be possible.

Intermediate shop-stock between assembly lines and press cell

The input flow transportation system is completely changed in Conf n+1 . An intermediate shop-stock solutions is positioned intermediately between downstream press and upstream assembly lines instead of being external. In addition, the conceptual solutions is modified from boxes on the shop-floor into swing chain conveyor. The swings are designed to be manually moved by the logistic operator, but it is likely to be automated in the future. The control part of this intermediate shop-stock is required to be decoupled from the rest of the assembly line control.

PLC (Programmable logic controller)

In the central PLC of the assembly line (see figure 6.24), a buffer margin strategy is deployed in planning more Input/Output AS-i (Actuator Sensor Interface) modules than necessary. Each of them is standard for any station, based on an open-interface strategy to connect future equipments.

Tube expanding press cell

The tube expanding press performs assembly operations between the tubes and the side members. The assembly process is a metal forming process fashioning the metal parts through mechanical deformation (see figure 6.27a). The final sub-assembly forms the cushion frame (see figure 6.27b). Operations for loading parts and unloading final sub-assemblies are all manually performed. The assembly process is automatically performed by the press. The press cell in Conf n-1 is composed of a press (see figure 6.28), toolings for parts fixations, a welding machine for some of the sub-assemblies, a bar-code machine for traceability purpose and input/output stocks at the interfaces with the transportation system. The loading and unloading operations are performed by an operator between the machines and stocks.

Initial requirements

Conf n corresponds to the implemented prototype in the pilot line in 2015. Later, it has evolved toward a final implementation Conf n+1 in the plant. The main change driver for redesigning the tube expanding press cell and its surrounding transportation system is the automation of the logistical operations which were manually performed up to that time. The initial requirements acting as entry points in the existing architecture Arch n-1 are represented in grey in figure 6.30. They all state the need for automating the logistical operations: loading & unloading operations performed by the machine operator and logistic operators, transportation operations performed by trains and lift-trucks.

Change-oriented conceptual solution

No flexible solutions for automation were able to be retrieved from the various existing operations. Moreover, requirements for automating the logistical operations have impacted most of the sub-systems (operators, input stock, output stock, tooling, bar-code machine, lift-truck, input train) excepting the press and the MIG-MAG welding machine. The re-configuration process was therefore change-oriented from the architecture of reference Arch n-1 . The design rationale supporting the change elicitation process is illustrated in figure 6.31. Change propagation analysis is not presented, but the resulting impacted artifacts by major changes are retrieved. The red artifacts symbolize the final solution concepts and their integration in the new system configuration Conf n . The decision about the output transportation system solution is not represented but follows the same design rationale as the input transportation system solution.

Because requirements were highly-coupled from one sub-system to another, the press cell, the transportation system and their complex interfaces were treated together in the design project. For instance, from i-req 3 & 4 the robot solution requires a highly precision of part disposal in the stock. I-req 6 is satisfied by the AGV solution, and i-req 5 requires trolleys carried by the AGVs to be removable and to become the input stocks of the press cell. As a result, the input transportation system is responsible for being the shop stock input of the press cell and guaranteeing the precision of parts' placement. This solution postpones the task for accurate placement of parts on trolleys to the mass stock where operators fill trolleys with raw parts. This example illustrates how a requirement about accurate placement of parts during the picking operation of the robot impacts the transportation system, which impacts in turn operators in charge of filling parts on trolleys in the mass stock. At each design stage (i.e. requirement analysis, allocation to structural elements or architecture synthesis), various other artifacts were added regarding different viewpoints as security, maintenance, accuracy, tolerances, ergonomic and other business-rules constraints. Input trolley & robot requirement analysis Another full sub-design problem is the interfaces between the transportation system and the press cell. The interface with the input transportation system, namely between the robot's tool and the trolley storing the raw parts is firstly studied. The rationale-based architecture (see figure 6.35) reveals that the requirements allocated to the elements interfaced with the input transportation system (AGVs, trolley A, fixtures A, trolley B, fixtures B) are highly coupled with the requirements relating to the press-cell's elements (robot, gripper, pneumatic grips and stand side-members).

The design problem involves co-design between the robot and the trolley. The critical design parameters are the path trajectory of the robot, its cycle time, the geometric specifications of the gripper, the pneumatic grips and the stand side members, the positioning of parts on trolley A, the fixtures on trolley A and the cycle time for filling the trolley by operators in mass stock. The co-design difficulty is also heightened by the segmentation of sub-system's projects asynchronously led by the different designer companies. In short, the trolley is specified by the customer F (Faurecia), AGVs by the supplier C and the integration of the robot in the cell by supplier N. Because they are not independent sub-systems (trolleys should be integrable with AGVs, Robot and Axis), the role of the customer F is crucial to specify interfaces to designer suppliers, so that the integrability between the sub-systems is guaranteed. From the first stages of this redesign process (Conf n ), designers acknowledged the uncertainty of future design evolutions even during the development project. Arch n was informally considered by designers but without tracing formally the design rationale for changeability. A retrospective list of forecast scenarios at period n is formalized in table 6.7 regarding the time scale, probability, reason type and allocated system elements. It is apparent that the project was carried out during the preliminary design stages since a lot of solutions were not decided yet, and the dimensioning design was not ready to be performed.

6.5.2 Redesign (n to n + 1) The existence of DFC considerations in Arch n was previously presented. The real denouement through the redesign processes leading to Conf n+1 is now presented. Based on that, an evaluation of DFC practices is suggested. The motivation is not about testing the clairvoyance of designers (e.g. scenarios 1, 2, 3, 5, 8, did not occur at least at a project-scale), but more to analyze in what extent DFC was embodied and how it could have been improved. It is observed that:

1. Most of the forecast scenarios were at a short-term level for DFC 2. Short-term scenarios were not systematically anticipated. Needs and means for DFC relied on designers' knowledge and comprehension of the problem. For instance, the need for interchangeability between the robot and the robot's tool was clear from the outset while the needs for adding a decentralized store, a logistic operator and an intermediate shop stock between the press cell and the assembly lines came late because logistic strategy teams were not initially part of the project. These latter changes arose from the plant level design (section 6.2) (see figure 6.42 and appendix A.8).

3. Even though the change enablers solutions were implied during discussions about uncertainty in design scenarios, solutions for changeability were neither systematically traced or formalized for Arch n . The system engineering process was restricted to the support of the configuration Conf n , but less for Arch n 4. Modular design was thought within the limits of system engineering complexity. Straight-forward intuitions led designers to separate the system project into different sub-projects (i.e. press cell project, transportation system project, input transportation project, output transportation project, AGVs design project, trolley design project etc.). It has undeniably helped to limit change propagation during redesign for Conf n+1 . However, modularity and integrability were not systematic in the rationalebased architecture, especially at lowest levels.

Validation and comparison of estimated Arch n

In order to validate the interest for DFC methodology such as presented in chapter 5, the following paragraphs estimate the outcomes under the same scenario conditions of period n -1 in using the DFC methodology (Arch n ). A quantitative comparison between ROI(Arch n , {Conf 0-n }) and ROI(Arch n , {Conf 0-n }) would have proved the interest for DFC methodology in a quantifiable way. This estimation of the ROI (see section 5.3.6) would have required: 1-a detailed and accurate evaluation of the allocated time, human resources, material resources and efforts involved in the reconfiguration Cost(Arch n → Conf 0-n ) and the investment cost for upgrading the architecture (Cost(Arch n-1 → Arch n )), 2-a longer scale of time with occurrence of previously forecast scenarios (only scenarios 10, 11, 12 were performed), 3-a mature Arch n regarding forecast scenarios. Neither of these three conditions were met. Regarding the third requirement, solutions for Arch n are presented in table 6.9. The DFC strategies and solutions are listed and based on the original forecast scenarios of table 6.7, assuming they would have been the same for Arch n and Arch n . The estimated benefits provided by the DFC methodology are:

1. Due to the systemic nature of the approach, larger considerations in time-scale, domains and viewpoints are investigated during scenarios forecast 2. DFC provides effective guidance during change enablers analysis and synthesis in a systemic way

Chapter 7

Conclusion and future directions

"There can be no life without change, and to be afraid of what is different or unfamiliar is to be afraid of life" Theodore Roosevelt

Outcomes

There is in 2016 a whole market for changeability in industry; the race to deploy greenfield and optimized systems for immediate production contexts is progressively replaced by strategies transforming existing systems (re-design). Due to market fluctuations, changeability is recognized as a critical property in the manufacturing system and engineering design domains to increase systems' lifetime. Comparing manufacturing systems to complex and pluri-disciplinary systems, this research work is innovative as it subscribes to both domains. Following a systems engineering approach, a formalization for system modeling during the design process is first established; the rationale-based architecture organizes design artifacts (structural blocks and requirements) and their connections reflect the rationale of the designers. It enlarges the usual representation domain for change propagation. Using this formalism, the methodology for changeable systems supports both the design for changeability process (design of the architecture of reference) and the redesign with reuse of changeability process (design of configurations deriving from the architecture of reference), going along with a system engineering design process as well. This work goes beyond a prescriptive framework, through guide-lines, process models and associated tools. Methodological aspects have been illustrated during several industrial projects with an automotive supplier, and validated in comparing their practices with the results that the methodological contribution would have provided in the same context. The observed outcomes satisfy the stated requirements for the thesis concept in section 3.2:

1. Changeability is taken in a systemic way throughout the conceptual phase and the detailed phase, the variety of design viewpoints, and the whole system lifecycle (Requirement 1). In doing so, changeability is designed and reused at any level in the system architecture, with any type of design artifact (Requirement 2).

2. The analysis, synthesis and evaluation stages for changeability design or for re-design are integrated into the engineering design processes (Requirement 3); this moves changeability from an optional, and most of the time abstract, design viewpoint to a critical and strongly supported one.

3. Although processes for re-design and design for changeability are separately presented, they can be performed as complementary viewpoints within same design projects (Requirement 4).

Perspectives for future tools to support design

Research Question RQ3 stated in chapter 3 ("What type of design support embodiment should be successful regarding previous requirements ?") has been answered with the methodology outlined in this manuscript, namely a collection of tools, methods and processes. The prescribed tools were modeling ones, assuming engineering design is a complex activity that should first be supported with methodological prescriptions.

According to the differentiation between process, method, tool and methodology made in [Estefan, 2007], a tool is an instrument that can enhance processes ("what" is to be done) and methods ("how" tasks are performed). In order to enhance the proposed methodology, intelligent tools could be developed for better assistance in engineering design processes. The formalisms, ontologies and methodologies proposed in this manuscript serve as starting points for future research. Figure 7.1 summarizes three examples of future tools that could be developed in accordance with the thesis concept. They also encompass opportunities to scale up existing market tools (PLM or MBSE software). Some rules for consistency evaluation and design problem formulation relying on a rationale-based system architecture have already been stated in section 4.6.2. They could easily be integrated into a future rule-based system. A Case Based Reasoning (CBR) approach for change propagation evaluation is presented in section 7.2.2. Insights are given for applications to design for changeability and redesign phases. Section 7.2.3 presents the architecture of a Multi-Agent-System (MAS) in which various viewpoints (domain-dependent and domain-independent) collaborate together.

Systemic Design Methodology for Changeable Systems

Short review of AI mechanisms in engineering design

Knowledge intensive, ill-defined, open and complex design problems raise the need to assist engineers with design support tools instead of prescribing methodologies and frameworks. Research into applications of Artificial Intelligence (AI) mechanisms to assist and offer comprehensive support during the engineering design process represents a major breakthrough in the literature. [START_REF] Wang | Collaborative conceptual design -state of the art and future trends[END_REF] reveal that design tools are more prevalent in detailed design than conceptual design, whereas conceptual design includes the highest design opportunities and impacts. Because supporting the generation of concepts, evaluation and reuse is problematic, they encourage research into AI design tools applied to collaborative and multidisciplinary conceptual design (e.g. web-based collaborative design, modeling and data sharing, design services, knowledge management, etc.). Considering design as an ill-defined, open-ended and wide-ranging domain is still a challenge for AI tools.

Regarding recent breakthroughs with deep learning techniques using Convolutional Neural Networks, more applications to design should be explored. Reasoning about design means providing relevant knowledge to designers, making Knowledge Engineering (KE) a critical topic in the development of design tools. KBS were first seen as a transfer of knowledge from expert humans to computers (rule-based expert systems). [START_REF] Studer | Knowledge engineering: principles and methods[END_REF]] describe the paradigm shift of KBS from a transfer approach of domain design knowledge to a modeling approach. Various concepts and methods relating to Knowledge Engineering are: Rule-Based Systems, Neural Networks, Fuzzy expert systems, Object-oriented methodology, CBR, Intelligent agents, Problem Solving methods, Ontology, Modeling Frameworks for KBS. [Liao, 2005] lists their applications in various research areas. [START_REF] Bakhtari | Bridging the gap between AI technology and design requirements[END_REF]] listed in the nineties some AI functionalities which the design support systems should provide to designers: 1-support the users with relevant information 2-assist negotiation through conflict and version management 3-assess the quality 4-assist innovation. Motivations for developing a CBR for change propagation evaluation and an MAS for a collaborative design environment subscribe to the first two objectives: change propagation evaluation is a knowledge-intensive process, and re-design and design changeability required collaboration and negotiation.

Change propagation evaluation -Case Based Reasoning

One of the thesis statements was that change propagation is not limited to physical interactions but can apply between any artifacts for the rationale-based architecture. Moreover, tracking change by checking the presence of links in design models is irrelevant if knowledge about margin effects, type of links and type of change is ignored. An intelligent tool for change propagation evaluation could also improve today's "change tracking" options offered by the editors of these tools. The objective of such tools is to learn and retrieve knowledge about propagation patterns so that changeability can be reused and evaluated during the redesign phase and the design for changeability phase.

Motivations for the case-based reasoning paradigm Rule-Based expert systems were highly developed in the 70s and 80s. They represent domain knowledge through causal relations (e.g. [START_REF] Heragu | Analysis of expert systems in manufacturing design[END_REF] develops "if-then rules" for manufacturing system problems: part design, process planning, equipment selection and facility layout). [Schank, 1987] criticizes rules-based expert systems due to the time-consuming expert knowledge elicitation and the difficulty of exploring new problems when they are not covered by the KB. Machine Learning techniques like Artificial Neural Networks also generalize design knowledge without requiring explicit domain knowledge to be available. They capture knowledge by training a model through a set of examples; after the validation phase the model is exploited for new instances. Although recent research on machine learning improves upon dynamic learning whenever training examples are available ("incremental learning" [Giraud-Carrier, 2000]), these techniques assume a degree of homogeneousness between a large number of problem instances that makes them unsuitable for design, especially conceptual design [Rentema, 2004]. Design reasoning rarely follows causal and deterministic relations between problems and solutions, but is rather characterized by ill-structured, unformalized, broad-range and unstable knowledge. Ensuing from these criticisms, CBR has emerged as a relevant paradigm for illstructured domains such as design. CBR is a general paradigm for reasoning from experience; it does not attempt to solve problems by exploiting general knowledge, but reasons by analogy with cases encompassing local knowledge. Cases contain knowledge about solved problem instances, namely the association between a problem and a solution: case=(pb,Sol(pb)). A memory model indexes and organizes past cases, so that designers can reuse and adapt them to the current context. Several steps characterize CBR tools: 1-Retrieve similar cases by matching index and similarity measurements; 2-Reuse and adapt the past case to the current one; 3-Revise; 4-Retain the new case in the memory model. CBR cycles (i.e. retrieve, reuse and revise) are comparable to design tasks (i.e. propose, critique and modify) [START_REF] Watson | Case-based design: A review and analysis of building design applications[END_REF]. Application for change enabler design (modularity and interfaceability) The evaluation of change propagation reveals the performance of the change enablers regarding a changing situation. Modularity can be reached by clustering elements whose change at interfaces induces change propagation to others (high coupling between internal interfaces). Interfaceability is designed to improve the ability of an external interface to absorb change (i.e. margins), so that the connected elements are not altered by change. An automated evaluation of change propagation would enable later applications in re-design and design for changeability phases to improve changeability performances: suggestions of modules to designers, suggestions of critical interfaces for better interfaceability.

Figure 1 . 1

 11 Figure 1.1 Changes in Manufacturing System Paradigms . . . . . . . . . . . . . . . . . . Figure 1.2 Production system levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 1.3 Design Activities relating to manufacturing system design . . . . . . . . . . . Figure 1.4 Manufacturing System Paradigms inspired by[START_REF] Koren | Design of reconfigurable manufacturing systems[END_REF] . . Figure1.5 Non-functional requirements[START_REF] Firesmith | The method framework for engineering system architectures[END_REF] . . . . . . . . . . . . . . Figure 1.6 Plan of the manuscript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 2 . 8

 28 Figure 2.1 Research domains of interest . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2.2 Manufacturing systems life cycle [ElMaraghy, 2006b] . . . . . . . . . . . . . . Figure 2.3 Design issues of an RMS[START_REF] Bi | Reconfigurable manufacturing systems: the state of the art[END_REF] . . . . . . . . . . . . . . . . . . . . . Figure2.4 Interactions between product, process & system domains[Rampersad, 1996] . Figure2.5 Domains influencing manufacturing system design . . . . . . . . . . . . . . . Figure2.6 Classification of integrated manufacturing system design approaches . . . . . Figure2.7 Interaction-modeling-based approaches for manufacturing system design . . . Figure 2.8 Correlation between design activities . . . . . . . . . . . . . . . . . . . . . . . Figure 2.9 Levels of assembly systems [Scholz-Reiter and Freitag, 2007] . . . . . . . . . . Figure 2.10 Class diagram for manufacturing systems . . . . . . . . . . . . . . . . . . . . Figure 2.11 Design framework of reference . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2.12 Reconfigurability characteristics [Rösiö, 2012] . . . . . . . . . . . . . . . . . . Figure 2.13 Change ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2.14 Change propagation behaviors [Eckert et al., 2004] . . . . . . . . . . . . . . .Figure 2.15 IDEF-0 Interrelated engineering change approaches . . . . . . . . . . . . . . .

Figure 3 . 1

 31 Figure 3.1 Dimensions of the methodological contribution . . . . . . . . . . . . . . . . .

Figure 4 .

 4 Figure 4.1 V-model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 4.2 Progressive and iterative artifacts definitions . . . . . . . . . . . . . . . . . .Figure 4.3 Design process model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 4.4 Alternating design views through the design process . . . . . . . . . . . . . .Figure 4.5 System Engineering artifacts classification . . . . . . . . . . . . . . . . . . . .Figure 4.6 Relationships between behavioral requirements and functional requirements .Figure 4.7 Taxonomy of system engineering artifacts relationships . . . . . . . . . . . . .Figure 4.8 Physical association relationships between structural blocks . . . . . . . . . .Figure 4.9 Example of < ref ine > relationship . . . . . . . . . . . . . . . . . . . . . . .

Figure 4 . 3

 43 Figure 4.1 V-model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 4.2 Progressive and iterative artifacts definitions . . . . . . . . . . . . . . . . . .Figure 4.3 Design process model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 4.4 Alternating design views through the design process . . . . . . . . . . . . . .Figure 4.5 System Engineering artifacts classification . . . . . . . . . . . . . . . . . . . .Figure 4.6 Relationships between behavioral requirements and functional requirements .Figure 4.7 Taxonomy of system engineering artifacts relationships . . . . . . . . . . . . .Figure 4.8 Physical association relationships between structural blocks . . . . . . . . . .Figure 4.9 Example of < ref ine > relationship . . . . . . . . . . . . . . . . . . . . . . .

Figure 4 . 4

 44 Figure 4.1 V-model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 4.2 Progressive and iterative artifacts definitions . . . . . . . . . . . . . . . . . .Figure 4.3 Design process model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 4.4 Alternating design views through the design process . . . . . . . . . . . . . .Figure 4.5 System Engineering artifacts classification . . . . . . . . . . . . . . . . . . . .Figure 4.6 Relationships between behavioral requirements and functional requirements .Figure 4.7 Taxonomy of system engineering artifacts relationships . . . . . . . . . . . . .Figure 4.8 Physical association relationships between structural blocks . . . . . . . . . .Figure 4.9 Example of < ref ine > relationship . . . . . . . . . . . . . . . . . . . . . . .

Figure 4 . 5

 45 Figure 4.1 V-model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 4.2 Progressive and iterative artifacts definitions . . . . . . . . . . . . . . . . . .Figure 4.3 Design process model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 4.4 Alternating design views through the design process . . . . . . . . . . . . . .Figure 4.5 System Engineering artifacts classification . . . . . . . . . . . . . . . . . . . .Figure 4.6 Relationships between behavioral requirements and functional requirements .Figure 4.7 Taxonomy of system engineering artifacts relationships . . . . . . . . . . . . .Figure 4.8 Physical association relationships between structural blocks . . . . . . . . . .Figure 4.9 Example of < ref ine > relationship . . . . . . . . . . . . . . . . . . . . . . .

Figure 4 . 6

 46 Figure 4.1 V-model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 4.2 Progressive and iterative artifacts definitions . . . . . . . . . . . . . . . . . .Figure 4.3 Design process model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 4.4 Alternating design views through the design process . . . . . . . . . . . . . .Figure 4.5 System Engineering artifacts classification . . . . . . . . . . . . . . . . . . . .Figure 4.6 Relationships between behavioral requirements and functional requirements .Figure 4.7 Taxonomy of system engineering artifacts relationships . . . . . . . . . . . . .Figure 4.8 Physical association relationships between structural blocks . . . . . . . . . .Figure 4.9 Example of < ref ine > relationship . . . . . . . . . . . . . . . . . . . . . . .

Figure 4 . 7

 47 Figure 4.1 V-model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 4.2 Progressive and iterative artifacts definitions . . . . . . . . . . . . . . . . . .Figure 4.3 Design process model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 4.4 Alternating design views through the design process . . . . . . . . . . . . . .Figure 4.5 System Engineering artifacts classification . . . . . . . . . . . . . . . . . . . .Figure 4.6 Relationships between behavioral requirements and functional requirements .Figure 4.7 Taxonomy of system engineering artifacts relationships . . . . . . . . . . . . .Figure 4.8 Physical association relationships between structural blocks . . . . . . . . . .Figure 4.9 Example of < ref ine > relationship . . . . . . . . . . . . . . . . . . . . . . .

Figure 4 .

 4 Figure 4.10 Hierarchical relationships between components . . . . . . . . . . . . . . . . . Figure 4.11 Overview of relationships between system engineering elements . . . . . . . . Figure 4.12 Example of < satisf y > relationship . . . . . . . . . . . . . . . . . . . . . . . Figure 4.13 Example of < allocate > relationship . . . . . . . . . . . . . . . . . . . . . . . Figure 4.14 Relationships between project elements in rationale and physical domains . .Figure 4.15 Example of rationale-based architecture . . . . . . . . . . . . . . . . . . . . .Figure 4.16 MDM for problem and solution domains . . . . . . . . . . . . . . . . . . . . .Figure 4.17 System engineering elements indirectly related to the operating press cell block Figure 4.18 Intelligent system responsible of analysis and evaluation activities . . . . . . . Figure 4.19 Sequence diagram between users and design system . . . . . . . . . . . . . . .

Figure 4 .

 4 Figure 4.10 Hierarchical relationships between components . . . . . . . . . . . . . . . . . Figure 4.11 Overview of relationships between system engineering elements . . . . . . . . Figure 4.12 Example of < satisf y > relationship . . . . . . . . . . . . . . . . . . . . . . . Figure 4.13 Example of < allocate > relationship . . . . . . . . . . . . . . . . . . . . . . . Figure 4.14 Relationships between project elements in rationale and physical domains . .Figure 4.15 Example of rationale-based architecture . . . . . . . . . . . . . . . . . . . . .Figure 4.16 MDM for problem and solution domains . . . . . . . . . . . . . . . . . . . . .Figure 4.17 System engineering elements indirectly related to the operating press cell block Figure 4.18 Intelligent system responsible of analysis and evaluation activities . . . . . . . Figure 4.19 Sequence diagram between users and design system . . . . . . . . . . . . . . .

Figure 5 . 1

 51 Figure 5.1 Scales for system evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5.2 Representation of a changeable system . . . . . . . . . . . . . . . . . . . . . . Figure 5.3 Opportunistic reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5.4 Reuse from a fixed architecture of reference . . . . . . . . . . . . . . . . . . . Figure 5.5 Reuse and a-posteriori leveraging . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5.6 Reuse and a-priori leveraging . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5.7 IDEF-0 Life-cycle model for the design of changeable system design . . . . . Figure 5.8 Reuse strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5.9 Iterative and progressive redesign process model . . . . . . . . . . . . . . . . Figure 5.10 State-flow diagram for reuse of existing changeability . . . . . . . . . . . . . . Figure 5.11 Classification of system elements according to levels of reusability . . . . . . Figure 5.12 Manufacturing system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5.13 Flexible scenario from the rationale-based architecture of system 5.12 . . . . Figure 5.14 Physical configuration for a manufacturing system . . . . . . . . . . . . . . . Figure 5.15 Reconfigurability scenario example . . . . . . . . . . . . . . . . . . . . . . . . Figure 5.16 Rationale architecture of a manufacturing system . . . . . . . . . . . . . . . . Figure 5.17 DSM between system engineering artifacts from example figure 5.16 . . . . . Figure 5.18 MDM between system engineering artifacts from example figure 5.16 . . . . . Figure 5.19 Design for changeability process model . . . . . . . . . . . . . . . . . . . . . . Figure 5.20 Outcomes of design for changeability process . . . . . . . . . . . . . . . . . . Figure 5.21 Extended scenario tree representation [Terkaj et al., 2009b] . . . . . . . . . . Figure 5.22 Profile for changeability drivers to manufacturing systems . . . . . . . . . . . Figure 5.23 Changeability requirement types . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5.24 Enabling properties for change scenarios in example in figure 5.25 . . . . . . Figure 5.25 Global synthesis of required changes on AGV element for Arch n . . . . . . . Figure 5.26 Changeability strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5.27 Global synthesis of required changes on AGV element for Arch n . . . . . . . Figure 5.28 Modules, interfaces and margins relationships . . . . . . . . . . . . . . . . . . Figure 5.29 Example of margins definition . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5.30 Example of modules and margins relationships . . . . . . . . . . . . . . . . . Figure 5.31 Module and interface types according to changeability strategies . . . . . . . Figure 5.32 Evaluation of changeability approach . . . . . . . . . . . . . . . . . . . . . . .

Figure 7 . 1

 71 Figure 7.1 Future tools development . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 7 .

 7 Figure 7.2 UML diagram for "change propagation pattern" cases . . . . . . . . . . . . . Figure 7.3 Illustration of a change propagation pattern . . . . . . . . . . . . . . . . . . . Figure 7.4 Illustration of change propagation pattern . . . . . . . . . . . . . . . . . . . . Figure 7.5 Representation of modularity and interfaceability . . . . . . . . . . . . . . . . Figure 7.6 Collaborative Design Environment for changeability design methodology . . .

  Figure 1.2: Production system levels

  Figure 1.4: Manufacturing System Paradigms inspired by[START_REF] Koren | Design of reconfigurable manufacturing systems[END_REF]

Figure 1

 1 Figure 1.6: Plan of the manuscript

Figure 2

 2 Figure 2.2: Manufacturing systems life cycle[START_REF] Elmaraghy | Flexible and reconfigurable manufacturing systems paradigms[END_REF]

Figure 2

 2 Figure 2.3: Design issues of an RMS[START_REF] Bi | Reconfigurable manufacturing systems: the state of the art[END_REF]

Figure 2 . 5 :

 25 Figure 2.5: Domains influencing manufacturing system design

Figure 2 . 6 :

 26 Figure 2.6: Classification of integrated manufacturing system design approaches

  Figure 2.7: Interaction-modeling-based approaches for manufacturing system design

Figure 2

 2 Figure 2.8: Correlation between design activities

  shop, DMS, cellular manufacturing, assembly line, FMS, FFMS or RMS [ElMaraghy, 2006a] Shape Product flow layout (the shape follow the material flow between stations): Line, U-Shaped, Loop or network [ElMaraghy, 2006a], ladder shape (alternative paths for material flows) or Process layout (the division of shop-floor in cells follows the parts functions): Job shop or cellular shop Segment flow Direction (Uni-directional or bi-directional), control (synchronous or asynchronous), flow control junction (one to one; one to many or many to many) System control Control structure Direct, distributed or hierarchical ('LCC Layout Complexity Code' [ElMaraghy, 2006a]) Production unit Production unit type Manufacturing cell, machine tool, work center for manufacturing; manual, hybrid or automated assembly single station assembly, single station assembly with set-wise assembly flow, single station assembly according to the once-piece-flow principle, multi-station assembly machine

  5: Survey of prescribed design viewpoints

Figure 2 .

 2 Figure 2.11: Design framework of reference

  Figure 2.13: Change ontology

Figure 2 .

 2 Figure 2.14: Change propagation behaviors[START_REF] Eckert | Change and customisation in complex engineering domains[END_REF]

  Figure 3.1: Dimensions of the methodological contribution

  Figure 4.1: V-model

Figure 4 . 3 :

 43 Figure 4.3: Design process model

  Figure 4.4: Alternating design views through the design process

Figure 4 . 7 :

 47 Figure 4.7: Taxonomy of system engineering artifacts relationships

Figure 4 . 8 :

 48 Figure 4.8: Physical association relationships between structural blocks

Figure 4

 4 Figure 4.9: Example of < ref ine > relationship

Figure 4

 4 Figure 4.12: Example of < satisf y > relationship

Figure 4

 4 Figure 4.14: Relationships between project elements in rationale and physical domains

Figure 4 .

 4 Figure 4.16: MDM for problem and solution domains

Figure 4 .

 4 Figure 4.17: System engineering elements indirectly related to the operating press cell block

Figure 4 .

 4 Figure 4.18: Intelligent system responsible of analysis and evaluation activities

Figure 4 .

 4 Figure 4.19: Sequence diagram between users and design system

Figure 5

 5 Figure 5.1: Scales for system evolution

Figure 5

 5 Figure 5.2: Representation of a changeable system

  Figure 5.3: Opportunistic reuse

Figure 5 . 4 :

 54 Figure 5.4: Reuse from a fixed architecture of reference

  Figure 5.5: Reuse and a-posteriori leveraging

Figure 5

 5 Figure 5.6: Reuse and a-priori leveraging

Figure 5

 5 Figure 5.7: IDEF-0 Life-cycle model for the design of changeable system design

Figure 5

 5 Figure 5.8: Reuse strategies

  Figure 5.10: State-flow diagram for reuse of existing changeability

Figure 5

 5 Figure 5.11: Classification of system elements according to levels of reusability

-Figure 5

 5 Figure 5.12: Manufacturing system

  Figure 5.14: Physical configuration for a manufacturing system

Figure 5

 5 Figure 5.15: Reconfigurability scenario example

  Figure 5.16: Rationale architecture of a manufacturing system

Figure 5 .

 5 Figure5.17: DSM between system engineering artifacts from example figure5.16

Figure 5

 5 Figure 5.18: MDM between system engineering artifacts from example figure 5.16

Figure 5 Figure 5

 55 Figure 5.19: Design for changeability process model

Figure 5 .

 5 Figure 5.25: Global synthesis of required changes on AGV element for Arch n

  Figure 5.26: Changeability strategies

Figure 5

 5 Figure 5.28: Modules, interfaces and margins relationships

Figure 5 Figure 5

 55 Figure 5.29: Example of margins definition

Figure 5

 5 Figure 5.31: Module and interface types according to changeability strategies

  Figure 5.32: Evaluation of changeability approach

"

  If the first thinking process should lead us to answer the question 'what to change?' the second thinking process should lead us to answer the question 'what to change to?' I can already see the need for a third thinking process. -Yes, so can I. 'How to cause the change.'"

Figure 6 . 1 :

 61 Figure 6.1: Seat frame components (www.faurecia.com)

  Figure 6.2: Identified sub-systems for case studies

Figure 6

 6 Figure 6.5: Initial logistic configuration Faurecia plant

  Figure 6.12: Illustration of indirect required changes

  Figure 6.14: DSM of physical artifacts from output flow architecture Arch n-1

  Figure 6.18: Manual Assembly Lines configuration Conf n-1 & Arch n-1

Figure 6 .

 6 Figure 6.19: Rationale-based architecture eliciting changes from Arch n-1 to Conf n+1

Figure 6 .

 6 Figure 6.20: Assembly line layout Conf n+1 & Arch n+1

Figure 6 .

 6 Figure 6.21: Carrier for cushion frames

Figure 6 .

 6 Figure 6.22: Buffer stations in the assembly line layout

Figure

  Figure 6.23: Cable management

6. 4

 4 Figure 6.25: System of interest: Cushion Frame segment line Conf n-1

Figure 6 .

 6 Figure 6.28: Expanding press

Figure 6 .

 6 Figure 6.29: Input transportation system

Figure 6 .

 6 Figure 6.30: Initial requirements allocated to Arch n-1

  Figure 6.35: Input trolley & Robot rationale-based architecture

Figure 6 .Figure 6

 66 Figure 6.37: Trajectory Robot simulation & validation on RobotStudio R

  Figure 6.41: Arch n → Conf n+1

∅Figure 6

 6 Figure 6.42: Solution concept Conf n+1

  Figure 7.1: Future tools development

Figure 7 . 4 :

 74 Figure 7.4: Illustration of change propagation pattern

Figure 7

 7 Figure 7.5: Representation of modularity and interfaceability

7

  Conclusion and future directions 7.1 Outcomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Perspectives for future tools to support design . . . . . . . . . . . . . . . . . . . . . . 7.2.1 Short review of AI mechanisms in engineering design . . . . . . . . . . . . . . 7.2.2 Change propagation evaluation -Case Based Reasoning . . . . . . . . . . . . 7.2.3 Collaborative design environment -Multi Agent System . . . . . . . . . . . . Context Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2 External behavioral Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

	Bibliography
	Appendices
	A Systems Engineering models
	A.1

A.3 BDD (Block Diagram Definition) of system . . . . . . . . . . . . . . . . . . . . . . . A.4 Internal system behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.5 Swim -Lane representation of operations in the cell . . . . . . . . . . . . . . . . . . A.6 Press Cell Layout Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.7 AGV Behavioral requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.8 Material flow and information flow in segment line Conf n+1 . . . . . . . . . . . . . .

  . . . . . . . . . . Figure 5.22 Profile for changeability drivers to manufacturing systems . . . . . . . . . . . Figure 5.23 Changeability requirement types . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5.24 Enabling properties for change scenarios in example in figure 5.25 . . . . . . Figure 5.25 Global synthesis of required changes on AGV element for Arch n . . . . . . . Figure 5.26 Changeability strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5.27 Global synthesis of required changes on AGV element for Arch n . . . . . . . Figure 5.28 Modules, interfaces and margins relationships . . . . . . . . . . . . . . . . . . Figure 5.29 Example of margins definition . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 6.1 Seat frame components (www.faurecia.com) . . . . . . . . . . . . . . . . . . . Figure 6.2 Identified sub-systems for case studies . . . . . . . . . . . . . . . . . . . . . . Figure 6.3 Coupling of design activities through different periods of time . . . . . . . . . Figure 6.4 Redesign and design for changeability instances . . . . . . . . . . . . . . . . . Figure 6.5 Initial logistic configuration Faurecia plant . . . . . . . . . . . . . . . . . . . . Figure 6.6 Initial layout Faurecia plant Arch n-1 & Conf n-1 . . . . . . . . . . . . . . . . Figure 6.7 Rationale-based-architecture of reference for input flow Arch n-1 . . . . . . . Figure 6.8 Rationale-based-architecture of reference for output flow Arch n-1 . . . . . . . Figure 6.9 DFC approach from n -1 to n + 1 . . . . . . . . . . . . . . . . . . . . . . . . Figure 6.10 Scenario tree of the future redesign projects of the plant . . . . . . . . . . . . Figure 6.11 Rationale-based Architecture of reference for input flow Arch n+1 . . . . . . . Figure 6.12 Illustration of indirect required changes . . . . . . . . . . . . . . . . . . . . . Figure 6.13 DSM of elements connected to the transportation path shape Arch n+1 . . . . Figure 6.14 DSM of physical artifacts from output flow architecture Arch n-1 . . . . . . . Figure 6.15 DSM of physical artifacts from output flow with modularity strategy . . . . . Figure 6.16 Final layout Faurecia plant Arch n+1 . . . . . . . . . . . . . . . . . . . . . . . Figure 6.32 System engineering process for Conf n . . . . . . . . . . . . . . . . . . . . . . Figure 6.33 System of interest digital mock-up with FlexSim R . . . . . . . . . . . . . . . Figure 6.34 Flow simulation with Flexsim R . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 6.35 Input trolley & Robot rationale-based architecture . . . . . . . . . . . . . . . Figure 6.36 Filling trolley operation simulation in FlexSim R . . . . . . . . . . . . . . . . Figure 6.37 Trajectory Robot simulation & validation on RobotStudio R . . . . . . . . . Figure 6.38 Output trolley rationale-based architecture . . . . . . . . . . . . . . . . . . . Figure 6.39 Transportation system layout . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 6.40 Network deployment diagram . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 5.30 Example of modules and margins relationships . . . . . . . . . . . . . . . . . Figure 5.31 Module and interface types according to changeability strategies . . . . . . . Figure 5.32 Evaluation of changeability approach . . . . . . . . . . . . . . . . . . . . . . . Figure 6.17 Assembly Line operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 6.18 Manual Assembly Lines configuration Conf n-1 & Arch n-1 . . . . . . . . . . Figure 6.19 Rationale-based architecture eliciting changes from Arch n-1 to Conf n+1 . . . Figure 6.20 Assembly line layout Conf n+1 & Arch n+1 . . . . . . . . . . . . . . . . . . . Figure 6.21 Carrier for cushion frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 6.22 Buffer stations in the assembly line layout . . . . . . . . . . . . . . . . . . . . Figure 6.23 Cable management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 6.24 Standard Communication in the Assembly Line . . . . . . . . . . . . . . . . . Figure 6.25 System of interest: Cushion Frame segment line Conf n-1 . . . . . . . . . . . Figure 6.26 Component variety for frame seats and product families . . . . . . . . . . . . Figure 6.27 Sub-assembly and metal forming assembly process . . . . . . . . . . . . . . . Figure 6.28 Expanding press . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 6.29 Input transportation system . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 6.30 Initial requirements allocated to Arch n-1 . . . . . . . . . . . . . . . . . . . . Figure 6.31 Solution concept Conf n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 6.41 Arch n → Conf n+1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 6.42 Solution concept Conf n+1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

  Table 2.1 Comparison between FMS & RMS . . . . . . . . . . . . . . . . . . . . . . . . . Table 2.2 Layout configuration characteristics [ElMaraghy, 2006b] . . . . . . . . . . . . . Table 2.3 Line Balancing problems classification [Boysen et al., 2007] . . . . . . . . . . . Table 2.4 Taxonomies of manufacturing system components . . . . . . . . . . . . . . . . Table 2.5 Survey of prescribed design viewpoints . . . . . . . . . . . . . . . . . . . . . . Table 2.6 Classification of DFC approaches . . . . . . . . . . . . . . . . . . . . . . . . .

	ISF	Information Structure Framework
	KB	Knowledge-Base
	KBS	Knwoledge-Base-System
	KE	Knowledge Engineering
	LB	Line Balancing
	Acronyms LIFO Last In First Out LL Line Layout Chapter 1
	MALB	Mixed-model Assembly Line Balancing
	MAS	Multi-Agent-System
	MBSE	Model-Based System Engineering
	AD MDM	Axiomatic Design Multidomain Design Matrix
	AFIS MOMS	Association Française d'Ingénierie Système Manufacturing Operations Management Systems
	AGV MPS	Automated Guided Vehicle Modular Production System
	AI MSDD	Artificial Intelligence Manufacturing System Design Decomposition
	BDD NC	Blocks Definition Diagram Numerical Control
	BOM NPV	Bill of Materials Net Present Values
	CAD PF	Computer Assisted Design Product Family
	CBR PLC	Case Based Reasoning Programmable Logic Controller
	CM PLE	Configuration Management Product Line Engineering
	CNC PLM	Computer Numerical Control Product Lifecycle Management
	CPI QFD	Change Propagation Index Quality Function Development
	DCF RFID	Discounted Cash Flow Radio Frequency Identification
	DfA RMS	Design for Assembly Reconfigurable Manufacturing System
	DFC RMT	Design For Changeability Reconfigurable Machine Tool
	DfM ROI	Design for Manufacturing Return On Investment
	DMS RS	Dedicated Manufacturing System Reconfiguration Smoothness
	DP SALB	Design Parameter Single Assembly Line Balancing
	DSM SCADA Supervisory Control and Data Acquisition Design Structure Matrix
	DTM SoI	Design Theory and Methodology System of Interest
	EBOM SSFD	Engineering Bill Of Materials System State Flow Diagram
	ESM SysML	Engineering System Matrix Systems Modeling Language
	FBS UML	Function-Behavior-Structure Unified Modeling Language
	FBs	Functional Blocks
	FDO	Flexible Design Opportunity
	FFBD	Functional Flow Block diagram
	FFMS	Focused Flexible Manufacturing System
	FIFO	First In First Out
	FMS	Flexible Manufacturing System
	GALB	Generalized Assembly Line Balancing
	GT	Group Technology
	iBDD	Internal Definition Blocks Diagram
	INCOSE International Council on Systems Engineering
	IRF	Integrated Real Option Framework

Table 4.1 Existence rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 4.2 Completeness rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 5.1 Similarity analysis algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 5.2 Enablers for change scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 6.1 Changeability requirements and enablers . . . . . . . . . . . . . . . . . . . . . Table 6.2 Changeability requirements and enablers . . . . . . . . . . . . . . . . . . . . . Table 6.3 Changeability requirements and enablers . . . . . . . . . . . . . . . . . . . . . Table 6.4 Initial System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 6.5 Functional requirements and satisfying structural elements . . . . . . . . . . . Table 6.6 i/o signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 6.7 Forecast Scenarios from Arch n . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 6.8 Conf n+1 change elicitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table 6.9 Change enabler solutions for Arch n . . . . . . . . . . . . . . . . . . . . . . . .

  3.3), the research topic lies at the intersection of three domains of interest: System Engineering Design, Manufacturing Systems and Changeability. The state of the art about changeable manufacturing system design is thus studied under these perspectives (see figure2.1). The changeable manufacturing system paradigms (FMS and RMS) are reviewed in section 2.1. A survey about the existence and the type of systemic perspectives applied to manufacturing systems is presented in section 2.2. Finally with the system engineering design literature, engineering configurations are defined, and approaches dealing with changeability and engineering change in general are examined in section 2.3.

		2
		Systemic
		approaches for
	1	manufacturing	3
	RMS	system	Change
	FMS	management
	Manufacturing System domain	Changeability	methods	design domain System Engineering
	Figure 2.1: Research domains of interest

Table 2

 2

.1: Comparison between FMS & RMS

Table 2

 2

	Design Space	Exploration	(4)		Real Options	Valuation	Flexible	design	concept	evaluation	Analytical	model (DCF,	NPV)	Simulation	Validation
	Concept Generation (3)	Analysis Synthesis	Identification of areas to embeded flexibility Generate new oportunities for flexibility	Strategy Generation Enabler Identification	Real Options Identifications	Identification existing mechanisms and types Generate new mechanism and types of real options	Flexible design opportunities identification Risk Bayesian Susceptibility model prediction Selection of candidate elements for flexibility Flexible design concepts and mechanisms generation	Identify and generate potential flexible design concepts	Flexible strategy Flexible enablers & decision rules identification	System Analysis System Synthesis	Identification of components that need Clustering processes in system configuration flexibility and reconfigurability requirements	Synthesis	Analysis of requirements Changeability Changeability System design	levels enablers elements	Screening for change objects suitable Identification of change Identification enablers transitions	Location and type of changeability	Mature supporting methods & tools
	Uncertainty	Recognition	(2)		Uncertainty	model	Dependency	&uncertainty	analysis		Uncertainty	drivers	identification	Evaluation of	engineering	change	Change	source	Recognition	Anticipation	of future	evolutions
	Baseline	Design	(1)					Initial	design			Initial	solution
		Design	models			Mikaelian	et al., 2011	Hu and	Cardin,	2015		Cardin,	2013	Al-Zaher,	2013	Francalanza	et al., 2014	Allaverdi et	al., 2015	Fricke and	Schulz,	2005

.6: Classification of DFC approaches

  are represented in table 5.23 and illustrated in table 5.24 and figure 5.25. Exchangeable The visual inspection type A can be exchanged with the visual inspection type B. The pick and place station can be moved to any station. ScalableThe pick and place station can be scaled with another station. The manual station location can be scaled to any station Figure 5.24: Enabling properties for change scenarios in example in figure 5.25

	«block» Trolley B «block» Guiding wire Volume variations of parts on «block» AGV «block» Trolley A trolley «req» 1.7 Volume Scalable number «req» 1.8 Volume Long term Scalable «req» 1.1 Volume Can support new configuration or modular fixation «req» PF Different speed «req» 1.3 Volume Can support several variants «req» PV Can be deployed in different layout «req» Strategic Can be deployed for different destinations «req» Strategic New travels «req» Logistic process Short term scalable «req» 1.2 Volume «changedriver» Product Variant «changedriver» «block» Handling System Scalable «req» 1.3 Volume Could work faster «req» 1.4 Volume Can access new stock configuratio n «req» PF Can load new process plans/ trajectories/ programs «req» PF Tools can be changed easily or adapted for new components or products «req» PF Can support different variants with smallest CO «req» PV «changedriver» «block» Press Expanding Several speed modes «req» 1.6 Volume Can have new or changeable tools and fixtures «req» PF Have limited configuratio n of jigs and sensors for automatized mode/ manual «req» PF Can load new process plans/ programs «req» PF Can support different variants with smallest CO «req» PV Product volumes Processes «changedriver» Store «changedriver» External strategic motivation «block» Identification machine «block» Reject unloading system «block» Cell control «block» Charging system «block» Mechanisms Scalable «req» 1.5 Volume Can identify new product «req» PF Can load new process plans easily «req» PF Can load new process traceability programs easily «req» PF Can adapt to new components «req» PF Can adapt to new product «req» PF Can be adapted to different trolley size «req» Volume Can support different variants with smallest CO «req» PV Can support different variants with smallest CO «req» PV Can support different variants with smallest CO «req» PV Can be deployed in different layout «req» Strategic «changedriver» Product Family «changedriver» Logistic process «changedriver» Standards (protocols, SI, security) «block» Internal Stock Place «block» Reject stock «block» Unloading final part «block» Welding machine «block» Transportation control Volume variation «req» 1.9 Volume Can support new product «req» PF Can support new product «req» PF «block» System Control Scalable interface with cell control «req» Volume Scalable interface with AGVs «req» Volume Can adapt to new product «req» PF Can support different variants with smallest CO «req» PV Can support several variants «req» PF Can support several variants «req» PF Scalable interfaces with destination system «req» Volume Can be deployed or not «req» Strategic Can be deployed or not «req» Strategic «changedriver» Mnfg process «Changedriver» requirements Stereotypes Symbol Description Consequence on i Removable A ↔ ∅ m can be removed from i m is optional 0 -1 Addable ∅ ↔ A m can be added at location i m is optional 0 -1 Exchangeable A ↔ B m can be exchanged with m' at location i m is unique 1 Scalable A ↔ A, B, C m can be scalable to (m,m',m") at location i m is multiple 1-* Figure 5.23: Changeability requirement types Operation Requirements Removable The manual station can be removed Addable An unknown station can be added Storage system System A/S unit Visual inspect.A Pick & Place Manual station Removing Scalable Exchanging Visual inspect. B Model X refine Unknown Station Unknown Station Adding Process units Physical location Location A Location {B, C, D} Any location Physical location B Physical location {Z;Y} specify specify specify Exchanging Exchanging Scalable Any location Figure 5.22: Profile for changeability drivers to manufacturing systems Operation specify specify

  Representation of the initial architecture Arch n-1

	6.2 Automotive seating plant through design for changeability
	6.2.1
				Plant 2018
	Plant 2014	Pilot Line 2014	Plant 2015	and future
	Conf n-1		Conf n+1	Conf n∞
					Plant
	Arch n-1		Arch n+1
	Conf n-1 Arch n-1		Conf n+1 Arch n+1	Conf n∞	lines	Assembly
	Conf n-1 Arch n-1	Conf n Arch n	Conf n+1	Conf n∞	system	transportation	Press cell &
	Figure 6.4: Redesign and design for changeability instances

  The identifications of changeability strategies, changeability requirements and enablers regarding the classification in section 5.3.2 are summarized in table 6.1. From left to right, the table elicits the design process going from need scenarios to solutions identification.

	Changeability requirements and strategies
	Scen. Changeability strategy		Changeability requirement	Changeability enablers
	1	Convertibility (long-term)	New automated functional-	Modularity of new func-
					ities shall be added and	tionalities for simplicity of
					some exchanged in the in-	upgrade & Integrability of
					formation system	information system toward
					change
	2	Change-overability (short-	The number of transporta-	Modularity of transporta-
		term)			tion units shall be scalable:	tion units to enable scal-
					from 5 to 10. The speed	ability; either with train
					of transportation units shall	solution (in manual situa-
					also be scalable	tion) or with AGVs solution
					rather than fixed conveying
					system
	2	Built-in flexibility (short-	The speed of transportation	Robustness of transporta-
		term)			system shall be scalable	tion system toward speed
					change
	3	Convertibility (long-term)	Production units must un-	Integrability of the sur-
					dergo high change in being	rounding plant to enable
					added or removed	feasible major changes
	4	Convertibility (long-term)	Manufacturing and logis-	Modularity of output flow
					tics process characteristics	in order to limit dependen-
					can be added or removed	cies of internal changes
	5	Probability of Extensibility (long-term)	4.<Product Variant Change> within production units 6.<Logistic process change> New areas of stops for input flow 0.9 Due to scenarios 3 & 4, ar-Integrability of trans-
		Scenario	occurence	4.<Product Variant eas of stops at production	portation layout : standard
					Change> units are likely to be added 3.<Product Family Change>	1 and common straight line
			1		0.2 or removed	0.6	shape
	6	Convertibility (long-term)	The transport solutions for	Integrability of suround-
			0.9		5.<Logistic process change> Automatisation of transport input flow (currently trains)	ing interfaces (TPA and
		1.<Technology Change>	between units and TPA and output flow (currently	Production units) towards
		Traceability Information system	0.8 exchanged to a more au-lift-trucks) are likely to be	the new solution
			0.8		tomated solutions as AGVs
		2.<Product Volume Change>	in inputs or conveyors
		Perdiod n+1 Table 6.1: Changeability requirements and enablers Perdiod n+3 Perdiod n∞
		Figure 6.10: Scenario tree of the future redesign projects of the plant

Table 6

 6

	TPA (i-
	X
	1)

.3: Changeability requirements and enablers 6.3.1 Manual assembly line Conf n-1

  At period n + 1, a new design project occurrence has led to redesign Conf n to a new version Conf n+1 . The re-configuration process was not performed at a physical level since Conf n was not detailed for deployment specifications. Instead, it was performed at a system engineering level, bringing changes to models, requirements and structural blocks defined along the design process. The final outcome of Conf n+1 has been physically deployed in the plant in 2015. It raises the issue of the different natures of re-configuration processes, since Arch n-1 → Conf n+1 is a physical re-configuration process in the plant, whereas Arch n → Conf n+1 is a system engineering reconfiguration process, with partial validation of Conf n and Arch n in the pilot line. The challenge of global re-configuration in merging different configuration natures is beyond the scope of this work. This section addresses the re-configuration phase from Arch n to Conf n+1 . Table6.8 presents the elicited changes having defined the final configuration Conf n+1 whether they relate to forecast scenarios of table 6.7. Configurations are partially illustrated in figure6.41.

Table 6 .

 6 7: Forecast Scenarios from Arch n

	Changed artifacts	Change operation	Estimated deployment	Scen.
		type	cost
	Requirement "handling from input store to loading sys-	Links removal	∅			∅
	tem" is not anymore satisfied by a Robot
	Block "Cell operator" is added	Block addition	Wage cost			∅
	Requirement "handling from input stock to loading sys-	Links addition	Training			∅
	tem" is satisfied by a "cell operator"
	Block "Input stock" is added	Addition	Investment cost		∅
	Block "Welding cell" structural block is added	Addition	Investment, tools, pro-	12
			gramming,	sensors&
			maintenance cost
	Requirement "handling operation from engraving ma-	Requirement ad-	∅			∅
	chine to welding cell" is added	dition
	Requirement "handling operation from engraving ma-	Link addition	Interface development,	∅
	chine to welding cell" is satisfied by "Robot"		programming cost
	Block "loading system" is specified as a block "conveyor	Block specifica-	Investment,	interface	∅
	belt with transiting pallet"	tion	and detailed develop-
			ment cost
	Block "unloading system" composed the "welding cell" Link addition	Tools,	programming,	4
			sensors cost & mainte-
			nance cost
	Transportation system (trolley, AGV, Axis) is removed Links & Blocks	∅			∅
		removal
	Block "Intermediate shop stock" is added between	Block Addition	∅			∼ 10
	"welding cell" and "Assembly lines"
	Block "Output transportation system" composes the	Link Addition	∅			11
	block "Intermediate shop stock"
	Block "Intermediate shop stock" is specified as a "man-	Block Specifica-
	ually moving swinging chair"	tion

Table 6 .

 6 Virtual modularity for the cell un/loading places concept; they are specifiable due to open interface with transportation system, axis and press cell 4 Convertibility Clearance / empty space for adding resources since the module "unloading system" was poorly detailed 6Change-overability Trolley fixtures, robot path, press tooling shall be able to be changed in being modular and ready to be used during set-up phases ("plug and produce") 6Built-in flexibility Loading and unloading systems, and other system resources shall be robust toward different product variants within the same family 7Built-in flexibility and extensibilityInactivates interfaces with the transportation control system must be declared without being used in further development (flexibility), clearance for further development in programs shall be embodied (extensibility) 8 Convertibility Clearance for enabling several solution developments for axis, open interfaces with transportation system and press cell 9 Extensibility Addition of a new press cell, for two new assembly lines, with the same system control and transportation system. It results in need for physical clearance space for duplication, logical open interfaces from system control and transportation system with indepence between "cell control" program and "system control" program in the PLC (cf. figure 6.40) 10 Convertibility (Addition) Clearance for enabling additional internal stock during project phase, open interfaces with output AGV and micro-engraving machine 11 Convertibility Virtual modularity of the transportation system component, open interfaces with press cell and assembly lines regarding the different alternatives solutions (AGVs, hangers), clearance space for further development 9: Change enabler solutions for Arch n

	id	Changeability Strategy	Change enabler solutions
	1; 5	Convertibility & Scalability	Virtual modularity for the AGVs concept component; it is specifiable with
				one or several AGV instance
	2; 15 Convertibility		Modular trolley with open interfaces with robot, operator at mass stock
				and AGVs requirements
	3	Convertibility:	Exchange-
		able

Jacque Fresco, inspired byBuckminster Fuller

DFC ensures re-use of changeability capability (i.e. flexibility, integrability, modularity) due to the traceability with the rationale-based architecture

The generic level of the methodology ensures its use in various classes of manufacturing systems, and it can be scaled-up with additional ontology for manufacturing system design (Requirement 5). Perspectives about assistance tools are specified to reduce the apparent complexity for designers.

Remerciements

This work has been sponsored by the French government research program Investissements d'avenir through the IMobS3 Laboratory of Excellence (ANR-10-LABX-16-01), by the European Union through the program Regional competitiveness and employment 2007-2013 (ERDF -Auvergne region) and by the Auvergne region 1 Ce travail a bénéficié d'une aide de l' État gérée par l'Agence Nationale de la Recherche au titre du programme Investissements d'avenir dans le cadre du projet LabEx IMobS3 (ANR-10-LABX-16-01), d'une aide de l'Union Européenne au titre 2007-2013 (FEDER -Région Auvergne) et d'une aide

Chapter 3

Research scope "The Factories of the Future PPP will generate reconfigurable, adaptive and evolving factories capable of high performance and small scale production. Resource efficiency in manufacturing, including end-of-life of products, will be linked to environmental sustainability in manufacturing" José Manuel Barroso, Preface to "EUROPE 2020, A European strategy for smart, sustainable and inclusive growth"

Work assumptions

For simplicity reasons, only four periods of time are distinguished within the sub-systems' lifecycle. But in reality, projects have continuously evolved between (n-1), (n) and (n+ 1) through plenty of incremental re-configurations. This raises the issue of the discretization of project configurations. Increments must not be too large, otherwise major design changes cannot be retrieved and tackled in real time; increments must not be too small, otherwise no useful knowledge on variability is provided to designers. Moreover, it is assumed that there is no need to consider precedences between configurations belonging to the same phase. Even though sub-system projects asynchronously evolve, it does not change the result of the different re-configuration processes. Finally, it is assumed that the number of sub-systems of interest (i.e. transportation system, press cell, assembly lines and plant level) is static regarding the four periods, without taking into account the evolution of the system structure. The specifications of the solutions for changeability lie into the new architecture of reference Arch n+1 (see figure 6.16). It embodies the integrability of the transportation path input and the modularity of the transportation output. Required adaptations at the detailed phase must then be performed to enable changeability at the operational level.

Assembly line redesign and design for changeability

Assembly operations of seat cushion frames are performed at the assembly lines. The input flow comes from intermediate shop-stock where unfinished cushion frames are stored, others raw components are stored in the assembly line store. The assembly lines are in charge of three main operations (see figure 6.17): Pump screw fastening (operation 1), Lock-bolt operation of racks (operation 2) and Torsion bar assembly (operation 3). Design for flexibility A short-term flexibility strategy is designed for dealing with three cushion reference variants. For each of them the carrier lifting system ensures the Z position of the cushion according to the lockbolts positions. Another flexibility strategy enables both manual an automated modes. In addition, the robot is required be independently reusable from its tool which requires an open margin strategy for the interface between the robot and its tool.

Cushion support

The moving carrier through the assembly line supports different variants of cushion. For that, it has dedicated and exchangeable jigs for each of the three variants. The change-overability is improved with the lack of screws to fix (see figure 6.21). Driven by the needs arising from the new conceptual solution (see figure 6.31), the configuration has been detailed through a MBSE scheme. It was primarily used for documenting the design rationale through SysML models and domain-dependent models (e.g. discrete event simulation software, robotic cell simulation). It helped to guarantee the consistency of the design process among the different stakeholders and actors from different disciplines (i.e. manufacturing process expert, robotic engineers, automation engineer, integrators suppliers, logistic experts, automated guided vehicles suppliers, traceability expert, and ergonomic expert).

Product Family

The design process was iterative between analysis and synthesis activities, and progressive from the systemlevel to lower levels, consistently with the formalism presented in chapter 4. All the tackled viewpoints are summarized in figure 6.32; they are successively developed in the following paragraphs. entities interacting with the system: actor entities able to drive the system (operator in mass stock, cell manager, information system (IS), integrator, maintenance operator) and passive entities (raw components, final sub-assemblies, floor space, trolleys, energy supply system). The SoI includes the press cell, the input transportation system from mass stock, and the output transportation system to assembly lines.

External system behaviour analysis Once the problem context and the system boundary are identified, the design problem is analysed through SysML behavioural diagrams (sequence diagram, state machine diagram, use-case diagram, activity diagram). User modes are identified, namely the different situations the system will be facing with and for which a specific behaviour is expected (i.e. integration/major change phase, ramp-up phase, operational phase and maintenance/repair failures phase in appendix A.2.1). For each of these modes, requirements about interactions with the contextual elements are detailed in a sequence diagram (see appendix A.2.2). Their expected behaviors are then specified in state machine diagrams, and each state ("init", "production", "change-over") is developed in activity diagrams (see appendix A.2.3).

System requirements analysis All along behavioural analysis, behavioural, functional or structural requirements are retrieved from models. Requirements can either be read in models or directly formulated from the comprehension of stakeholders and designers. As illustrated in table 6.4, they can belong to various categories (e.g. physical constraints, functionalities, security, integrability with existing resources, product quality, cost, performance) and come from various sources (e.g. business rules, strategy, quality rules, other sub-systems etc.).

System structural elements identification Because requirements are rarely solution-neutral and may instead refer to structural elements, the design process model is iterative between design analysis and synthesis activities. Rationale links are successively traced between requirements and structural elements in the rationale-based architecture. In the previous examples, some solutions were either already existent or co-specified along with behavioural diagrams (e.g. robots, press and mechanisms, micro-engraving, cell and system control in appendix A.2.3). The concurrent identification of structural elements satisfying functional requirements in the synthesis stage is presented in table 6.5. During architectural design, the arrangement of structural blocks can be specified in a digital mock-up of the system (see figure 6.33). Structural elements are also organized in a hierarchical block diagram according to their levels and types in the system (see figure A.3). Green blocks represent hardware modules, pink ones are software modules, and orange ones are hybrid modules. Operational Performance

Functionalities

The system must have one pilot which will be the master for all the machines Internal system behavior analysis In addition to the requirements elicited at the system level, the required functionalities and exchanged flows within each of the the sub-systems are described in a swim-lane diagram in appendix A.4.1. The system's behaviour is simulated using the discrete-event simulation software Flexsim R . Concepts are validated with performance indicators, and then communicated to the various stakeholders, business managers and suppliers. Two configurations are tested. The first one is composed of one mass stock (or shop stock), one SoI (press cell and transportation system), and two assembly lines (see figure 6.34a). The second one is scaled up with one mass stock, two SoI, and four assembly lines (see figure 6.34b). Along with that, behaviours for each of the logical sub-systems modules (i.e. cell control, press cell, input axis, output axis, transportation control, input transportation control, output transportation control, AGVs) are detailed into activity diagrams (see appendix A.4.2). Let us note that requirements can be used as specifications for the development of structural elements (e.g. modes and states specify the system control).

Press cell sub-systems behaviour analysis Behavioral requirements regarding the sequence of operations are represented within the activity diagram in appendix A.5, and then validated in FlexSim R models. It raises the issue of the robot being the bottleneck of the system, inducing a lot of waiting time for the press. The detailed dimensions about the number of robots and the type of operations are still questioned at the end of Conf n without finding an agreement with the supplier.

Functional Requirements Satisfying element Raw parts shall be transported from mass stock to press cell Input transportation system {AGVs, Input trolley, Guiding wire, RFID sensors} final assemblies shall be transported from press cell to assembly lines Output transportation system {AGVs, Output trolley, Guiding wire, RFID sensors} Full input trolleys shall move from a waiting place to the press cell input place. Once empty, they shall move to an other waiting place during the cycle time Input Axis Empty output trolleys shall move from a waiting place to the press cell output place. Once filled, they shall move to an other waiting place during the cycle time Output Axis Sub-assemblies shall be marked for traceability control Micro-engraving machine Raw parts shall be loaded inside the press

Loading system Sub-assemblies shall be loaded from the microengraving machine to the output trolley

Unloading system

Expanding operations shall be performed on tubes and side members

Press expanding

Loading operation shall be performed from the input trolley to the loading system, and from the press to the micro-engraving machine Robot Operators shall fill the input trolleys in the mass stock Operator in mass stock An internal store shall be planned for the defective parts Rack for defects Table 6.5: Functional requirements and satisfying structural elements Axis behaviour analysis Nominal scenarios are established for input and output axis: when the press cell process is finished, the input axis moves the input trolley from "cell process place A" to "cell unloading place A"; and when the "cell process place A" is empty and the press cell is waiting, the input axis moves the input trolley from the "cell loading place A" to the "cell process place A". In parallel, the same behaviour is specified for output axis with respectively the "cell process place B", "cell loading place B" and "cell unloading place B".

Press cell layout synthesis Following the decisions about the press cell's elements (i.e. robot, press, micro-engraving, trolleys, axis, loading and unloading systems) the layout of the cell is synthesized by the supplier N (see appendix A.6).

AGVs behavioural requirement from press cell AGVs design is part of the system design process (see figure 6.31). AGVs are automated vehicles in charge of transporting the input trolleys (upstream the press cell) and output trolleys (downstream the press cell) using markers in the environment (RFID sensors and the guiding wire). From system-level requirements and adjacent sub-system requirements (i.e. trolley design, input and output axis design), behavioural requirements and structural requirements for AGVs are elicited at the sub-system level. Interactions between the transportation control, the global logical system and AGVs are represented in appendix A.7.1. The internal behavior requirements for AGVs modes and buffer management are represented in appendix A.7.2. The operating mode of the transportation control module is detailed in appendix A.7.3. The detailed-design stage has been performed within the context of another industrial-academic project aiming at designing generic and reconfigurable transportation systems.

Transportation system layout synthesis System requirements derive in the specifications of the different stop areas that shall be identified by RFID chips. Two circuits with two distinct guiding wire are decided (figure 6.39). given environment (i.e. connected elements in its neighborhood) and impacting an interfaced output element on which change is propagated. Each case contains knowledge about a solved change propagation pattern.

The "change propagation pattern class" includes (see figure 7.2 and figure 7.3): an input element, an output element, an interface between them, a change direction, a received change driver applied to the input element and a delivered change driver applied to the output element.

Additional knowledge

The change propagation pattern definition can be enriched with other ontologies developed in the area of change propagation and management. For instance, [START_REF] Giffin | Change Propagation Analysis in Complex Technical Systems[END_REF] formalize change motifs in change networks and the definition of indices to quantify area in terms of its propensity for accepting, reflecting or propagating change. In order to fully develop the CBR, similarity measurement and adaptation knowledge should also be defined. Last but not least, knowledge engineering approaches [START_REF] Bernard | Methods and Tools for Effective Knowledge Life-Cycle-Management[END_REF] should drive the integration of the ontology of manufacturing systems, changeable solutions and other expert knowledge.

Collaborative design environment -Multi Agent System

The core methodology for systemic design proposed in this manuscript encompasses various aspects. A collaborative design environment should hence reflect the variety of required viewpoints.

Motivations for the MAS paradigm

The MAS derives from distributed AI, in which autonomous entities, called agents, support the decentralized and parallel execution of activities. Imitating human interaction situations, a complex problem is divided into several smaller ones with specific goals and skill knowledge. Interacting agents are thus able to solve the problem together when it is impossible only by themselves. Agents are intelligent objects since they are able to interact thanks to communication interfaces and to resolve problems according to their partial and embedded resolution capabilities. Collaborative processes and conflict resolutions emerge from these intelligent architectures. Because they are distributed, modular and scalable, these architectures can also be rapidly adapted to new requirements. A broad range of applications has been studied. Based on survey papers in the manufacturing system domain [START_REF] Wang | Agent-based Intelligent Control System Design For Real-time Distributed Manufacturing Environments[END_REF]] [Monostori et al., 2006] [Shen et al., 2006] [Leitão, 2009], MAS are widely applied to enterprise organization and integration, manufacturing shop-floor control and scheduling, production planning and process planning. Only a few research works attempt to apply MAS to concurrent engineering design and manufacturing [Sprumont andMuller, 1997] [Shen et al., 2003].

A collaborative design environment [START_REF] Lu | A scientific foundation of collaborative engineering[END_REF] classify collaborative engineering problems according to whether knowledge is deterministic and independent of human preferences, or is socially constructed and derived from human perspectives and interactions. The framework of a semi-automated collaborative design tool is here specified. This proposition goes beyond the segmentation between technologyoriented approaches and social science-oriented approaches, and subscribes to socio-technical-oriented approaches such as ECN (Engineering Collaboration via Negotiation) [START_REF] Lu | A scientific foundation of collaborative engineering[END_REF]. As design is a distributed and asynchronous problem, the collaborative design environment is organized as a blackboard architecture. The main blackboard is a data repository for information about changeability capabilities, namely the architecture of reference. It is related to a second blackboard that includes knowledge about the current configuration under design. Surrounding them, knowledge sources (KSs), namely the three macro-agents, are allowed to communicate and interact with the blackboards while they operate. Changeability in engineering design has to be considered from two complementary viewpoints: design for changeability (i.e. the creation of modules and corresponding interfaces) and reuse changeability capabilities (i.e. taking advantage of the developed and invested modules and interfaces). To establish changeability as a lifecycle system property, it has also to be concurrent and even collaborative with the design project of the system. The design environment in Figure 7.6 involves these three concurrent processes, represented as three macro-agents (MA1, MA2, MA3) collaborating together. A second level of collaboration takes place between the agents within the macro-agent. Each agent refers to a viewpoint having been described in the methodology proposition in chapter 5. This collaborative design environment could be enlarged with activities specific to the manufacturing system domain.

Appendices