- Email: [email protected]
MODELLING AND SIMULATING APPROACH OF DISTRIBUTED DEVELOPMENT PROCESSES IN MECHATRONICS
MODELLING AND SIMULATING APPROACH OF DISTRIBUTED DEVELOPMENT PROCESSES IN MECHATRONICS F.-L. Krause*#, C. Biantoro# *
Fraunhofer-Institute for Production Systems and Design Technology, Department of Virtual Product Creation # Institute of Machine Tools and Factory Management, Department of Industrial Information Technology, Technische Universität Berlin Pascalstrasse 8-9, 10587 Berlin, Germany (frank. –l.krause;chris.biantoro)@ipk.fraunhofer.de Topic A (Methods and tools for multi-disciplinary systems development) Abstract: The attempt to improve mechatronic design processes is hindered by their complexity. The process complexity is mainly caused by an extensive process modularity and by the interdependencies of heterogeneous distributed processes which in turn are due to the interrelation of multidisciplinary domains. This paper proposes a new approach for planning and improving mechatronic design processes by modelling and simulating distributed development processes using object-oriented Petri Nets. For this purpose, this approach not only implements stochastic characteristics of development processes. It integrates design processes from different domains. In summary, a robust tool for planning and analysing mechatronic development processes is created. Copyright © 2006 IFAC Keywords: Concurrent Engineering, Distributed Models, Process Models, Petri Nets, Project Management.
1.
INTRODUCTION
In order to plan and optimise mechatronic design processes through implementing a process modelling and simulation approach, several aspects have to be taken into consideration with respect to the characteristics of the mechatronic design processes. In addition to simultaneous and collaborative processes, the design processes of mechatronic products are also characterised by extensive modularisations, hierarchies of processes and by a high degree of integrated design processes from different disciplines. The conditions above implicate interactions among processes which in turn produce interdependencies among them. Consequently any decisions made in one element of the design process in one company not only affect the succeeding process flows within that company but also the inter-
related process flows in other companies. The characteristics above present a number of stochastic features that increase the difficulty of modelling and analysing mechatronic development processes. These stochastic features are attributed to the expected process lead time, to the frequency of the iteration cycles and to the changes of the process parameter: content, required resources and costs as well as process structure. In addition, the uncertainties of the start time of the communication in the design process also lead to a stochastic feature. Several researchers have introduced approaches that consider some dynamic characteristics of the development processes, e.g. the process lead time, the iteration cycles and the process parameter (Krause, et al., 2004). Nevertheless, there is still a lack of process modelling tools and approaches that
336
also incorporate a dynamic modelling of the process structure in the distributed design environment. Therefore, this work focuses on developing an approach for modelling and simulating distributed development processes of mechatronic products. The new approach is developed on the basis of a distributed modelling environment whereby the overall model consists of several separated autonomous models. Each one of them is interrelated by means of a communication interface built into the system for process synchronization. This method enables each company to build and simulate its own process models according to its domain competencies and communicate its model states to other companies by means of a server. A joint integration between objects and Petri Nets is used for implementing this approach. The major advantage of applying this approach is an increase of the possibility to integrate a suppliers’ process model into the OEM’s process model. In addition, this approach also increases the possibility of modularizing the overall processes and modelling the process structure dynamically. These advantages enhance the efficiency and the quality of the results achieved by modelling and simulating mechatronic distributed development processes. 2. DISTRIBUTED DEVELOPMENT PROCESSES OF MECHATRONICS 2.1. Development Processes of Mechatronic Systems Interdisciplinary heterogeneity in mechatronic design processes can be integrated into a cross-domain process model. In addition to the phase model described by Kallenbach, et al. (1997) and Isermann (2003), the association of German engineers (VDI: Verein Deutscher Ingenieure) presents a guideline for a cross-domain process model. According to the VDI guideline 2206 (VDI, 2003), the macro level of the cross-domain process model of mechatronic design is derived from the V-Model of software development processes (see Fig. 1). The design of a mechatronic system begins with specifying the system requirements and subsequently with creating a functional structure based on the requirements. In this phase, which is also called System Design (left branch of V-Model), each function unit is realised by a variety of solution principles from different mechatronic domains which are modelled in form of a cross domain function model (Gausemeier, et al., 2002). These function models will be integrated by considering the importance of interfaces and parameters among the functions in order to create an abstracted model of the complete mechatronic system. A simulation of the complete system based on an abstracted model is
Fig. 1. V-Model according to VDI (2003). performed in order to evaluate the function models. In this design phase the OEM cooperates mostly with specific firms which have a special know how and are competent in their particular domains in finding a variety of solution principles. The design process then continues with detailing the abstracted model of the mechatronic system in a domain specific way in the form of functions and components (bottom part of V-Model). During this phase the OEM collaborates with the system suppliers in defining and modelling the solutions of each domain specific function and component simultaneously. Additionally, a simulation of the solution model is required in order to validate the mechanical structure as well as the controller structure and their interactions. For the mechanical and electrical/electronic domain, these activities belong to the geometrical modelling process. This process is followed by the physical-topological modelling process. Here a multi-body dynamics and elastic model derived from a reduced geometrical model will be analysed by means of simulation with respect to its behaviour, for instance in terms of material stiffness and in terms of temperature regarding mechanical components and in terms of inductivities as well as in terms of resistance with respect to electronics. In addition, in order to gain and optimise the model parameters, the result of the physical-topological model will be transformed into a mathematical model and optimised with the help of the available methods, (experimental model analyses and measurements). Then, this particular parameter will be tested and analysed as a decision basis for an optimal solution. In the software design of the microcontroller, the integration of mathematical modelling and coding processes is possible with the help of rapid controlling technology. The modelling algorithms can be directly tested and optimised in the real system because the C-Code will be generated at
337
instantly by automatic code generation. The optimized parameter will be used for detailing the reduced model in the geometrical modelling process. The process will be repeated in form of detailed model until an adequate granularity of the product model, namely the component model is achieved. The optimal solution of a component should be integrated with solutions of other components. It will have its physical interactions tested against specified requirements. This testing process can be performed with the help of software-in-the-loop in the early stage of the design or by hardware-in-the-loop (right branch of V-Model). 2.2. Information Exchange In mechatronic design processes, it is common to have misunderstandings between designers due to the heterogeneity of the information contained in the models. Therefore, it is very important to create an integrated design environment that can not only support the exchanges among the models from different domains but also between abstracted and detailed models. In addition to the integrated design environment as has been introduced by Lasa (2002), the information flow from an abstract model to a detailed model (top down process) requires the creation of tools and algorithms for modelling automation while considering the problem scope limitation. On the other hand, the information flow from the detailed model to the abstract model (bottom up process) needs the development of algorithms that derive from simplified models. In this context, Lasa described two main approaches of information exchange from different physical domains on the same level of abstraction, namely model exchange and cosimulation. Moreover, in order to realise model exchange consistently and smoothly, Gräb (2001) implemented an integration of different and domain specific models by means of parametric integration. The parameter is also used as an interface between the design process from one domain and other domains. It is implemented in the integrated design environment by parametric dependencies. In order to coordinate the parameter exchange optimally with respect to the information contents, design partners and information timing, it is very important to evaluate the processes and tasks dependencies. 3.
Another type of a high level Petri Net is an objectoriented Petri Net (OOPN). The OOPN combines objects and Petri Nets in the form of tokens. This means that a token is also an object that has attributes and methods. A process begins when a sequence of methods in an object is executed by transition firing. This condition will be evaluated by a method invocation which is stimulated only if the attribute of an object is equal to the variable specified in the input arc. This execution method changes the values of the attributes and produces a new instance of the object. Simultaneously, the token moves to another place. Places serve as containers for tokens which carry information of a system state. The characteristics of OOPNs are advantageous because they can be used for modelling and analysing the state changes in the states during the development of the processes. Another extension of OOPNs was proposed by Zapf and Heinzl (1999) who embedded the net models into objects. This enlarges the previous concept by determining the system structure in the form of an object and subsequently modelling the objects’ behaviour by means of the net. In this case, the object nets can contain tokens that have reference in relation to other objects the behaviour of which is also modelled with the help of the nets (see Fig. 2). In addition to this concept, a higher order of Petri Nets was implemented by Janneck and Esser (2002). This concept allows Petri Nets to be handled as a token which lies on a super place and is called as a component model. This model can be dynamically connected to and disconnected from other Petri Nets models. This component model, which has parameters, can be instantiated and connected to other related models via defined interfaces or ports. This characteristic increases the flexibility of composing and abstracting Petri Net models. Moreover, the concept also allows the generation of reusable model components. This possibility offers a remarkable benefit when modelling complex processes with arbitrary abstraction levels such as the mechatronic development processes. The method also makes the attempt to integrate different design processes via defined interfaces easier. Furthermore, it enables the cooperation of distributed design processes.
OBJECT-ORIENTED PETRI NETS
Petri Nets are noted as formalisms for modelling, simulating and analyzing dynamical systems with concurrent and non-deterministic behaviour. Petri Nets evolve from low-level Petri Nets, such as time Petri Nets, predicate/transition Petri Nets to High level Petri Nets such as coloured Petri Nets (CPN).
Fig. 2. Joint Integration between Objects and Petri Nets according to Zapf and Heinzl (1999).
338
4.
NEW APPROACH TO MODELLING AND SIMULATING DISTRIBUTED DEVELOPMENT PROCESSES FOR MECHATRONICS
4.1. Model Generation Model Structure The new approach constructs the distributed process models for mechatronic systems as described in the following model structure depicted in Fig. 3. The whole model is composed of distributed enterprise models which are interconnected by communication interfaces. The number of enterprise models is dependent on the number of partners with which OEM cooperates in developing its products. In other words, each enterprise model represents a supplier that participates in the development processes of its original equipment manufacturer. Each supplier can be responsible for developing a function unit or a component depending on which level in the development chain the supplier exists. Each enterprise model is composed of process models, resources models and data models. Process models consist of logical sequence of process flows, depending on the granularity level. This process model illustrates the hierarchy of the process structure and the modularisation of the mechatronic design process. The process model can also be specific for each discipline. The resource model represents all resources including human and design resources as well as simulation tools that are needed for each company to execute the design processes. The resource model also allows interdisciplinary team building which is responsible for developing function units. The data model stores all information that is relevant for the process model and the resource model as well as the model generated during simulation run time. To synchronise the processes within an enterprise model and beyond by information exchange, a communication interface is built into the process model. This interface serves both the activities of sending information to and receiving information from other process models. Concept of Modelling Distributed Processes The following example of a distributed design flow of a common-rail system illustrates the concept described above (see Fig. 4). To develop a common rail system, there are two companies participating in designing the sub-system of the high pressure generator. The OEM is responsible for designing the electronic circuit of a regulator valve and partner A is responsible for designing the mechanic part of the high pressure pump. If iteration occurs during the model testing process due to insufficient pressure generated in the former model (1a), the OEM has to decide whether to increase the number of the pistons and to modify the pump’s pressure. This decision influences the following process flows including the modelling process.
Fig. 3. Model Structure.
Fig. 4. Example – Distributed Process Modelling of Sub-System High Pressure Generator. Subsequently, before the modelling process begins, the state of the model is analysed first by accessing the data model (1b). Based on the data model, the corresponding generic modelling process (modelling pump with piston = 3) and the underlying activities are selected and executed (2). This results in the change of the pressure parameter. In order to synchronise this change with other dependent processes, the communication interface in the process model sends this parameter to the design processes of a regulator valve handled by the OEM (3). After the OEM receives this parameter, several adjustments in the processes have to be done including an iteration in the design process (4a). The change in the pressure parameter prompts the OEM to modify the electronic design of the valve. Hence, based on the data retrieved from the data model (4b), the appropriate generic modelling process (electronic design for i = 30 A) and the underlying activities are selected and executed (5). Simulation of Process Model The distributed process models base their simulation on the process model as the first level of model abstraction (see Fig. 5). Each process component in the process model can be broken down into several
339
steps in the process nets (second level of model abstraction). They are: the receiving parameter (b), the process execution (d), the iteration (e) and the sending parameter (f). The simulation proceeds if the token representing the developing object enters through the input port and arrives at a place (a). A transition (c) detects whether the required parameter has arrived on the super place (b). If this is the case, the developing token enters the super place (d) as a parameter and a new net object is instantiated (1). As the new net object is instantiated, the token, that represents the developing object, lies directly on the place in the new net object (third level of model abstraction). The transition (g) analyses the present state of the data model and according to the attribute in the developing object, the transition selects the corresponding generic process 1 modelled in the net object (2). The developing object will enter the super place of process 1 as a parameter and instantiate a new net object (fourth level of model abstraction) (3). The new net object could contain design activities and another new net object could be instantiated from each design activity (4). In the underlying nets of design activity (fifth level of model abstraction), the execution of design activity begins with implementing the super place ‘resource get’ (h). In this super place the required resources for executing the particular design activity are reserved for a certain stochastic delay. In this place (i), the activity is executed according to the stochastic firing time distribution and the data model specified for this activity is modified. Subsequently, the resources will be free (j) and the corresponding cost for this activity is incurred (k). At the end, there is a possibility to execute an iteration loop for this activity on the basis of an empiric distribution function (l).
If the activities for this particular process have been executed, the token representing the developing object will enter the super place iteration (e), and the overall process can be reiterated. If this is not necessary, then the resulting parameter is sent to dependent processes (f). 4.2. Distributed Modelling Environment A prototype of this approach was implemented by means of the Moses Petri Net tool (The Moses Project, 2001). In order to build the prototype, the Moses tool was engineered by modifying its Java classes and adding new Java classes specified for distributed modelling and simulation. By using the Moses tool, a cooperative modelling and simulation environment for distributed modelling and simulation is built by implementing client-server architecture (see Fig. 6). For this purpose, a neutral server and the simulation function are connected with the data base. In this environment each company (OEM or supplier) can build and simulate its process model independently of other process models (distributed modelling). At the beginning of a simulation, the server retrieves model states not only from a particular client and stores them in the central data base. It also retrieves model states from other related clients. Subsequently, during the simulation run time, the server starts the simulation function and afterwards the simulation function connects with the central data base in order to store all simulation results. If each particular client is to present the specific results after simulation, the server connects the central data base and retrieves the particular model states as well as the simulation results (central simulation). Subsequently, the server gives to the client the simulation results and the current model states.
Fig. 6. Cooperative Modelling and Simulation by Client-Server Architecture. Fig. 5. Simulation of Distributed Process Models.
340
4.3. Simulation Results By analysing the attributes in the development object of a particular model that are stored in the central database after the simulation, the server receives and classifies the simulation results. Subsequently, the server sends some information concerning development time (see Fig. 7) and costs as well as resource utilisation to each client to which it is significant. Thus, not only the OEM, but also each supplier has a possibility to present and analyse the simulation results of its model in conjunction with other relating models. This condition increases the quality of the simulation. It also brings more detailed knowledge about its own design processes to each supplier and by doing so helps them to improve their own process models. Moreover, the results are presented not only for entire development processes, but also for each milestone Thus, the progress of the development processes can be observed regarding time and costs. By having a process observer, the modeller is able to supervise whether a process requires a parameter and if the operation receives it from other processes. This capability is crucial in analysing the communication time. Based on the simulation results, a process optimisation can be carried out by developing a number of strategies for analysing and eliminating weak points in the process.
Fig. 7. Time Distribution of Design Process of OEM. 5. CONCLUSION AND ACKNOWLEDGEMENTS This paper presents a modelling and simulating approach for distributed development processes in mechatronic products. An extended object-oriented Petri Net (OOPN) is used for the purpose of implementing this approach. In the implementation step, there are two types of tokens: tokens representing object nets and tokens representing the developing object. The former serves process modularisation, the latter serves process flows. This approach has some advantages in comparison to existing modelling approaches and tools: (1) it enables the modeller to model and to simulate not only the parameters of the design processes, such
as lead time, costs, resources and contents, but also the process structure dynamically and stochastically. This ability can be used to dynamically model and simulate the changes in the process structure due to changes of design methodology along the mechatronic design processes. (2) This approach enables the modeller to integrate the design processes from partners of different companies and domains by exchanging design parameters. (3) The process model can be arbitrarily modularised in a hierarchical structure. This ability fits mechatronic design processes that are characterised by high process modularisation. The authors thank the Deutsche Forschungsgemeinschaft (DFG) for financing the research training groups ‘Stochastic Modelling and Quantitative Analysis of Complex Systems in Engineering’ (GRK 621). REFERENCES Gausemeier, J., Flath, M. and Möhringer, S. (2002). Modelling of functions of mechatronic systems, exemplified by tyre pressure control in automotive systems, In: International Journal of Vehicle Design Vol. 28, Nos.1/2/3. 5-17. Gräb, R. (2001). Parametrische Integration von Produktmodellen für die Entwicklung mechatronischer Produkte. Shaker Verlag, Aachen. Isermann, R. (2003). Mechatronic systems: fundamentals. Springer Verlag, Berlin. Janneck, J.W., Esser, R. (2002). Higher-order Petri Net Modelling- Techniques and Applications. In: Workshop on Software Engineering and Formal Methods, Petri Nets 2002. Kallenbach, E., et al. (1997). Zur Gestaltung integrierter mechatronischer Produkte. In: Tagung Mechatronik im Maschinen – und Fahrzeugbau. Krause, F.-L., Kind, C. and Voigtsberger, J. (2004). Adaptive Modelling and Simulation of Product Development Processes. In: Annals of the CIRP, 53/1. 135-138. Lasa, M. (2002). A system engineering approach for computer based design in mechatronics: a common rail application. In: ForschrittBerichte VDI, Reihe 20: Rechnerunterstützte Verfahren; 349. VDI-Verlag, Düsseldorf. The Moses Project. (2001). Moses Petri Net Tool. Computer Engineering and Communication Networks Lab (TIK), ETH Zurich. Verein Deutscher Ingenieure. (2002). Entwicklungsmethodik für mechatronische Systeme. In: VDI Guideline 2206. VDI, Düsseldorf. Zapf, M., Heinzl, A. (1999). Techniques for Integrating Petri nets and Object-Oriented Concepts, In: Working Papers in Information Systems. University of Bayreuth.
341
Fraunhofer-Institute for Production Systems and Design Technology, Department of Virtual Product Creation # Institute of Machine Tools and Factory Management, Department of Industrial Information Technology, Technische Universität Berlin Pascalstrasse 8-9, 10587 Berlin, Germany (frank. –l.krause;chris.biantoro)@ipk.fraunhofer.de Topic A (Methods and tools for multi-disciplinary systems development) Abstract: The attempt to improve mechatronic design processes is hindered by their complexity. The process complexity is mainly caused by an extensive process modularity and by the interdependencies of heterogeneous distributed processes which in turn are due to the interrelation of multidisciplinary domains. This paper proposes a new approach for planning and improving mechatronic design processes by modelling and simulating distributed development processes using object-oriented Petri Nets. For this purpose, this approach not only implements stochastic characteristics of development processes. It integrates design processes from different domains. In summary, a robust tool for planning and analysing mechatronic development processes is created. Copyright © 2006 IFAC Keywords: Concurrent Engineering, Distributed Models, Process Models, Petri Nets, Project Management.
1.
INTRODUCTION
In order to plan and optimise mechatronic design processes through implementing a process modelling and simulation approach, several aspects have to be taken into consideration with respect to the characteristics of the mechatronic design processes. In addition to simultaneous and collaborative processes, the design processes of mechatronic products are also characterised by extensive modularisations, hierarchies of processes and by a high degree of integrated design processes from different disciplines. The conditions above implicate interactions among processes which in turn produce interdependencies among them. Consequently any decisions made in one element of the design process in one company not only affect the succeeding process flows within that company but also the inter-
related process flows in other companies. The characteristics above present a number of stochastic features that increase the difficulty of modelling and analysing mechatronic development processes. These stochastic features are attributed to the expected process lead time, to the frequency of the iteration cycles and to the changes of the process parameter: content, required resources and costs as well as process structure. In addition, the uncertainties of the start time of the communication in the design process also lead to a stochastic feature. Several researchers have introduced approaches that consider some dynamic characteristics of the development processes, e.g. the process lead time, the iteration cycles and the process parameter (Krause, et al., 2004). Nevertheless, there is still a lack of process modelling tools and approaches that
336
also incorporate a dynamic modelling of the process structure in the distributed design environment. Therefore, this work focuses on developing an approach for modelling and simulating distributed development processes of mechatronic products. The new approach is developed on the basis of a distributed modelling environment whereby the overall model consists of several separated autonomous models. Each one of them is interrelated by means of a communication interface built into the system for process synchronization. This method enables each company to build and simulate its own process models according to its domain competencies and communicate its model states to other companies by means of a server. A joint integration between objects and Petri Nets is used for implementing this approach. The major advantage of applying this approach is an increase of the possibility to integrate a suppliers’ process model into the OEM’s process model. In addition, this approach also increases the possibility of modularizing the overall processes and modelling the process structure dynamically. These advantages enhance the efficiency and the quality of the results achieved by modelling and simulating mechatronic distributed development processes. 2. DISTRIBUTED DEVELOPMENT PROCESSES OF MECHATRONICS 2.1. Development Processes of Mechatronic Systems Interdisciplinary heterogeneity in mechatronic design processes can be integrated into a cross-domain process model. In addition to the phase model described by Kallenbach, et al. (1997) and Isermann (2003), the association of German engineers (VDI: Verein Deutscher Ingenieure) presents a guideline for a cross-domain process model. According to the VDI guideline 2206 (VDI, 2003), the macro level of the cross-domain process model of mechatronic design is derived from the V-Model of software development processes (see Fig. 1). The design of a mechatronic system begins with specifying the system requirements and subsequently with creating a functional structure based on the requirements. In this phase, which is also called System Design (left branch of V-Model), each function unit is realised by a variety of solution principles from different mechatronic domains which are modelled in form of a cross domain function model (Gausemeier, et al., 2002). These function models will be integrated by considering the importance of interfaces and parameters among the functions in order to create an abstracted model of the complete mechatronic system. A simulation of the complete system based on an abstracted model is
Fig. 1. V-Model according to VDI (2003). performed in order to evaluate the function models. In this design phase the OEM cooperates mostly with specific firms which have a special know how and are competent in their particular domains in finding a variety of solution principles. The design process then continues with detailing the abstracted model of the mechatronic system in a domain specific way in the form of functions and components (bottom part of V-Model). During this phase the OEM collaborates with the system suppliers in defining and modelling the solutions of each domain specific function and component simultaneously. Additionally, a simulation of the solution model is required in order to validate the mechanical structure as well as the controller structure and their interactions. For the mechanical and electrical/electronic domain, these activities belong to the geometrical modelling process. This process is followed by the physical-topological modelling process. Here a multi-body dynamics and elastic model derived from a reduced geometrical model will be analysed by means of simulation with respect to its behaviour, for instance in terms of material stiffness and in terms of temperature regarding mechanical components and in terms of inductivities as well as in terms of resistance with respect to electronics. In addition, in order to gain and optimise the model parameters, the result of the physical-topological model will be transformed into a mathematical model and optimised with the help of the available methods, (experimental model analyses and measurements). Then, this particular parameter will be tested and analysed as a decision basis for an optimal solution. In the software design of the microcontroller, the integration of mathematical modelling and coding processes is possible with the help of rapid controlling technology. The modelling algorithms can be directly tested and optimised in the real system because the C-Code will be generated at
337
instantly by automatic code generation. The optimized parameter will be used for detailing the reduced model in the geometrical modelling process. The process will be repeated in form of detailed model until an adequate granularity of the product model, namely the component model is achieved. The optimal solution of a component should be integrated with solutions of other components. It will have its physical interactions tested against specified requirements. This testing process can be performed with the help of software-in-the-loop in the early stage of the design or by hardware-in-the-loop (right branch of V-Model). 2.2. Information Exchange In mechatronic design processes, it is common to have misunderstandings between designers due to the heterogeneity of the information contained in the models. Therefore, it is very important to create an integrated design environment that can not only support the exchanges among the models from different domains but also between abstracted and detailed models. In addition to the integrated design environment as has been introduced by Lasa (2002), the information flow from an abstract model to a detailed model (top down process) requires the creation of tools and algorithms for modelling automation while considering the problem scope limitation. On the other hand, the information flow from the detailed model to the abstract model (bottom up process) needs the development of algorithms that derive from simplified models. In this context, Lasa described two main approaches of information exchange from different physical domains on the same level of abstraction, namely model exchange and cosimulation. Moreover, in order to realise model exchange consistently and smoothly, Gräb (2001) implemented an integration of different and domain specific models by means of parametric integration. The parameter is also used as an interface between the design process from one domain and other domains. It is implemented in the integrated design environment by parametric dependencies. In order to coordinate the parameter exchange optimally with respect to the information contents, design partners and information timing, it is very important to evaluate the processes and tasks dependencies. 3.
Another type of a high level Petri Net is an objectoriented Petri Net (OOPN). The OOPN combines objects and Petri Nets in the form of tokens. This means that a token is also an object that has attributes and methods. A process begins when a sequence of methods in an object is executed by transition firing. This condition will be evaluated by a method invocation which is stimulated only if the attribute of an object is equal to the variable specified in the input arc. This execution method changes the values of the attributes and produces a new instance of the object. Simultaneously, the token moves to another place. Places serve as containers for tokens which carry information of a system state. The characteristics of OOPNs are advantageous because they can be used for modelling and analysing the state changes in the states during the development of the processes. Another extension of OOPNs was proposed by Zapf and Heinzl (1999) who embedded the net models into objects. This enlarges the previous concept by determining the system structure in the form of an object and subsequently modelling the objects’ behaviour by means of the net. In this case, the object nets can contain tokens that have reference in relation to other objects the behaviour of which is also modelled with the help of the nets (see Fig. 2). In addition to this concept, a higher order of Petri Nets was implemented by Janneck and Esser (2002). This concept allows Petri Nets to be handled as a token which lies on a super place and is called as a component model. This model can be dynamically connected to and disconnected from other Petri Nets models. This component model, which has parameters, can be instantiated and connected to other related models via defined interfaces or ports. This characteristic increases the flexibility of composing and abstracting Petri Net models. Moreover, the concept also allows the generation of reusable model components. This possibility offers a remarkable benefit when modelling complex processes with arbitrary abstraction levels such as the mechatronic development processes. The method also makes the attempt to integrate different design processes via defined interfaces easier. Furthermore, it enables the cooperation of distributed design processes.
OBJECT-ORIENTED PETRI NETS
Petri Nets are noted as formalisms for modelling, simulating and analyzing dynamical systems with concurrent and non-deterministic behaviour. Petri Nets evolve from low-level Petri Nets, such as time Petri Nets, predicate/transition Petri Nets to High level Petri Nets such as coloured Petri Nets (CPN).
Fig. 2. Joint Integration between Objects and Petri Nets according to Zapf and Heinzl (1999).
338
4.
NEW APPROACH TO MODELLING AND SIMULATING DISTRIBUTED DEVELOPMENT PROCESSES FOR MECHATRONICS
4.1. Model Generation Model Structure The new approach constructs the distributed process models for mechatronic systems as described in the following model structure depicted in Fig. 3. The whole model is composed of distributed enterprise models which are interconnected by communication interfaces. The number of enterprise models is dependent on the number of partners with which OEM cooperates in developing its products. In other words, each enterprise model represents a supplier that participates in the development processes of its original equipment manufacturer. Each supplier can be responsible for developing a function unit or a component depending on which level in the development chain the supplier exists. Each enterprise model is composed of process models, resources models and data models. Process models consist of logical sequence of process flows, depending on the granularity level. This process model illustrates the hierarchy of the process structure and the modularisation of the mechatronic design process. The process model can also be specific for each discipline. The resource model represents all resources including human and design resources as well as simulation tools that are needed for each company to execute the design processes. The resource model also allows interdisciplinary team building which is responsible for developing function units. The data model stores all information that is relevant for the process model and the resource model as well as the model generated during simulation run time. To synchronise the processes within an enterprise model and beyond by information exchange, a communication interface is built into the process model. This interface serves both the activities of sending information to and receiving information from other process models. Concept of Modelling Distributed Processes The following example of a distributed design flow of a common-rail system illustrates the concept described above (see Fig. 4). To develop a common rail system, there are two companies participating in designing the sub-system of the high pressure generator. The OEM is responsible for designing the electronic circuit of a regulator valve and partner A is responsible for designing the mechanic part of the high pressure pump. If iteration occurs during the model testing process due to insufficient pressure generated in the former model (1a), the OEM has to decide whether to increase the number of the pistons and to modify the pump’s pressure. This decision influences the following process flows including the modelling process.
Fig. 3. Model Structure.
Fig. 4. Example – Distributed Process Modelling of Sub-System High Pressure Generator. Subsequently, before the modelling process begins, the state of the model is analysed first by accessing the data model (1b). Based on the data model, the corresponding generic modelling process (modelling pump with piston = 3) and the underlying activities are selected and executed (2). This results in the change of the pressure parameter. In order to synchronise this change with other dependent processes, the communication interface in the process model sends this parameter to the design processes of a regulator valve handled by the OEM (3). After the OEM receives this parameter, several adjustments in the processes have to be done including an iteration in the design process (4a). The change in the pressure parameter prompts the OEM to modify the electronic design of the valve. Hence, based on the data retrieved from the data model (4b), the appropriate generic modelling process (electronic design for i = 30 A) and the underlying activities are selected and executed (5). Simulation of Process Model The distributed process models base their simulation on the process model as the first level of model abstraction (see Fig. 5). Each process component in the process model can be broken down into several
339
steps in the process nets (second level of model abstraction). They are: the receiving parameter (b), the process execution (d), the iteration (e) and the sending parameter (f). The simulation proceeds if the token representing the developing object enters through the input port and arrives at a place (a). A transition (c) detects whether the required parameter has arrived on the super place (b). If this is the case, the developing token enters the super place (d) as a parameter and a new net object is instantiated (1). As the new net object is instantiated, the token, that represents the developing object, lies directly on the place in the new net object (third level of model abstraction). The transition (g) analyses the present state of the data model and according to the attribute in the developing object, the transition selects the corresponding generic process 1 modelled in the net object (2). The developing object will enter the super place of process 1 as a parameter and instantiate a new net object (fourth level of model abstraction) (3). The new net object could contain design activities and another new net object could be instantiated from each design activity (4). In the underlying nets of design activity (fifth level of model abstraction), the execution of design activity begins with implementing the super place ‘resource get’ (h). In this super place the required resources for executing the particular design activity are reserved for a certain stochastic delay. In this place (i), the activity is executed according to the stochastic firing time distribution and the data model specified for this activity is modified. Subsequently, the resources will be free (j) and the corresponding cost for this activity is incurred (k). At the end, there is a possibility to execute an iteration loop for this activity on the basis of an empiric distribution function (l).
If the activities for this particular process have been executed, the token representing the developing object will enter the super place iteration (e), and the overall process can be reiterated. If this is not necessary, then the resulting parameter is sent to dependent processes (f). 4.2. Distributed Modelling Environment A prototype of this approach was implemented by means of the Moses Petri Net tool (The Moses Project, 2001). In order to build the prototype, the Moses tool was engineered by modifying its Java classes and adding new Java classes specified for distributed modelling and simulation. By using the Moses tool, a cooperative modelling and simulation environment for distributed modelling and simulation is built by implementing client-server architecture (see Fig. 6). For this purpose, a neutral server and the simulation function are connected with the data base. In this environment each company (OEM or supplier) can build and simulate its process model independently of other process models (distributed modelling). At the beginning of a simulation, the server retrieves model states not only from a particular client and stores them in the central data base. It also retrieves model states from other related clients. Subsequently, during the simulation run time, the server starts the simulation function and afterwards the simulation function connects with the central data base in order to store all simulation results. If each particular client is to present the specific results after simulation, the server connects the central data base and retrieves the particular model states as well as the simulation results (central simulation). Subsequently, the server gives to the client the simulation results and the current model states.
Fig. 6. Cooperative Modelling and Simulation by Client-Server Architecture. Fig. 5. Simulation of Distributed Process Models.
340
4.3. Simulation Results By analysing the attributes in the development object of a particular model that are stored in the central database after the simulation, the server receives and classifies the simulation results. Subsequently, the server sends some information concerning development time (see Fig. 7) and costs as well as resource utilisation to each client to which it is significant. Thus, not only the OEM, but also each supplier has a possibility to present and analyse the simulation results of its model in conjunction with other relating models. This condition increases the quality of the simulation. It also brings more detailed knowledge about its own design processes to each supplier and by doing so helps them to improve their own process models. Moreover, the results are presented not only for entire development processes, but also for each milestone Thus, the progress of the development processes can be observed regarding time and costs. By having a process observer, the modeller is able to supervise whether a process requires a parameter and if the operation receives it from other processes. This capability is crucial in analysing the communication time. Based on the simulation results, a process optimisation can be carried out by developing a number of strategies for analysing and eliminating weak points in the process.
Fig. 7. Time Distribution of Design Process of OEM. 5. CONCLUSION AND ACKNOWLEDGEMENTS This paper presents a modelling and simulating approach for distributed development processes in mechatronic products. An extended object-oriented Petri Net (OOPN) is used for the purpose of implementing this approach. In the implementation step, there are two types of tokens: tokens representing object nets and tokens representing the developing object. The former serves process modularisation, the latter serves process flows. This approach has some advantages in comparison to existing modelling approaches and tools: (1) it enables the modeller to model and to simulate not only the parameters of the design processes, such
as lead time, costs, resources and contents, but also the process structure dynamically and stochastically. This ability can be used to dynamically model and simulate the changes in the process structure due to changes of design methodology along the mechatronic design processes. (2) This approach enables the modeller to integrate the design processes from partners of different companies and domains by exchanging design parameters. (3) The process model can be arbitrarily modularised in a hierarchical structure. This ability fits mechatronic design processes that are characterised by high process modularisation. The authors thank the Deutsche Forschungsgemeinschaft (DFG) for financing the research training groups ‘Stochastic Modelling and Quantitative Analysis of Complex Systems in Engineering’ (GRK 621). REFERENCES Gausemeier, J., Flath, M. and Möhringer, S. (2002). Modelling of functions of mechatronic systems, exemplified by tyre pressure control in automotive systems, In: International Journal of Vehicle Design Vol. 28, Nos.1/2/3. 5-17. Gräb, R. (2001). Parametrische Integration von Produktmodellen für die Entwicklung mechatronischer Produkte. Shaker Verlag, Aachen. Isermann, R. (2003). Mechatronic systems: fundamentals. Springer Verlag, Berlin. Janneck, J.W., Esser, R. (2002). Higher-order Petri Net Modelling- Techniques and Applications. In: Workshop on Software Engineering and Formal Methods, Petri Nets 2002. Kallenbach, E., et al. (1997). Zur Gestaltung integrierter mechatronischer Produkte. In: Tagung Mechatronik im Maschinen – und Fahrzeugbau. Krause, F.-L., Kind, C. and Voigtsberger, J. (2004). Adaptive Modelling and Simulation of Product Development Processes. In: Annals of the CIRP, 53/1. 135-138. Lasa, M. (2002). A system engineering approach for computer based design in mechatronics: a common rail application. In: ForschrittBerichte VDI, Reihe 20: Rechnerunterstützte Verfahren; 349. VDI-Verlag, Düsseldorf. The Moses Project. (2001). Moses Petri Net Tool. Computer Engineering and Communication Networks Lab (TIK), ETH Zurich. Verein Deutscher Ingenieure. (2002). Entwicklungsmethodik für mechatronische Systeme. In: VDI Guideline 2206. VDI, Düsseldorf. Zapf, M., Heinzl, A. (1999). Techniques for Integrating Petri nets and Object-Oriented Concepts, In: Working Papers in Information Systems. University of Bayreuth.
341