Integrated Model for Co-Development of Products and Production ...

Integrated Model for Co-Development of Products and Production Systems – A Systems Theory Approach Stellan Gedell, Marcel T. Michaelis and Hans Johannesson Department of Product and Production Development, Chalmers University of Technology, SE – 41296 Gothenburg, Sweden Abstract: The seamless co-development of products and production systems is still an unresolved challenge. Undoubtedly, progress has been made through the proposal and application of new methodologies in the collective of Concurrent Engineering. Still, there is a gap between modeling approaches in Product Development and in Production System Design. This gap is an obstacle especially if many interdependencies exist among the constituents of products and production systems. This paper aims at closing this gap by modeling these constituents in an integrated model. This model represents the product and the production plant as co-equal systems with sub-systems, interactions, and behavior. It allows modeling every sub-system in all its lifecycle phases together with the rationale behind its design. A class model is refined for purpose of laying a structured basis for modeling that can be implemented in computer-based support. A real life example from the automotive industry illustrates the application of an integrated model and highlights its benefits for co-development. Key Words: concurrent engineering, integrated product development, configurable component, platform-based design, systems design.

1. Introduction For the success of products that are to be produced and sold, it is not enough to design these products. It is just as essential to ensure production processes that are able to materialize the design. In the same way that a product can be created from scratch or result from a modification, the production process can be created from scratch or result from a modification. Generally, it is more common to base new products and new processes on existing ones. For instance, a new car model is seldom developed without looking at its predecessor and the production system and processes in place. The same is the case for new machine tools, computers, and mobile phones. When manufacturing products, one approach is to create a product design and then pass it over to production. In other words, a standard production facility is presumed, and the product design is limited by this standard. Another case is to take for granted that the capabilities of the production system can always be expanded in order to produce the given design. In both cases, the product designer is relieved from considering production. In today’s highly competitive market, with optimized products and highly adapted production, these are unlikely scenarios. Instead, the product designer wants to exploit the production facility’s capabilities in order to both achieve specific product properties and to ensure predicable cost, quality, and producability, for example. Conversely, both production opportunities and production risks identified by the production system designer should be considered by the product designer, potentially leading to modifications of the product design. These objectives are closely connected to the dependencies between product design and production system design. In this paper we adopt a Systems Theory [1] approach to illustrating and managing these dependencies. Generally, Systems Theory offers a variety of principles that help describe and explain complex phenomena where a single constituent cannot be understood without considering its context. Here, we focus on the principles of behavior, interface, interaction, and composition.

A1

A more specific approach to managing the dependencies of products and production systems over time is to develop products and ranges of products within a more or less rigid framework. Companies that implement this idea often take a platform-based approach to designing. In it, the platform is “the collection of assets that are shared by a set of products” [2] and production systems, including components, processes, knowledge, as well as people and relationships. Adopting a long-sighted approach to developing products and production system can increase the reuse of components, processes, knowledge and resources as one step towards sustainable production. While Systems Theory sets the general scene of this paper, the research presented here is, more specifically, based on the Configurable Component (CC) framework [3-7]. The CC framework is a modeling approach devised to support the development of complex designs in general and platform-based designs in particular. The aim of this research is to further elaborate within this framework how to support the co-development of products and production systems. The successful management of the dependencies between products and production systems is also a goal of Concurrent Engineering (CE). In other words, CE aims at successful codevelopment of these two. They undergo a co-evolution [8] if this co-development is carried out continually over time and if new products and production systems are based on existing ones. Co-evolution is not limited to products and production systems. For example, a product and its development process can co-evolve [9] and benefit from the integration of models that describe these two. Various methods of general CE support have been presented. Examples of such methods are organizational setups that reduce barriers between different parts of the organization and the introduction of engineering processes that facilitate cross-functional co-evaluation [10]. While CE includes a comprehensive collection of methodologies, this paper contributes with a specific aspect in this collection, namely in information modeling. More specifically, it presents an integrated model for the co-development of products and production systems. A class model is refined for this purpose [11]. A class model is a template that defines which modeling elements are available and how they may relate to each other. Based on this template (consisting of the classes) instances can be created, so called objects. These objects represent a design and together they form an object model. All models that are illustrated in this paper describing designs are object models. Class and object models are used in software engineering and, more specifically, in so called object-oriented programming. The Unified Modeling Language (UML) [11], for example, is an object modeling and specification language used in software engineering. UML provides multiple means for representation of a (software) design, so-called diagrams. These diagrams include a class diagram (i.e. a class model) and object diagram (i.e. an object model). A specific UML model is presented in Chapter 6 defining the relationships between elements essential for the composition of systems. The object-oriented approach, with for examples classes and objects, has its origin in software engineering. The Configurable Component framework in general and this research in particular seek to apply this approach outside its original domain, namely in the area of designing and producing physical products. Wu et al. [12] present a similar object-oriented approach with a different focus, namely linking the mechanical, electronic, and software domains. The CC framework consists of a number of ways to represent a design. It is intended as a useful toolbox available for the designer for building models of products and production A2

systems. These can then be utilized e.g. to optimize design and processes. Although process optimization is not the focus in this paper, it has been demonstrated that a model aligning products and manufacturing enables optimization of the manufacturing process [13]. Modeling the two systems with their dependencies can result in a vast amount of information. Therefore, the research effort is ultimately directed towards a computer-based version of the toolbox, which can facilitate managing the dependencies and thus support CE. The existing CC framework together with the class model elaborated in this paper lay the foundation for such computer-based support. Product models and production system models address different domains within industrial organizations and, thus, do not share a common heritage. As a consequence, they are built around different terminologies and focus on different objects. Still, those models relate to each other. The relationships must be explicitly described to attain an integrated product and production system model. For this purpose, the models’ respective terminologies must be understood. More specifically, they must be understood in such a way that every construct in one domain can be mapped to a construct in the other domain. Examples of this gap in terminology are that product development uses the constructs system and function, while production uses process, operation, tool, and cell. Besides bridging this gap in terminology, it is necessary to model both designs in such a way that relationships between elements can be expressed even if they belong to different domains. 2. Research Approach 2.1

Research Question

Essentially, this paper aims at modeling interacting systems (in other words, systems that affect each other). Particularly, the interacting systems product and production system are put into focus. With the goal of representing them in an integrated model, the following research question was formulated: How should the dependencies between the product and the production system be represented in an integrated model, within the Configurable Component framework, to support co-development of complex and platform-based designs? In the present definition of the Configurable Component framework, which is distributed across several publications [3-7], some of its elements are rather well elaborated. The embedded function-means model and the composition mechanism (as further explained in Section 3.2) are two examples. In the area of representing dependencies between interacting systems suitable modeling methods are not in place and are explored here. 2.2

Research Methodology

The presented research is based on a research model of co-evolvement of theory and empiricism similar to the one illustrated in Figure 1, adopted from Jørgensen [14]. As shown in Figure 1, the model focuses on how theory and empirical observation relate to each other in applied research. Its two starting points illustrate both the parallel activities and the interaction between these activities. In the presented work, the problem base is represented by the issues evolving in the codevelopment of complex and platform-based designs. The theory base is laid by Systems A3

Theory in general and, more specifically, by the Configurable Component framework. The work presented in this paper includes a real-life industrial example from Saab Automobile AB. Analyzing this concrete example of dependencies among product design, production system design, and processes provided the insights to synthesize a model of the systems from the example and to complement the definition of the Configurable Component, through refining its class model. Data sources for the real-life example included the physical product and the production facility, product and production documentation, and informal interviews with engineers from the engineering design department and from production. 2.3

Studying a Real-Life Industrial Example

An arbitrarily selected spot-welding station in the body-in-white plant of Saab Automobile AB’s site in Trollhättan, Sweden was chosen as a production system to study. Consequently, the product produced there, a sheet-metal assembly, was chosen as a product to study. The production unit in the body-in-white plant is a robotized welding facility with manual loading and unloading. The product is a part of the body-in-white structure of the car. With respect to the product, the research retrospectively studied aspects from various product lifecycle phases and how these had affected the design of the product. With respect to the production unit, its basic structure and how it had come into being were not studied. However, the designing of a welding tool and the fixture in direct contact with the product were included in the study of the example. Problem base

Theory base

SYNTHESIS

RESEARCH

ANALYSIS

Building structures, internal consistencies, etc.

Disclosing structures, causalities, empirical rules, etc.

Diagnosis

Model

SYNTHESIS

ANALYSIS

Generating solutions, evaluating consequences, selection

Validity, external consistencies, usefulness, etc.

DEVELOPMENT

New scientific insights

New scientific insights

KNOWLEDGE TRANSFER: Adaptation of methods, implementation, etc.

Practical results

Figure 1. Basic work paradigms for research and development activities, translated and adapted from Jørgensen [14].

A4

3. Frame of Reference This Chapter introduces the two main elements in the theory base of this paper, Systems Theory in general and the Configurable Component framework, which has a focus on applied modeling of systems. 3.1

Systems Theory

Systems Theory is a theory designed to study unified whole systems. It has some key features: its ability to represent anything of interest, so-called systems, and the fact that each system is a whole that is more than the sum of its parts. While many definitions of the term system exist, this paper accedes to Sommerville’s [15] definition: "A system is a purposeful collection of interrelated components that work together to achieve some objective". Purposefulness here includes a user defining a system based on his or her need. This, in turn, may lead to multiple users defining systems with overlapping content. Drawing purposefulness into the picture has another consequence: not every nitty-gritty part will be seen as a system by default because defining it as a separate system may lack purpose. The adopted definition does not limit systems to be artifacts. For instance, living organisms and their organs can be seen as systems. This is exemplified later in this paper where humans and groups of humans are seen as systems. Hitchins [16] puts into words how the whole can be more than the sum of its parts: “A system is an open set of complementary, interacting parts with properties, capabilities, and behaviors emerging both from the parts and from their interactions”. The contribution from the system’s interaction with its surroundings (in other words, other surrounding systems) is vital. Systems that interact, so called open systems, will interchange matter, energy and information with other systems. Roozenburg and Eekels [17] describe how a system continuously transforms from its current state to another state in an infinite series (which may be cyclical). The resulting state from such transformation depends on the current state and the inputs the system receives through interaction. More specifically speaking, the behavior of a system depends on its sub-systems and how they interact, as well as how the system interacts with other systems. Its properties are properties of the system as a whole. These emergent properties [18] cannot be attributed to a specific part of the system. Rather, they emerge when the system is considered as a whole. Examples of emergent properties are: the overall mass of the system, the reliability of the system, and the usability of a system. The overall mass of the system is an example of an emergent property that can be computed from individual component properties. The reliability of the system depends on the reliability of the components and the relationships between the components. Finally, the usability of the system involves not only the system itself, but also the users of the system. While basic ideas of Systems Theory thinking trace back to the ancient world, it was defined in a modern sense throughout the last century [1, 19, 20]. With the theory’s aim to handle functions and relationships within biology, it was meant as a complement to reductionism. Reductionism’s closed system approach, breaking things apart and studying them separately

A5

Physio-chemical form

Intensive properties

Geometrical form

Extensive properties

Function

Needs

Values

Mode and conditions of use

Figure 2. Functions emerge as a combination of the design and its mode and conditions of use [17].

to formulate laws and principles of behavior, had been quite successful. However, it had shortcomings, especially when dealing with complex biological systems. For example, studies of an individual termite cannot explain how millions of them together build nests, meters high. Similar shortcomings can be found when describing the behavior of complex artifacts (vehicles, production facilities, traffic systems, and design departments, for example) and how all these will influence each other when they interact. This identified need within the automotive industry is the driver for an integrated product and production process model. Roozenburg and Eekels [17], while discussing Product Design, describe how a product’s function is a result of the design itself and the way it is used (see Figure 2). Interpreting Figure 2 based on the Systems Theory approach adopted in this paper the following statements can be made:

Figur!2!

-

A product is an example of a system. (The four blocks in the upper left corner of the figure represent the product.) The mode and conditions of use correspond to the interactions from the product’s environment (in other words, the interacting systems), as well as to its internal state. The product’s functions can be seen as a subset of its behavior.

Here, when trying to understand a system’s behavior and its dependencies with other systems, the system’s interactions and its internal states need to be understood. In this paper, this notion will be used as an approach for refining the class model to make it capable of representing an integrated product and production system model. 3.2

The Configurable Component

The CC framework is a means of representing systems and their incorporated subsystems based on the generic building block, the Configurable Component [4]. The concept has its origin in the attempt to describe variant-rich and complex products and therewith, more generally, entire product platforms [3]. It makes use of several basic principles and constructs, explained below: One CC represents a system. That system can be elaborated and represented by a set of subsystems. This means that the initial system is composed using a number of subsystems, which can be composed of others and so on until the required level of granularity is reached. Note that composed of is not synonymous with consists of. In other words, the mechanism of composition describes more generally the resources (sub-systems) the super-system needs to form itself.

A6

Accuracy, etc.

Interfaces

Internal structure

Figure 3. A watch used to exemplify visible and hidden design solutions.

By default, the internal structure of a system is encapsulated (i.e., its content is hidden). However, the selected content of interest inside a CC can be made visible for other systems. Two typical examples can be given here. First, making internal content visible can be done for purposes of representing the possible and factual interactions between systems. Second, it allows for elaboration and composition. Its internal structure hidden, basically inaccessible for others, the CC achieves a certain level of autonomy. The watch (see Figure 3) is an example where some performance data (accuracy) as well as interfaces (mechanical, like crown and watchband connection, and optical, like hands) are made visible, and where the design solutions that form the internal structure (mechanical or electronic movement) are hidden behind the clock face. The elements within a CC that describe the design are Design Solutions. A design solution is the result of a design decision and can represent anything from an overall concept to the smallest detail. Interfaces, for example, are one specific form of design solutions. A CC can represent a number of variants. Parameter values are used to describe available or feasible variants of a system as a whole or of individual design solutions within the systems. For example, a rear-view mirror can have a parameter on its system level defining on which side of a car it is intended to mount the mirror. The curvature of the glass can be an example of a design solution parameter for a rear-view mirror. The reasoning behind selected design solutions, the so-called Design Rationale, is incorporated in the Configurable Component adopting the Function-Means formalism in the shape of a Function-Means tree [21]. Thus, the design rationale is directly connected to the level of detail relevant for a particular system. A function-means tree consists of three groups of information, namely requirements, solutions and how these are related to each other. Requirements can be either Functional Requirements (FR) or Design Constraints (DC). Solutions are represented by Design Solutions (DS). The function-means formalism gradually refines both functional requirements and solutions. A FR is solved by a DS, which may require a function (expressed as FR), which is solved by a DS and so on. The function-means tree is modified to form an embedded function means model [7] in order to act as an integrated part of a configurable component, rather than a stand-alone model. The rules for modeling are made less strict, and constraint handling is made more transparent and explicit. The design rationale is not limited to reasoning and design solutions within the CC. For example, it can also include assumptions about which external design solutions could affect the design represented by the CC. The development of the CC concept has identified a number of internal elements and constructs that are required for comprehensiveness. However, only the ones explained above have been explored thoroughly. Internal elements of the CC that need further exploration A7

include: Interfaces, Interactions, State Models, Part Definitions, Performance Models, and Features. This paper focuses on interfaces, interactions and state models as means in an integrated model while omitting the further development of the other constructs to limit the research work. 4

Towards an Integrated Model representing Interacting Systems

This chapter provides the theoretical considerations that lead from Systems Theory and the CC framework to the class model. For the sake of simplicity, a coffee machine is used whenever possible to illustrate and to exemplify. 4.1

Different Modeling Approaches and Their Implications

Modeling means describing some selected aspects of reality. It is often done to facilitate the activity of designing. Depending on what specifically is to be facilitated, different aspects of reality are chosen. Thus, the way modeling is conducted and the resulting models themselves may differ. This section discusses the implications of two particular modeling principles and motivates the selection of one of them as basis of the integrated model sought in this paper. Based on the intention of supporting the development of complex and platform-based designs, we prioritize a model that is capable of representing the design throughout its complete lifecycle. More specifically, for this purpose, we see it as essential to include in the model an object that represents the design in all lifecycle phases. The introduction of an all-lifecycle object will have an effect on how to model, for example, the production and disassembly processes for a coffee machine. In Figure 4, three major lifecycle states are shown: the designing of a coffee machine, the production of a coffee machine, and the use of a coffee machine to make coffee. In all of these states, the coffee machine interacts with other systems; in the first case, with the design engineers, in the second case, with the manufacturing plant, and in the third case, with the coffee, the water, and so on. A system will have even more states throughout its lifecycle. Apart from the major states from Figure 4, states on a more detailed scale are also conceivable. Examples could include partly designed, design complete, partly assembled, completely manufactured, in use, worn out, and recycled. The level of detail can easily be increased if it suits the purpose of the model. Above, the need to represent the design during its complete lifecycle has been addressed. In the following, two different modeling approaches are explored along with their ability to support this need. Coffee Machine

Product Development Socio-technical System

Production System

Electric. grid, Water, Coffee, Ground Coffee, etc.

Designing

Production

Use

Figure 4. Example of a product’s major lifecycle phases and potential interacting systems.

A8

Modeling According to Hubka and Eder The two modeling approaches, illustrated in Figures 5 and 6 respectively, represent the production system in alternative ways. Apart from this difference, the same production stations, parts (heater and frame) and assembly (coffee machine) can be found represented in either figure. In both figures, arrows can mean a transfer of material, energy and information. Ultimately, both figures represent the same reality, yet with different focuses. In Figure 5, the parts will flow through the various stations, in which they will be modified according to the respective station’s transformation process. For instance, in Station A, a piece of metal (input) is transformed into a frame (output). In Station C, the same frame and additional parts are transformed to yield the coffee machine by means of an assembly process. This assembly process, a transformation process, interacts with the execution system. This modeling approach is presented in the Theory of Technical Systems introduced by Hubka and Eder [22]. One implication of this modeling approach is that the resulting model closely represents the stations and the flow of parts between them. However, while this model visualizes the production flow, it provides limited support for analyzing the flowing parts in all their lifecycle phases and their dependencies with other systems in the final product. Station C (assembly) Execution system Station A (casting)

∑ Effects Frame Heater Etc.

Transformation Process

Coffee machine

Station D (wrapping)

Station B (assembly)

Figure 5. Modeling of a production system according to the Theory of Technical Systems [22].

Station B (assembly)

Frame

Heater

Coffee machine

Figur 5 Station A (casting)

Station C (assembly)

Station D (wrapping)

Figure 6. Modeling of a production system using a Systems Theory approach according to, among others, Hitchins [16].

A9

Modeling According to Hitchins The modeling approach in Figure 6 represents the same production system in a different manner. Instead of parts flowing in and out, being transformed by the production system, the second approach applies Systems Theory according to, among others, Hitchins [16]. More specifically, this means that systems exclusively interact with other systems. Station C will interact with the frame system, the heater system, and the coffee machine system. This is visualized with bi-directional arrows that indicate that an interaction between systems exists, rather than the flow of parts. In other words, the systems affect each other. Rather than modeling material as flowing between systems, material here is given another place in the model, namely as an interacting system of its own. This means that modeling as proposed here allows this material (often a part) to be examined and modeled more closely. In the example of the coffee machine this means, water flowing through the physical space of the machine is not considered a part of the system coffee machine. Instead, it is another system interacting with the machine that can be examined. In summary, this approach, as presented in Figure 6, models products and production systems as co-equal objects. As a consequence, it also can be applied for the two other major lifecycles phases described in Figure 4, designing and use. During the designing of the coffee machine, the socio-technical system (the design department) interacts with the design (3-D representations, calculation models, etc.), successively changing the design from just initiated to complete. When the coffee machine is in use, it will interact with other systems, like the user, ground coffee, and the electrical grid. Selecting a Suitable Modeling Approach Ultimately, there are two main differences between the two modeling approaches. The first difference is how interactions are defined and how transformations are modeled. The second main difference is that products and production systems are co-equal in the second modeling approach (Figure 6). Transformation as a principle is generally seen as a useful notion to model change in systems. In this aspect we take the first modeling approach as a source of inspiration. Yet, for the further development of the model in this paper the modeling approach should not hinder representing every system in all its lifecycle phases. Moreover, co-equal objects for products and production systems are a basis for establishing an integrated model. Looking at these two differences, we deem the second modeling approach more suitable as a basis for the integrated model. It is therefore adopted to further develop the integrated model in the following sections. 4.2

Interaction and Interface

The previous chapters include references to the terms interaction and interface without discussing them in detail. This section elaborates on these two constructs and discusses their content and place within the class model.

A10

System A Composition E

System B I/F H

Interaction F

G

System C I/F I

Figure 7. The modeling elements forming a composition.

This paper has the ambition to avoid prescribing engineering processes as much as possible. However, in order to develop a class model that ultimately supports the process of designing, one needs to make some assumptions about the related engineering processes. The first assumption is that when designing a system, it may be composed of sub-systems and those sub-systems interact according to the designer’s intentions. In other words, one adopts a top-down approach, where the designer of a system both selects the sub-systems that compose the system and defines how they are to interact. The second assumption is that it is desirable that a system can be used in different products. While there are many reasons to motivate this, one of the prominent ones is economy of scale. From a modeling perspective, this means a system is brought from one context to another. For this to work properly, the system cannot bring the references from its first context to the second one. In other words, a design needs to be described autonomously, and modeling the dependencies in a direct and rigid way is unsuitable. Composing Systems Using Autonomous Sub-Systems

Figur 7

The first assumption above results in the need to further discuss and develop the mechanism of composition, the interactions between sub-system’s interfaces, and the production processes that join materialized sub-systems. The mechanism of composition is elaborated upon in previous publications concerning the Configurable Component (Claesson [4] and Gedell [3], for example). Interaction and interface are elaborated in this chapter. Figure 7 will be used to elaborate the constructs composition, interaction, and interface. The figure includes some basic elements: -

A represents a system. B and C represent systems, and are, in the given setup, used as sub-systems composing A. E, F and G contain information about the composition and interaction of the two subsystems.

If a functional requirement is to be solved using two sub-systems, different pieces of information need to be identified: which sub-systems these are, how they are to interact, and (if the sub-systems are physical parts) how they are to be assembled. These pieces of information are distributed as follows:

A11

-

-

Composition E contains information regarding which1 sub-systems together will compose system A. This information can be used to build a hierarchically structured model of the design. Interaction F contains information about which of the sub-systems’ interfaces interact and how these interfaces are to interact to compose System A. The description of how the interfaces are to interact includes information about the designs of the respective interfaces and, for example, interaction diagrams to describe dynamic behavior. If the system is to be materialized, G contains information about which production system is to be used. Interfaces H and I (in Systems B and C, respectively) contain information about how the interfaces are designed

To emphasize, the designer of a system autonomously selects which sub-systems to use and how these are to interact2. Consequently, this is described in the system. G is to be elaborated upon further, which is indicated by the dashed lines. To be more specific, G is to be replaced with a composition and interactions. Note that Figure 7 only gives a schematic overview of the information related to a composition and does not fully reflect the internal structure of the Configurable Component. Maintaining Autonomy in an Integrated Model The second assumption above deals with the need to develop and maintain a system without limiting it to being used by one super-system only (i.e., in one context). The principle of encapsulation ensures this by preventing references to the system’s interior. However, this alone does not suffice. The systems’ interfaces are visible to the surrounding systems and may be used unwisely to build relationships between systems in a way that results in their autonomy being lost. Returning to Figure 7, for example, Sub-system B has no relationships of its own (in other words, relationships pointing away from it). It is thereby autonomous. However, no information exists about which requirement to meet to become a useful system. In order to be able to design a system that will work as a sub-system in other super-systems, the requirements on the system need to be identified and represented. It can be assumed that numerous processes exist to find out which requirements a sub-system needs to meet. This, however, is outside the scope of this paper. Still, this information needs to be structured. When the possibility to handle contexts by directly referring to other systems is prohibited, another approach is necessary. The remedy proposed in this paper is that each sub-system within itself describes which surrounding systems it is designed to work with, as part of its requirements. In Figure 8, it is shown how System C represents requirements on how it can interact. It does so by describing its intended surroundings (i.e., its possible interaction with the Interface H’ of System B’). In other words, the expected surroundings of a system are represented inside this system (in this case by System B’). This is done to support designing the system in a way so that it will deliver the expected behavior when used in any of its intended super-systems. Naturally, that neither limits how it may be used nor guarantees that it will work in the surroundings into which it is placed. 1

Besides information about which element to use, information about which variant of this element to chose is also included here (if variants of B or C exist). 2 If the selected sub-system does not exist or meet the expectations, the design will not work. That, however, is another question not elaborated upon here.

A12

System C Interaction F’ I/F I

System B’ I/F H’

Figure 8. Modeling of system’s surroundings inside the system itself.

Note that F in Figure 7 and F’ in Figure 8, as well as B and H in Figure 7 and B’ and H’ in Figure 8, are two independent sets of information that can be equal, equivalent, partly equivalent, or completely different. Of course, if they differ, it is most likely not a good choice to let the system be composed using these particular sub-systems. To emphasize, the intention is to represent one and the same object in multiple versions (for example, the Interaction F in Figure 7 and F’ in Figure 8). This allows the class model to manage incomplete and inconsistent information, thus ensuring that diverging opinions and insights are made visible before decisions are made. 4.3

Behavior, States, and Processes

Above, the term behavior is mentioned several times. However, when discussing production systems, other constructs are more prominently used. Examples of these are process and state model. Those two constructs will be elaborated on in this section, based on Systems Theory, connecting it to behavior. As pointed out earlier, two statements can be made about systems [17]: -

A system’s behavior is a result of the system and its interaction with its surroundings and A system continuously transforms from its current state to its next state.

Figur 8

The state into which a system transforms depends on the design of the system, its current state, and the system’s input (a part of the interaction). Systems may be designed to sequentially transform themselves in a controlled manner. A series of transformations is a process. In other words, when something is changing within the system, a process is taking place. Processes can be found more places than production systems, a special case of a product. They can also be found in products in general.

Figure 9 illustrates both the continuous transformation of a system, visualized by the piston’s movement, and discrete states of interest. Theoretically, the engine system has an infinite number of states. However, only a few states are of interest here: exhaust valve closed (S1), inlet valve opened (S2), inlet valve closed (S3), and compression start (S4). The example shows that some of the processes taking place in a continuously transforming system can be expressed by successively changing, discrete states. These states capture the part of the system’s behavior relevant for a particular stakeholder. Put another way, the states capture the processes of interest. State models are a means of representing these states of interest.

A13

S1

S2

S3 S4

Figure 9. A four-stroke engine with its piston in continuous movement and some states of interest (S1: exhaust valves closed, S2: inlet valve opened, S3: inlet valve closed, S4: compression started)

Start

Wish of existence

Engaged in assembly

Partly manufactured

Consumed

Manufacture complete

Has existed

Figure 10. Overview of a part’s lifecycle state model.

State models are a way for a designer to represent the states considered interesting and the transition from one state3 to another. It is intended to be a purposeful, simplified representation of reality, a reality that is continuously transforming. In other words, transformation is what takes place in the system, and transition is part of a model used to represent the system. The basic building blocks of state models are state, transition and transition condition [23]. When the transition condition is met, the system will change from one state to the next one (in other words, a transition will take place). A transition in one system’s state model can generate events that meet the transition condition in other systems’ state models.

Figur 10

To exemplify, a spot welding robot and a part welded by the robot are both represented by state models. When the part is spot welded, each production activity of the robot, modeled by a state in the robot’s state model, will induce a transition in the part’s state model. One example is from “four spot welds completed” to “five spot welds completed” (see even Figure 16). This way of modeling dynamic dependencies between systems is one of the means used in this paper to represent an integrated model. 3

Within the context of state models, the distinction between a design’s infinite number of states versus states of interest is not maintained in this paper. Instead, the term state of interest below is replaced with state.

A14

To further increase the granularity of a part’s states during its manufacture, a wish of existence state is added between the initial state Start and the state Partly manufactured (see Figure 10). With this state, Wish of existence, the dependencies between the products and the production systems can be used to model a pull on the production system. A need for a part will induce a transition from start to the wish of existence state. Correctly modeled, this will generate an output that triggers the production system to first prepare itself to produce the part and then to produce it. Because the production system will consume parts while producing the requested ones, it will signal its need for those parts further backwards in the production chain. A pull in the material flow is modeled, often referred to as Kanban [24]. With this method in place, it is possible to model the ordering flow all the way back to the ore mine, or whatever is considered suitable. Once this pull is propagated all the way back, the physical production flow (going in the opposite direction) can start. In Figure 10, the final state Have existed is used by the IT support systems to be able to keep track of what parts have been produced. In other words, the state is used to maintain the part instance within the computer system even after the part itself has been extinguished.

5. Real-Life Industrial Example Below, a model for the product, Rear Header Roof Panel, and its manufacture in the production unit, Station 160, is presented. First, the product is described, including the interactions with the production system. Second, the production system is described, including the interactions with the product and how these can be arranged in a sequence. Third and finally, an integrated model for both systems is presented. The Rear Header Roof Panel (from here on referred to as the roof panel) is composed using three parts of die-pressed sheet metal: an inner panel, an outer panel, and a gutter (see Figure 11). Moreover, some additional parts, two backdoor hinges with one reinforcement plate and three bolts each, are included in the roof panel. These additional parts are excluded in the presentation of the real-life example for the sake of brevity.

Positioning holes

Foldable tab Welding access holes

Hinge reinforcement

Curvature to seal against trunk lid

Figure 11. The roof panel and some highlighted design solutions. Inner panel (light blue), outer panel (dark blue), gutter (light green), and hinge reinforcement (dark green).

A15

Rear Header Roof Panel Welding Station 160

Inner panel Outer panel

Gutter

Figure 12. Overview of the involved systems at the welding station.

The welding station creates the roof panel while consuming the other parts. The systems involved in this production process that relate to this production system are illustrated in Figure 12. 5.1

Modeling of the Roof Panel

The roof panel is an integrated part of the body-in-white structure, situated at the back-end of the roof where the roof meets the rear door. It fulfills an important load-bearing function during crash and serves as mounting point for the rear door. The structure is covered on the outside by the roof panel and on the inside by the head lining.

Figur 11

A design like the roof panel consists of a vast number of design solutions. The physical part as such can be studied in order to create a list of design solutions. Holes, cutouts and other geometrical features can all be assumed as design solutions. However, when the roof panel is studied in its context (i.e. when it has become part of the car), further design solutions can be identified. One such solution is a curvature that is part of a sealing. The design solutions are to be documented as solutions within a function-means tree and, in this way, contribute to establishing the design rationale. When creating a design the functionmeans approach is to support a successive top-down refinement of functional requirements and solutions. However, with an already existing design like the one from this real-life example, where documentation lacks design rationale, a bottom-up approach is applicable. In the bottom-up approach, the identified design solutions are used as a starting point for questions to the designers, for example: “Why is that cutout there?” Designers’ answers, why a particular design solution exists, are not necessary limited to the context of the particular part itself. Instead, the designers often give multiple explanations for a design solution. That is because the designers see the part and its rationale connected to other systems on various levels. For instance, the roof panel is seen as part of the roof, the body-in-white, and the car. Reflecting this multi-level cognition, the examples of DSs and FRs presented below are not all addressing the same level in the system structure. Following a bottom-up path, they are organized in Tables 1 and 2 as follows: -

The design solution identified through studying the design (Column 4 to the far right). The functional requirement that is met by the design solution in Column 4 (Column 3). The design solution on the first higher level that the design solution in Column 4 contributes to (Column 2). The functional requirement that is met by the design solution in Column 2 (Column 1).

A16

Table 1. Collection of branches in a function-means tree representing some of the roof panel’s interactions and interfaces. FR on higher level

DS on higher level

FR on roof panel and its surroundings, respectively

DS of roof panel and its surroundings, respectively

Brace the bodyin-white from when the parts are put into place until they are welded

Flexible joints on part to be welded

Provide fasteners to be able to flexibly hold parts together

Foldable tabs

Enable access to weld spots

Holes that give the welding electrodes access to designated area for spot weld

Support the parts’ interpositioning in the fixture Establish enclosure of the passenger compartment with the trunk lid

Provide capability for foldable tabs to hold parts together

Every part has holes with which it is positioned to the fixture’s pins Trunk lid closes and seals the rear of the compartment

Ensure access to roof panel for the welding electrodes

Holes Access holes

Ensure that the welding electrodes keep within reserved space

The shape of the welding electrodes 2) The welding electrodes’ path approaching the target

Enable positioning to pins

One circular hole and one slotted hole

Enable positioning using holes

Two positioning pins on fixture

Design the roof panel’s rear end in a way such that it, together with the trunk lid, will leave space for a molding

A shape on the roof panel that aligns with the trunk lid. 2) A flange (for the molding)

Design the trunk lid to fit to the roof panel and the molding

A shape on the trunk lid that aligns with the roof panel

Table 1 elaborates the roof panel, presenting a collection of some of the related FRs and DSs (some are illustrated in Figure 11). The white cells were filled through studying the actual product. Together they form four branches of a function-means tree, with the functional requirement in Column 1 as the starting point. The design solution in Column 2 describes an interaction between the roof panel and other systems. The remaining cells (with a grey background) contain the functional requirements and the design solutions for the interacting system. Interacting systems here can for example be another sheet metal part or the fixture. The table is not intended to be exhaustive. Still, there are requirements derived from both the production lifecycle phase (Rows 1, 2, and 3) and use lifecycle phase (Row 4). The table is an example of how a system within itself can express requirements regarding how it can interact with its surrounding systems as discussed in Section 4.3. As can be seen from the example, the design’s function will only occur when the interaction is established. This is in accordance with the Systems Theory reasoning where a system’s behavior depends on its interactions. Because of this paper’s focus on integrated models, and because this integration is modeled by means of interacting systems, it is worth noting that every design is explicitly part of an interaction. The interactions exist either with other parts of the product or with the production system.

A17

Table 2. Collection of branches in a function-means tree representing some of the production system’s interactions and interfaces. FR on higher level

DS on higher level

FR on fixture and its surroundings, respectively

DS of fixture and its surroundings, respectively

Ensure that no part is missing

Detectors for every part

Provide capability to detect the part

Magnetic sensor

Be detectable by magnetic detectors

Parts made of magnetic material

Enable positioning using holes

Two positioning pins for each part

Enable positioning to pins

One circular hole and one slotted hole per part

Provide capability to deform the parts into nominal shape

Clamps and clamping support

Allow deformation into nominal shape

Elastic parts

Ensure assembly tolerances within limits Ensure the product’s nominal shape

Fixtures to position every part correctly Force the parts into nominal shape

The roof panel and the parts it is made of are all produced and consumed in the same plant. The lifecycle phase of use falls away. As an example, the inner panel’s state model could have the following states: Start, Wish of Existence, Cut out, Die-press step 1 completed, …, Die-press step N-1 completed, Manufacture complete, Engaged in assembly, Consumed and Has existed. The roof panel’s state model could have the following states: Start, Wish of Existence, First spot weld completed, …, Spot weld N-1 completed, Manufacture complete, Engaged in assembly, Consumed and Has existed.

5.2

Modeling of the Welding Station

In brief, the production process in Station 160 can be divided into three phases: manual loading, automated welding, and manual unloading. The operator takes the (sub-)parts, one at the time, and places them in a two-parted fixture (see Figure 13), starts the welding automatic sequence, and unloads the completed roof panel. During the automated phase, clamps are activated on the fixture, and shape weld spots are applied. To finalize the welding, some more strength weld spots are added that are non-accessible while the roof panel is in the fixture. Another robot grabs the roof panel from the fixture and moves it to a fixed spot weld unit where remaining spot welds are made before the panel is delivered to a rack. The station is composed of a large number of design solutions. The robots with their control logic are themselves complex systems, the safety systems are comprehensive, and the fixture with its monitoring system is extensive. Moreover, the production system Station 160 is also comprised of the operator and operating instructions. In this example, the design solutions, that are modeled primarily, are the ones that interact with the roof panel. Examples include the operator’s actions, the fixture’s surfaces in contact with the product, the welding electrodes, and the robot control program. This is in accordance with this paper’s objective to devise an integrated product and production system model that goes as far as it is adequate and useful. A18

Figure 13. The fixture with the sheet metal parts in place: (1) magnetic detectors, (2) positioning pins, (3) clamps and clamping supports

Load inner panel

Grab inner panel

Activate clamps

Position inner panel in fixture

Move weld head to position for first weld spot

Release inner panel

Send current through electrodes

Activate Start button

Deliver the roof panel

Figure 14. A subset of one of the station’s state models.

Studying the welding station in an attempt to identify and understand why design solutions exist in this system is similar to studying the product. Some design solutions are more obvious than others. The purpose of the start button that starts the welding sequence, for instance, is easy to identify. Some physical design solutions are explained in Table 2 in a similar way as is done above for the roof panel (compare Table 1).

Figur 14

Figure 13 is a photomontage of several real pictures (not 3D renderings) of the sheet metal parts in the fixture of Station 160. Using image-processing software, the parts were made semi-transparent or cut in order to show elements of the fixture and the roof beam that are otherwise covered. The table does not include design solutions that form the dynamic behavior. On this level of granularity, state models are more suitable to model processes. These state models elaborate the welding station’s use phase (see example in Figure 14). Other phases are not modeled (for example, the manufacture and disintegration of the welding station itself). A19

The state model also explicitly describes a number of interactions. For example, it describes: 1. 2. 3. 4.

Operator’s hand to inner panel’s surfaces Fixture’s positioning pin to inner panel’s positioning hole Fixture’s clamp support to inner panel’s surface Weld spot electrode to inner panel’s surface

From the list, some interactions will evoke a need to harmonize the product design with the design of the station. This is the case, for example, for the design of the positioning hole (cf. Interaction 2) and the accessibility for the weld electrodes to weld the spot welds (cf. Interaction 4). 5.3

Modeling of Roof Panel and Welding Station in an Integrated Model

In the models presented in the sections above, a number of interactions have been identified in between the product and the production system. Together, these models can form an integrated model (see Figure 15). For the sake of clarity, the figure includes only a few of the design solutions given above. The separate state models can also form an integrated model. A state in one state model can generate an event that will meet a transition condition in another state model (see Figure 16). Operator

Roof Panel

Fixture

Surface

IA: Align using pin and hole

Pin

IA: Unload roof panel

Inner Panel Hand

IA: Load inner panel

IA: Align using pin and hole

Hole Hole

Pin Surface

Clamp support

IA: Shape the pre-assembly to correct shape

Figure 15. Integrated model, focus on interface and interaction. Inner Panel SM

Station 160 SM

Roof Panel SM

Wait for order Start

Manufacture complete

Grab inner panel Wish of existence Position inner panel in fixture

Engaged in assembly Activate Start button

Figur 15 Partly manufactured

Consumed Send current through electrodes

Figure 16. Integrated model, focus on interacting state models.

A20

Figur 16

In the previous figures (Figures 15 and 16), design solutions of the types interface, interaction and state model are illustrated. These design solutions contribute to form a super-system as they describe how the sub-systems relate to each other. The composition method, used to describe a design on various levels of granularity, is also used to relate systems to each other to form super-systems. Together, all elements contribute to form an integrated model. Figure 17 presents a simplified version of it. The figure illustrates a selection of interfaces, interactions, and state models (from Figures 15 and 16). Furthermore, both the product and production systems are described using the composition mechanism. The Body-in-White system is composed of its production system (the Body Shop) and the Roof Panel system. The Roof Panel system is composed of its production system (Station 160) and the Inner Panel system, and so on. In a similar way, the production system Body Shop is composed of the Roof Panel Production system and the Inner Panel Production system. They are, in turn, composed using sub-designs, which are omitted in the figure. Compositions in the figure are mainly represented by the sub-system placed within the boundary of its super-systems. However, in a 2-D layout like Figure 17, it is not possible to fully comply with this representation. Even though the model itself complies with the modeling technique, the presentation must deviate when the complete picture is presented as it is in the figure. For example, both the Body Shop and the Inner Panel are composed using the Inner Panel Production system. However, that system is only explicitly shown inside the frame of the Body Shop. Instead, the composition of the Inner Panel is presented using a Production System and an arrow to the system.

Body in White

Body Shop

Composed of

Composed of

Production System

Roof Panel Production System (160) Pin

Roof Panel Composed of

Hole SM

Production System

Inner Panel Composed of

IA: Align with pin & hole

Part

SM

Inner Panel Production System (150)

Production System SM

Composed of

Composed of SM

Sheet Metal

Figure 17. An integrated model, with composition, interface, interaction and state models.

Figur 17

A21

Figure 18. An UML model describing the relationships between interface and interaction and their inheritance from design solution.

6. UML Model The relationship between interface and interaction can be expressed in a formal modeling language. Here, UML has been used, adding to the diagrams presented in other works elaborating on the CC framework. More precisely, the Generic Modeling Environment (GME) [25] formalism was applied in the creation of the class diagram in Figure 18. Both interface and interaction are specializations of design solutions. In other words, they inherit behavior from the design solution object as illustrated in the diagram. Through this relationship, it becomes apparent that interface and interaction can be included in a functionmeans tree, as it has been shown in Tables 1 and 2. To emphasize, because design solutions are elements of a system, interfaces and interactions will be so, too. In other words, interface is within a system’s boundary as one of its internal elements and not something in between two systems. The diagram also describes the relationship between interface and interaction. Interaction contains the information about which interfaces interact.

7. Discussion This paper focuses less on engineering processes but rather on information modeling of two technical systems, namely products and production systems. In this sense, it does not directly propose a method that prescribes or aims at restructuring engineering processes in order to achieve “concurrency and simultaneity”[10]. Rather, the artifacts product and production system are elaborated together with their interfaces and interactions. This in turn paves the way for utilizing any “inherent concurrency” [26] in the respective development process where appropriate. For this purpose, a mapping of the systems’ constituents with the development processes for these systems needs to be conducted if one desires a controlled and prescribed engineering process. With respect to the product and its development process, this mapping has been demonstrated e.g. by Eppinger et al. [27] and Prasad [10]. On reflection, when combined with such mapping, the here proposed elaboration of the product together with the production system can lay the foundation for managing the process of their co-development. The presented paper makes use of a real-life industrial example in two ways. The example A22

was taken as a reference, representing basically a typical manufacturing production setup (in other words, assembly combined with fabrication). This concrete example with the concrete interactions among product design, production system design, and processes provided necessary insights. These formed a sound footing to synthesize a model of the systems from the example and to complement the class model. The case was also applied here to exemplify how a product and the production system (used to produce the product) can be modeled. The application shown in the real-life example comes from manufacturing production, and the modeling approach presented is applicable in this area. Beyond that, its use is conceivable even in other industries dealing with discrete entities of production. These industries produce products with a specific lifecycle for each entity. The results presented in this research are applicable in these industries and valid in this specific context. The work presented is based on Systems Theory and the Configurable Component framework, and it must not conflict with these theories. Neither the specializations of design solutions into interface and interaction nor the approach to model products and production systems in a co-equal way indicate inconsistency with the base theories. Moreover, the results are consistent with the goal of a class model that can be applied to create a seamless integrated model that clarifies the dependencies between product and production systems. With the elaboration of interactions for models based on Configurable Components, it becomes clear that they do not form a hierarchical composition; rather, they form a network. This, for example, emphasizes that configuration is not achievable through a simple top-down approach. Instead, configuration can be the result of a number of interactions. The introduction of interactions that point at interfaces within another system results in another consequence: the autonomy of a configurable component can be perceived as limited. A solution for how to maintain autonomy is proposed in Section 4.3. Each system can within itself describe which surrounding systems it is designed to work with. Also evolving from the refinement presented here is the circumstance that a state model in one Configurable Component can affect a state model in another Configurable Component. Roughly speaking, both systems’ state models incorporate the same event. This double representation has to be accommodated.

8. Conclusion and Future Work This paper presents a means of support for the co-development of products and production systems. It does so by elaborating the idea of bringing products and production systems together in one integrated model. More specifically, it refines a class model, which is a structured foundation for modeling that can be implemented in computer-based support. With these modeling tools at hand Concurrent Engineering can be facilitated through information modeling across organizational groups. The contribution, seen from an academic perspective, is the refinement and further development of concepts and modeling methods of the Configurable Component framework. As a result and as reflected in the research question, this work shows how dependencies between the product and the production system, as well as their sub-systems, can be represented in an integrated model. Interfaces and interactions of these (sub-)systems can be represented on any level in the system structure. With this, stakeholders can select the granularity of the model they deem expedient. Moreover, the states of all systems can be modeled for purpose of representing their behavior A23

throughout their entire lifecycle. Also here stakeholders can select the level of detail (i.e. the granularity) at will. The resulting state models can be used to describe the changes of any system that interests the stakeholders. Introducing interface, interactions and state models, as proposed in this paper, leads to a vital advantage: it clarifies the dependencies between the product and production systems in a seamless model. Designers and stakeholders of a specific system can analyze and observe the system in its context. Modeling interfaces, interactions, and states is illustrated using a real-life industrial example. This real-life example also points to the industrial applicability of the proposed modeling approach. Companies can find support for the co-development of their products and their production systems. The approach is especially useful when companies want to design a variety of different products, e.g. following a platform strategy. It is also of use, when products and production systems are developed together over time, i.e. when they undergo a co-evolution. Finally, further work will be directed at three different aspects. First, it needs to be examined how configuration of a model can be achieved when modeling is not plainly hierarchical or top-down. Second, managing the representation of the same event in different state models needs further attention. Third, the question of a concrete procedure for applying the resulting integrated model in development work was intentionally left out of the scope of this paper and needs to be explored further.

Acknowledgements This work was carried out at the Wingquist Laboratory VINN Excellence Centre within the Area of Advance – Production at Chalmers University of Technology, supported by the Swedish Governmental Agency for Innovation Systems (VINNOVA). The support is gratefully acknowledged. We would also like to extend our thanks to Saab Automobile AB, industrial partner in the Centre.

References 1.

von Bertalanffy, L. (1968). General System Theory: Foundations, Development, Applications. New York: George Braziller.

2.

Robertson, D. and K. Ulrich. (1998), Planning product platforms. Sloan Management Review. 39(4): 19-31.

3.

Gedell, S. (2009). Platform-Based Design - Design Rational Aspects within the Configurable Component Concept [Licentiate Thesis]. Chalmers University of Technology: Gothenburg. 50.

4.

Claesson, A. (2006). A Configurable Component Framework Supporting Platform-Based Product Development [Doctoral Thesis]. Chalmers University of Technology: Gothenburg.

5.

Claesson, A., S. Gedell, and H. Johannesson. (2001). Platform Product Development: Product Model - A System Structure Composed of Configurable Components, in Proceedings of ASME DETC2001. Paper No. 21714.

6.

Claesson, A., B. Rosvall, and H. Johannesson. (2005). Capturing Design Knowledge of

A24

Robust Designs Using Configurable Components, in Proceedings of ASME DETC2005. Paper No. 85364. 7.

Gedell, S., H. Johannesson, and L. Holmberg. (2008). Design Rationale for Efficient Product Platform Development: A Systematic Configurable Component Approach. Proceedings of TMCE 2008 Symposium. 537-550.

8.

Tolio, T., et al. (2010), SPECIES-Co-evolution of products, processes and production systems. CIRP Annals - Manufacturing Technology.

9.

Huang, H.Z. and Y.K. Gu. (2006), Development Mode Based on Integration of Product Models and Process Models. Concurrent Engineering: Research and Applications. 14(1): 27-34.

10. Prasad, B. (1996). Concurrent Engineering Fundamentals, Volume 1: Integrated Product and Process Organization. Upper Saddle River, N.J.: Prentice Hall PTR. 11. UML. (2010). http://www.uml.org. Object Management Group. [accessed 10/18/2010]. 12. Wu, J.C., M.C. Leu, and X.F. Liu. (2009), A Hierarchical Object-oriented Functional Modeling Framework for Co-Design of Mechatronic Products. Concurrent Engineering: Research and Applications. 17(4): 245-256. 13. Huang, G.Q., X.Y. Zhang, and L. Liang. (2005), Towards integrated optimal configuration of platform products, manufacturing processes, and supply chains. Journal of Operations Management. 23(3-4): 267-290. 14. Jørgensen, K.A. (1992). Scientific Work Paradigms (Videnskabelige arbejdsparadigmer) (in Danish) Aalborg University Center: Aalborg, Denmark. 15. Sommerville, I. (2001). Software Engineering. International Computer Science Series, 99-0313059-7. Harlow: Addison-Wesley. 16. Hitchins, D.K. (2003). Advanced Systems – Thinking, Engineering, and Management. Norwood, MA: Artech House. 469. 17. Roozenburg, N.F.M. and J. Eekels. (1995). Product Design: Fundamentals and Methods. Wiley Series in Product Development, 99-2092755-4. Chichester: Wiley. 18. Checkland, P. (1981). Systems Thinking, Systems Practice. Chichester: Wiley. 19. Aristotle and W.D. Ross. (1936). Aristotle's Metaphysics: A Revised Text with Introduction and Commentary. Oxford. 20. von Bertalanffy, L. (1972), The History and Status of General Systems Theory. The Academy of Management Journal. 15(4): 407-426. 21. Andreasen, M.M. (1980). Synthesis Methods on a Systems Foundation – A Contribution to a Design Theory (Syntesemetoder på Systemgrundlag - Bidrag til en konstruktionsteori) (in Danish) [Doctoral Thesis]. Lund Technical University: Lund, Sweden. 22. Hubka, V. and W.E. Eder. (1988). Theory of Technical Systems : A Total Concept of Technical Systems. Berlin: Springer. 23. Wagner, F., R. Schmuki, and T. Wagner. (2006). Modeling Software with Finite State Machines: A Practical Approach. Boston, MA: Auerbach. 24. Vollmann, T.E., W.L. Berry, and D.C. Whybark. (1984). Manufacturing Planning and Control Systems. Homewood, Ill.: Dow Jones-Irwin. A25

25. GME. (2008). http://www.isis.vanderbilt.edu/projects/gme. Institute Integrated Systems, Vanderbild University. [accessed 10/18/2010].

of

Software

26. Prasad, B. (1999), Enabling principles of concurrency and simultaneity in concurrent engineering. Artificial Intelligence for Engineering Design, Analysis and Manufacturing. 13(3): 185-204. 27. Eppinger, S.D., et al. (1994), A Model-Based Method for Organizing Tasks in Product Development. Research in Engineering Design. 6(1): 1-13.

Stellan Gedell Stellan Gedell is currently a PhD student at the Department of Product and Production Development at Chalmers University of Technology in Gothenburg, Sweden. At the time of the study he was employed at Engineering Operations Sweden at Saab Automobile AB in Trollhättan, Sweden. He started his PhD studies at Chalmers University of Technology in 2008 focusing on integrated platformbased product development.

Marcel T. Michaelis Marcel T. Michaelis is currently a PhD student at the Department of Product and Production Development at Chalmers University of Technology in Gothenburg, Sweden. He started his PhD studies at Chalmers University of Technology in 2008 focusing co-development of product and production system platforms.

Hans Johannesson Dr Hans Johannesson is chair professor in Engineering Design at Chalmers University of Technology in Gothenburg, Sweden. He received his PhD in Machine Elements from Luleå University of Technology, Sweden in 1980. In 1984 he joined Chalmers where he was given the responsibility to establish education and research at Chalmers within Engineering Design and CAD. Today he is heading the Product Development division with some 40 employees. The research is carried out in close cooperation with Swedish automotive and aerospace industry within the framework of the Wingquist Laboratory.

A26