Definition of the engineering methodology

Transcription

1 integration of process and quality Control using multi-agent technology Work Package 4 Engineering methodology Deliverable D4.2 Definition of the engineering methodology Document type : Deliverable Document version : Final Document Preparation Date : 01/04/2012 Classification : Public Author(s) : SIEMENS File Name : Deliverable 4.2 Definition of the engineering methodology_v1.0.pdf Project Ref. Number : Project Start Date : 01/07/2010 Project Duration : 36 months Website : Project funded by the European Commission under the Seventh Framework Programme ( ) Contract n NMP2-SL

2 Rev. Content Resp. Partner Date 0.1 Document structure SIEMENS 14/02/ Adding chapter 2 SIEMENS 22/02/ Adding chapter 3 SIEMENS 24/02/ Adding chapter 2.2 SIEMENS 07/03/ Include input from IPB on HMS and MAS SIEMENS 12/03/ Include chapter 4 SIEMENS 14/03/ Include chapter 5 and finalize SIEMENS 15/03/ Include Siemens internal Re and prepare SIEMENS 19/03/2012 for partner re 1.0 Include Re from Partners and prepare final document SIEMENS 29/03/2012 2

3 Table of contents Table of contents...3 Table of figures...5 Glossary...6 Acronyms/Abbreviations Introduction The mechatronic approach Mechatronic units Integration of GRACE MAS and mechatronic unit approach Synergies of the integrated approach Engineering activities MAS engineering activities Identification of mechatronic units Identification of integrated agents Identification of stand-alone agents Derivation of a System architecture Instantiation Implementation Module tests Integration Integration test Additional general engineering activities Project management Procurement Engineering workflow Conclusion...44 References

4 Appendix A GRACE engineering methodology

5 Table of figures Figure 1: Relations between Engineering process and engineering artefacts...7 Figure 2: Intention and goals of GRACE WP Figure 3: The mechatronic system (based on [GEK01])...15 Figure 4: Information structure of mechatronic units (based on [Kie07])...17 Figure 5: The mechatronic unit...18 Figure 6: Interface concept for mechatronic units...19 Figure 7: UML Class Diagram for GRACE Agent Classes (following [Ins11])...21 Figure 8: GRACE Agent integrated into mechatronic unit (integrated agent)...24 Figure 9: GRACE engineering workflow model Phase Figure 10: GRACE engineering workflow model Phase Figure 11: GRACE engineering workflow model Phase Figure 12: GRACE engineering workflow model Phase Figure 13: Engineering methodology framework

6 Glossary The following section defines the understanding and uses of different terms within this document. Domain - An area of knowledge that (1) is scoped to maximize the satisfaction of the requirements of its stakeholders, (2) includes a set of concepts and terminology understood by practitioners in that area and (3) includes the knowledge of how to build (software) systems in that area Engineering Following [Enc11] engineering is the creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property. Engineering process An engineering process is a coordinated course of knowledge use actions. It is divided into a set of phases targeting different levels of detail and concreteness of the engineering objects. Mechatronic engineering process A mechatronic engineering process is an engineering process where the involved engineering objects are mechatronic units and mechatronic systems. Engineering artefact An engineering artefact is an object created or used within one or more actions of an engineering process. Within early phases of engineering processes engineering artefacts are usually of informational nature while in later phases they can also be of physical nature. 6

7 Figure 1: Relations between Engineering process and engineering artefacts Engineering tool - An engineering tool is a software system designed to model, process, and store plant components or facets within an engineering process. Manufacturing Industry - Task and aim of manufacturing engineering is the production of geometric determined solid bodies (workpiece, assembly group, products) with preset attributes by application of various manufacturing methods. Mechatronic system - A mechatronic system is a closed system that realizes by its actuating elements, its sensor system and its control a defined (usually physical) behavior within a manufacturing system. It is composed of one or more mechatronic units and may be processed like a mechatronic unit during the engineering. Mechatronic engineering activity - A mechatronic engineering activity (MEA) is an action within the mechatronic engineering process. It is assigned to one or more phases of the engineering process, executed by one involved engineering role, and has impact on the design of a mechatronic system or unit. Mechatronic modeling concept - A mechatronic modeling concept is an approach to map mechatronic systems or units to plant components or facets by structure and relationship. Mechatronic unit (MU) - A mechatronic unit (plant component) is a mechatronic system that can be described by its functionality and is composed of software (control) and hardware (mechanical, electrical, and further construction) objects. 7

8 Model - A model is a representation of a real system or a couple of systems. Models have three significant features: (1) Representation. A model is always a representation of natural and artificial originals which could be models, too. (2) Reduction. A model does not have all attributes and aspects of the original, just those, which seem to be relevant to the model user or creator. (3) Intended purpose. Creating a model has always a purpose defined by the intended use of the model. The usage defines the model relevant parts and aspects. A model is featured by abstraction which means the conscious reduction of reality to stress model features important for the modeler or for the model intention. Modules In the context of this deliverable the use of the word module should be understood as a collective term to describe the entirety of both agents and mechatronic units. This is done to cover all application cases e.g. agents interacting with agents, agents interacting with mechatronic units, vice versa and mechatronic units interacting with mechatronic units. Plant - Plants are large assemblies of technical devices to produce certain technical products usually in a fully or semi-automatic way. Plants execute technological processes which produce the technical products from several processing steps. Plant components - Reusable unit, which is completed and encapsulated, with defined interfaces to the outside. A component is an aggregation of building blocks. Production station - In the sense of this deliverable a production station is a specific part of the production line. This includes not only those stations which are adding value/functionality to the product, but also stations for controlling the product quality (quality control stations). The following terms of multi-agent-systems are defined according to [Ins11]: Agent - An autonomous component, that represents physical or logical objects in the system, capable to act in order to achieve its goals, and being able to interact with other agents, when it doesn t possess knowledge and/or skills to reach its objectives on its own. 8

9 Distributed Control System (DCS) - A dedicated system used to control manufacturing processes that are continuous or batch-oriented. DCSs are connected to sensors and actuators, normally through Programmable Logic Controllers (PLCs) and use set-point control to control the flow of material through the plant. Holon - An identifiable part of a (manufacturing) system that has a unique identity, yet is made up of sub-ordinate parts and in turn is part of a larger whole. Multi-agent systems (MAS) - Society of agents that represent the objects of a system that interact with each other to reach the system objectives. Moby - is an electronic RFiD tag attached to the pallet carrying the products along the production line, identifying univocally each product. The tag contains information that can be accessed by a RFiD reader. Product - In the sense of this work, a product is not only related to final products commercialized by OEM companies, but also intermediate parts/components that comprise complex products. Examples of products are washing machines or drums. 9

10 Acronyms/Abbreviations ADACOR ADAptive holonic COntrol architecture for distributed manufacturing systems BOM BoO Dx.y ERP FAT FOL GRACE HMS I/O ID IDEAS IMA MA MAS MES MU OA P2 PA PABADIS PROMISE PC PLC PROSA PTA QCA Bill of Material Bill of Operations Deliverable x.y Enterprise Resource Planning Final Acceptance Test First Order Logic integration of process and quality Control using multi-agent technology Holonic Manufacturing System Input/Output (Interface) Identifier Instantly Deployable Evolvable Assembly System Independent Meta Agent Machine Agent Multi-Agent System Manufacturing Execution System Mechatronic Unit Operator Agent see PABADIS PROMISE Product Agent Plant Automation based on Distributed System Product Oriented Manufacturing Systems for Re-Configurable Enterprises Personal Computer Programmable Logic Controller Product Resource Order Staff reference Architecture Product Type Agent Quality Control Agent 10

11 RA TA UML WP XML Resource Agent Transport Agent Unified Modelling Language Work Package Extensible Markup Language 11

12 1. Introduction The Deliverable 4.2 is the second output of work package 4 Engineering methodology. Within this work package a new engineering methodology for decentralized manufacturing systems based on the GRACE Multi Agent System (MAS) platform will be developed. The main objective here is to identify the impact of GRACE new control concepts on manufacturing engineering activities, to create suitable and effective engineering concepts for decentralized automation, and to render them applicable for industrial applications. In particular, the following objectives will be reached: Provision of activity model based engineering process guideline supporting the combination of manufacturing entities for rapid creation of case dependent GRACE MAS platform adaptations using standardized interfaces. Definition of possibilities to easily extend GRACE MAS platform capability for providing changed additional functionalities with a minimum effort in order to enhance and adapt MAS to changing requirements from products, types of production and quality assurance, or manufacturing technology. Support for the management of production models, data and further relevant information on GRACE MAS platform and its engineering including behavior modeling for control application and overall behavior analysis. Main Objective: A new engineering methodology for decentralized manufacturing control systems based on the GRACE MAS platform Identify impact of GRACE control concepts on manufacturing engineering activities Create suitable and effective engineering concepts for decentralized automation Render them applicable for industrial applications Figure 2: Intention and goals of GRACE WP 4 Within task 4.1 a general engineering process reference model for manufacturing systems was defined, which was developed and evaluated for domains like automotive 12

13 production lines or home appliance production lines. It was then adapted and extended towards a detailed GRACE specific engineering process for home appliance production lines including process and quality control. The model was created by dissecting the engineering of the production line in its phases, decomposing the working processes (e.g., layout planning) within the individual phases into individual activities and, identifying their relations, and influences (causes and effects) with system properties of the process & quality control system. This model and the additional information presented in Deliverable 4.1 will serve as a basis for the engineering methodology presented within this second deliverable. Like Deliverable 4.1 also Deliverable 4.2 will be divided in two parts, one public and one confidential. The intention is to develop the engineering methodology in two sequential steps. The first step will be the definition of a general engineering methodology, which is applicable for a high number of engineering domains in factory automation like automotive, home appliance, consumer goods, etc. This first part is subject of this deliverable and will be available as a public document. It will show: how to map GRACE modular architecture to a modular engineering approach by utilizing use cases for modular manufacturing concepts, which new engineering activities are needed or which activities have to be changed for the engineering of MASs, by interpolating the GRACE MAS concepts of WP 1, the definition of generic hardware and software structures for the customization of GRACE MAS platform. The second step includes a domain and potentially also OEM specific detailing of the general engineering process reference model, containing definition of methodology supporting the identification of (reusable) modules, definition of a model supporting the quality-oriented application of the engineering methodology, and elaboration of required changes of the engineering workflow (activities/documents) presented in [Sie11] due to MAS influence. Results of step 2 will be given in Appendix A to this paper, which will be a new deliverable. Within the GRACE project this detailed model will serve as the GRACE engineering methodology and will therefore only be available to the project partners due to confidentiality of Whirlpool specific information. 13

14 With the help of this bisection, the GRACE project will provide a sort of public red line for MAS engineering methodology including a basic workflow model showing the interactions between different tasks, phases and disciplines of the engineering process. Never the less we are also aware that there will be no general engineering methodology applicable for each domain. Therefore Appendix A shows how this methodology could be easily rendered to fit the specific domain of home appliance production. The industrial interest of the partner Whirlpool for this specific sector motivates the classification of Appendix A as confidential. This document is structured as follows. The idea of mechatronic plant modularization was already introduced as an important prerequisite for a general engineering reference model. This idea refined and a model for describing mechatronic units has been developed. This model is described in chapter 2. Additionally we will show how this model and the mechatronic approach in general will synergize with the MAS-approach of GRACE. Within the Deliverable 4.1 and the Appendix A to D4.1 general engineering activities have been described and evaluated with respect to their importance to the final product quality. Within chapter 3 of this deliverable we will also describe additional engineering activities crucial for the development of multi-agent-systems. Using all the above mentioned inputs, chapter 4 will describe the general engineering methodology for multi-agent-systems. Both chapters are part of the general engineering methodology and will result in the general engineering workflow, presented in chapter 4, which in turn will be the basis of the GRACE engineering methodology described in Appendix A (separated from this document). Chapter 5 will close this deliverable with a short summary and a classification how the so far developed concepts and approaches fit in the big picture of the engineering methodology. 14

15 2. The mechatronic approach Like stated in [Sie11] one approach to face the rising requirements within the engineering of modern facilities is to use the mechatronic plant design approach. It is therefore most important to understand the needs of each discipline and to grant each of them the capability to depose specific information. Here, the mechatronic approach is notably feasible because it combines the different perspectives of mechanics, electrics and automation to a holistic. Thus, it is not only able to illustrate the single domain specific information but also the dependencies among them. The modeling of mechatronic units is done based on the basic mechatronic system presented by [GEK01]. This system consists of two different levels: The physical layer which consists of the controlled system (often also named as process). The information layer where the collected control information is processed. On the line of both layers sensors are collecting the control information out of the controlled system/process. This information is processed and actuators are used to intervene on the process/controlled system. Note, that in some cases, e.g. when the mechatronic system represents a quality control station, the actuators may not directly influence the process but may be used for positioning of sensors etc. or may neither exist. The scheme of this system is shown in Figure 3. communication system Supply energy informationprocessing informationprocessing-unit human-machineinterface human Digital values (mainly information flow) preprocessing digital- /analogkonverter analog- /digitalkonverter adjustment / amplification analog values (mainly energy- and material flow) sensors Supply energy Supply energy actuators controlled system/ process Material flow Energy flow Information flow mandatory unit optional unit Figure 3: The mechatronic system (based on [GEK01]) 15

16 2.1. Mechatronic units Based on the general approach of mechatronic thinking the mechatronic unit thinking aroused especially in the field of factory automation [ARC10], [Thr05], [ScW07], [WHE10], [VDI 2206]. [Kie07] analyzed which data has to be presented by a mechatronic unit. Based upon this the following data should be considered: Topological data describing the hierarchy of mechatronical units and devices and giving an over how the system is structured and where are the interfaces between the system units. Process control data consisting of all control relevant information like control specifications, control code, information signals, variable declarations etc.. Mechanical data covering all typical mechanical data like 3D-CAD models and kinematics. Electrical/pneumatical and hydraulical data including interface description (mostly energy and material), wiring diagrams, pneumatical diagrams, etc.. Function describing data containing all relevant functional parameters, technological descriptions, functional models etc. This data can be divided into the description of the uncontrolled and controlled system behavior. Generic data summarizing all further data and serving as a data pool especially for non-technical (nut neither less important) data like organizational data (e.g. article codes for purchasing, equipment manufacturer, ), economic data and others (e.g. user manuals, maintenance data/ -manuals, ). The structuring of this data can be seen in Figure 4. 16

17 Mechatronic unit data topological data internal hierarchy subordinate devices interface to devices Process control data signal information PLC function blocks mechanical data 3D-CAD data kinematics electrical / pneu. / hydraulic data connections wiring diagrams pneumatic schemes Function decribing data functional models functional parameters technological descriptions generic data uncontrolled behavior controlled behavior organizational data article code manufacturer technical data economic data other data material / weight power supply expenses space needed Instruction manual Maintenance manual Maintenance data Figure 4: Information structure of mechatronic units (based on [Kie07]) Using the above mentioned information model and an object-oriented design approach the mechatronic unit can be derived from the mechatronic system presented in Figure 3. For each mechatronic unit a unique name or identifier has to be defined, ensuring that the mechatronic unit can be called, addressed and referenced in a bijective manner. Each mechatronic unit consists of the mechatronic system and a defined I/O interface. Here, each controlled system/process on the physical layer of the encapsulated mechatronic system could be again a mechatronic unit. Thus, hierarchical structuring of mechatronic units is possible at any time. Additionally there is the possibility to define s for each mechatronic unit. By doing so, the visible information of the unit can be reduced, enhancing simultaneously the clarity and usability of mechatronic units. An abstract representation of the mechatronic unit is displayed within Figure 5. The interaction between a mechatronic unit and its environment and/or other superior units is realized over its I/O-interface. At this level the interaction must not only include information exchange but also material and energy flows like shown in Figure 3 and Figure 5. They could be specified as follows: Energy flows act as an energy transfer for the purpose of power supply of the mechatronic unit or for manipulation of the controlled system/process. This energy can be transferred in different manner like electrically, hydraulically, pneumatically, heat radiation, etc. The information interfaces serve as a typical data transfer interface. They include e.g. parameter hand-over, control signals, bus interfaces, etc. 17

18 Name / ID me chat ron ic sys tem information layer digital- /analogkonver ter a dj us tm en t/ a m pli fic ati on a ctu at ors information processing information processing physical layer pr ep ro ce s ing anal og-/digitalkonver ter sensors I/O energy in f or mati on mate rial Deliverable D4.2 The material interface is a substantial part of the mechatronic unit as here the hand-over of production parts (e.g. product components and product (sub- )assemblies) can be represented. As the simple examples of the different interface types show, the type of data stored within the mechatronic unit and its amount can easily reach very high numbers and thus can be uncontrollable. To face this problem there are two tools which can be used. The first are the different s on the mechatronic unit. Like written above they serve for limiting the amount of data displayed for the user of the mechatronic unit (which can be an engineering using the unit for the engineering of a plant, but also a plant operator using an interface of mechatronic unit for controlling the production process). As a second tool it can be made use of the object-oriented approach (which the mechatronic unit is designed for). Thus, typical object-orientated procedures may be used, e.g. data encapsulation, inheritance and polymorphism. Making use of inheritance allows the engineer to specify information of a mechatronic unit and then inherit this information to subordinated mechatronic units. Thus, a production line can be detailed into e.g. its production stations. These stations are again mechatronic units with a basic set of information inherited by their parental object. This way, changes of the parental object information are automatically announced to the child objects and data consistency can be assured. Name / ID mechatronic system information layer I/O energy information processing preprocessing information digital- /analogkonverter analog- /digitalkonverter adjustment / amplification sensors actuators controlled system material physical layer electrical mechanical automation functionoriented economic e le ctr ical v ie w me cha nica l v ie w aut om atio n v ie w fu nctio n- or ien ted v ie w e con om ic v ie w Figure 5: The mechatronic unit In addition to the information integrated within a mechatronic unit the I/O-interface is of high importance as it represents all material and immaterial flows between the mechatronic unit and its environment. Like mentioned before, a hierarchical structuring of mechatronic units is a basic requirement for an efficient and successful application of the mechatronic 18

19 digital- /analogkonverter adjustment / amplification actuators adjustment/ amplification actuators Nam e ID / mechatr oni c system inf orm a tio n lay er el ec tr ic al vi e w konverteradjustment / amplification actuators Nam e ID / m e ch a ni ca l vi e w informati on pr ocesing informati on pr ocesing a u to m at io n p hy si cal la ye r vi e w mechatr oni c system inf orm a tio n lay er konv adjustm amplifi actua cation ent/ erter tors el ec tr ic al vi e w m e ch a ni ca l vi e w fu n ct io n- o rie n te d vi e w informati on pr ocesing informati on pr ocesing a u to m at io n p hy si cal la ye r e c on o m ic vi e w analog- preproc esing /digitalkonv sens an konverter alog-/digita l- sensors erter ors I/O energy i nf ormati on m at er ia l preprocessing analog- /digitalkonverter sensors preprocessing digital- /analogkonverter analog-/digitalko nv e rt er sensors Deliverable D4.2 approach. To support this hierarchical structuring of mechatronic units an interface concept was developed. It is shown in Figure 6. Superior mechatronic units / environment Name / ID mechatronic system I/O informat ion layer energy information processing information electrical controlled system physical layer mechanical automation functionoriented economic material Server / Database Control station / HMI Operator mechatronic unit Execution interface Internal interface Functions Functions Functions Internal Database Device interface Subordinate mechatronic units / equipment Name / ID mechatronic system I/O information layer energy information processing information controlled system material physical layer electrical mechanical automation functionoriented economic vi e w fu n ct io n- o rie n te d vi e w e c on o m ic vi e w I/O energy i nf ormati on m at er ia l Figure 6: Interface concept for mechatronic units The communication with superior mechatronic units and or the environment is done by using the execution interface. The functions, an eventual internal database and other internal elements of the mechatronic unit can use/can be used (by) this interface. If there is any control from a superior instance this is done by the execution interface. 19

20 The internal communication between functions, internal database and other internal components is processed via the internal interfaces. This way, variables can be exchanged between functions or can be stored in the database. Thus, the internal interface represents the whole internal communication among components of the mechatronic unit. The interaction with subordinate mechatronic units or equipment is handled by the device interface. This way functions can directly access sensors and actuators like position sensors or motors and thus, are able to perform a given functionality. In addition to the above described horizontal communication in practice there is often also a vertical communication needed. This could be the case if product assemblies are handed over from one station to the next. This kind of interaction is also done by using the execution and device interfaces. It should be noticed that the mechatronic unit which comes first in the sequential working order is interacting over its device interface with the execution interface of the following mechatronic unit Integration of GRACE MAS and mechatronic unit approach This chapter will deal with the question how the GRACE multi-agent system developed in [Ins11] and the mechatronic unit approach shown in [Sie11] and also in chapter 2.1 of this deliverable can be integrated. Also the synergetic effects and advantages will be shown. The idea of combining MAS and mechatronic units or in general combining MAS with a functional oriented/modular approach is not new and can be seen in both past and current research projects [BCB01], [IDE11], [JeW00], [GRA11], [PAB11], [Par98], [SHY06], [WGU03], [WEI01], [LeR06], [BWV98]. In the following two examples are given, showing two different approaches which, in general, seemed to be followed. Within the PABADIS PROMISE project (see [PAB08], [PAB11] and [LüF01]) the focus was set on agents as software. These agents were controlling different production resources as a kind of front-end. A methodic combination of this multiagent system with a mechatronic unit approach was only implicitly given. Within the IDEAS project (see [RBO11], [NFO11] and [IDE11]) the approaches of multi-agent systems and mechatronic units are very tightly coupled by defining mechatronic agents consisting of software and hardware. Both approaches try to deal with the rising complexity of manufacturing lines and the simultaneously rising demands regarding flexibility and adaptability. Trying to apply one of these approaches on the GRACE multi-agent system leads to particular problems. To highlight them, Figure 7 gives a recap over of the MAS developed in [Ins11]. 20

21 Figure 7: UML Class Diagram for GRACE Agent Classes (following [Ins11]) Following the PABADIS PROMISE (P2) approach agents are software entities. They are implemented on an industrial PC or PLC and are organizing the production. Thus, some of these agents also need to interact with the hardware (e.g. production station). For the P2- approach there are several production resources which are not hierarchically organized. Each of this production stations is controlled by an agent and in addition agents might also use other production stations they need to fulfill their goals. Looking at the GRACE MAS architecture this approach is feasible to describe all agents. But when it comes to the resource agents of GRACE, then there is a difference to P2. Within GRACE project resources are not structured in a horizontal flat manner, but are vertically and horizontally structured. E.g. the bearing insertion station is a module. But looking one level deeper inside, the bearing insertion station consists of three sub-modules: 1. The rear tub thickness control 2. The A-bearing insertion 3. The B-bearing insertion These sub-modules can be further detailed within like the bearing feeding and the bearing insertion itself. Just taking this simple example it becomes clear, that production resources are not hierarchically flat. Indeed the structuring in vertical manner improves flexibility of a production resource. If Whirlpool decides to change the supplier of bearing, this might also mean changing the bearing feeding. Following the P2 approach this would mean changing the agent of the whole production resource. But with a more detailed structuring it could also mean to change the feeding module. If this module is then also 21

22 controlled by a separate agent this would lead to the fact that not the whole production resource has to be changed, but only the feeding module, as the agent of this module is able to adapt itself to its environment. Thus it has to be said that using the P2-approach is not suitable to combine with the modularization approach used with the GRACE project. Another approach out of the current research activities is the mechatronic agent approach of the IDEAS project. Here, every agent consists of a software (control) part and a hardware part. Thus, every agent is in some kind represented in the physical world. This approach and also the shown structuring approach is very similar compared to the GRACE ideas. Never the less within the GRACE MAS architecture there are some agents which are not typically physical existing. The IMA and the PTA are both agents existing only as software on a PC, PLC or something like that. So it can be argued that they are a kind of special version of a mechatronic agent with no physical hardware, they are no typical IDEAS mechatronic agents. The goal of this deliverable is to present an engineering methodology suitable for the engineering of multi-agent systems. Keeping that in mind it is not said, that this methodology is only applicable for the GRACE MAS architecture, but quite contrary the goal should be a methodology reasonable to exploit a high number of different MAS architectures. Following this idea, we developed an integration scenario where all extremes of integration between agents and physical modules are covered: Only agents are considered within the MAS engineering, physical modules (e.g. production resources) are not in focus (like P2). Both agents and physical modules are considered, but not integrated. Agents and physical modules are fully integrated (like IDEAS). The basis for the integration of agents and mechatronic units is a clearly defined structure of both of them. It is highly important that the interaction of the modules over their interfaces is precisely defined. This is also one of the reasons why this topic was not only stressed within [Ins11] but also in chapter 2.1 of this deliverable. Using these interface definitions, the engineer is able to precisely intersect the modules of a production system and to guarantee an interaction between these modules by not intersecting through one module and thus cutting communication or other interfaces. The integration of agents and mechatronic units is done by encapsulating modules according to their functions. This simply means that a module is not per se defined as the sum of a mechatronic unit and an agent. For the IMA s and PTA s of GRACE MAS a module is congruent to an agent (see [Ins11]). The GRACE resource agents however are not congruent to a module. Instead they are integrated into the mechatronic unit of the controlled resource and serve there as the information processing of the mechatronic unit. The module here is congruent to mechatronic unit with its integrated RA. The third scenario is a module which is congruent to a mechatronic unit (but without an agent). This scenario is given primarily on the lower levels of the production line where the control part is not very complex (e.g. just consisting of one standard function block for 22

23 position control). To keep the complexity of an agent system low these simple automation functions without any intelligence in the direction of self-organization, self-optimization and/or adaptation are not modeled as an agent. Following these three scenarios also three according modules can be identified: 1. Mechatronic units, are defined following chapter 2.1. They are physical objects with an information processing part which is NOT an agent, and thus, NOT selfoptimizing, self, organizing and/or adapting. (e.g. a robot which is only capable of performing move position xyz instructions) 2. Stand-alone agents, are defined following [Ins11]. They are software objects and do not DIRECTLY control any hardware. (e.g. GRACE independent meta agent or product type agent) 3. Integrated agents, are mechatronic units with an agent as information processing part. The agent is directly controlling the hardware of the mechatronic unit to achieve self-optimization, self, organization and/or adaptation. (e.g. the bearing insertion station controlled, organized and optimized by a GRACE resource agent and for itself also being a mechatronic unit) The first two modules are well defined within the specified documents. The integrated agent is a combination of the first two module-types. Thus, Figure 8 shows how both entities agent and mechatronic unit communicate in an integrated scenario. The outer shell is established by the mechatronic unit. Every communication with the environment is processed via the execution and device interfaces. The agent is an encapsulated part inside of the mechatronic unit. Its inter-agent communication interface and the GUI are directly connected to the execution interface. The inter-agent communication interface is additionally connected to the device interface, which can also be used by the physical or legacy system interface of the agent. Despite these outside communications, the GUI and especially the internal behavior of the agent can directly use the internal interfaces of the mechatronic unit to gain access to the database, other agents or other information processing objects within the mechatronic unit. 23

24 digi tal - /analogkonver ter adj ust ment / am plif icati on act uator s information layer physical layer digi tal - /analogkonver ter adj ust ment / am plif icati on act uator s Na me / ID m ech atr on ics yst em inf orma tion laye r i nfo rma tio np roc es ing amplific actua ation tors analog konv se erter nsors / digital- i nfo rma tio np roc es ing p hysi cal ayer ele ctr ica l m ec ha nic al aut om atio n fu nct ionor ien ted eco no mic I/O en erg y in for ma tio n ma ter ial prepr ocessing analog- / digit alkonver ter sensors in fo rmation layer ph ysical layer N am e/ ID m ec hat ron ics ys tem in form atio nla yer info rm atio pn ro ces sin g konve adjustm amplific ation ent/ rter actua tors info rm atio pn ro ces sin g phys ical laye r ele ctr ica l m ec ha nic al aut om atio n Deliverable D4.2 Na me / ID mechatronic system I/O energy information processing information controlled system material Integrated agent Stand-alone agent mechatronic unit Server / Database Control station / HMI Human mechatronic unit Execution interface GRACE Agent GUI electrical mechanical automation fu nct ionor ien ted functionoriented economic eco no mic erter nsors / digital- analog konv se prepr ocessing analog- / digit alkonver ter sensors internal behaviour Internal Database Internal interface inter-agent communication... Adaptation function Dispatching function Monitoring function Physical or legecy systems interfaces Device interface Name / ID mechatronic system I/O energy information processing information controlled system material electrical mechanical automation functionoriented economic I/O en erg y in for ma tio n ma ter ial Integrated agent Stand-alone agent mechatronic unit Production resource Production resource Figure 8: GRACE Agent integrated into mechatronic unit (integrated agent) The use of the above mentioned approach promises some advantages and also the possibility to generate synergetic effects between MAS and mechatronic thinking. As can be seen in chapter the identification of agents can be simplified by using the mechatronic modularization structure of a plant. Within Appendix A to this deliverable we will provide a methodology to identify modules of a production line or even of a factory. Using this approach the mechatronic units of a plant are identified. In a second step the integrated agents are identified by analyzing the intelligence of the units. If there is a typical agent needed due to adaptation, optimization and/or organization needs, then the mechatronic unit becomes an integrated agent (MU + Agent). If not then it stays as a mechatronic unit with a simple information processing part. Thus, two module types can be identified by using one identification method and then utilizing the synergies between MAS- and MU-approach. This also leads to the fact that the modularization is done in a way, that for the overall factory always the same modules are identified. Modularizing agents and mechatronic units independently could lead to two 24

25 different intersections of the plant as for both processes not necessarily the same approaches or conditions have to be used. This would also mean that an independent modularization leads to potential inconsistencies within the plant design. As the modularization is done in the beginning of the engineering, these inconsistencies would lead to high NC-costs (Non-Conformance-costs). Keeping this fact in mind it becomes even more meaningful to exploit the synergies between the two approaches and also to use them for a consistent and coherent module hierarchy. The possibility to do that is also owed to the fact, that all mentioned approaches (MAS, MU, HMS) are based on a quite similar functional approach Synergies of the integrated approach One general advantage of the introduced method is that it is applicable not only for GRACE multi-agent systems, but also for others. As long as agents and or hardware modules (like mechatronic units) are clearly encapsulated and every communication is processed via defined interfaces the integration can be done as described above. This also enables the use of our engineering methodology for Systems like they were developed in P2. Here, the P2- agents can be encapsulated as stand-alone agents and the production resources can be seen as encapsulated mechatronic units. Thus, all principles of the P2 methodology can be used without any restrictions. In fact also the possibility to define P2-resource agents as integrated agents on a product instance is given. Trying to apply the GRACE engineering method on the IDEAS project (MAS) or the ADACOR project (HMS) this would mean that the mechatronic agents/holons are defined as integrated agents in a sense of this deliverable. Thus, the methodic approach of IDEAS is usable and can be supported by GRACE engineering methodology. Comparing the three module types of chapter 2.2 with the holonic manunfacturing system approach used by ADACOR [LeR06] or PROSA [BWV98] there are several similarities to be found. So it is possible to map the different holon types to the above mentioned modules. A Holon, as defined within [GiB05] is an autonomous and cooperative building block of a manufacturing system for transforming, transporting, storing and/or validating information and physical objects. The holon consists of an information processing part and often a physical processing part. A holon can be part of another holon. Thus, every of the above mentioned modules may also be a holon. The difference here is, that the integrated approach tries to combine both approaches and therefore both motivations of holonic manufacturing systems (motivated by flexible manufacturing tasks) and multi-agent-systems (motivated by programming of distributed entities) [GiB04]. Hence, the integrated approach of mechatronic thinking and MAS is quite similar to the holonic manufacturing system approach but with a less strict integration of MAS (information processing part) and MU (physical part). The advantage of using the above presented approach lies within its flexibility. Thus, it is possible to use the approach for all three types of manufacturing system approaches: mechatronic systems, multi-agents systems and holonic systems. 25

26 Taking these examples and also taking into account the applicability for the GRACE MAS it becomes visible, that the GRACE engineering methodology is not only developed for this specific research project, but for a broad range of MAS, HMS and mechatronic systems engineering. Hence, all basic principles presented within this deliverable are broadly applicable and might serve as a kind of red line throughout the engineering project. Never the less Appendix A will provide a specification of this engineering methodology, taking into account the domain specifics of consumer good production. Here it will be shown how the general methodology can be customized for a specific domain or even OEM. Another advantage of the integration approach is that the change of functionalities is simplified. Thus, adding software functionality can be done by exchanging just the agentpart of an integrated agent. Another example can be given by a robot. Let s assume a standard six-axis robot is used to assemble a motor on a product. Then the type of motor is changed due to some reason (change of supplier, change of motor characteristics for better product quality, ). The new motor has to be assembled in a similar way but with another effector. Using the introduced approach it is possible to modularize the robot as a robot itself and a mounted module effector. Thus, only the effector module has to be changed by installing a new one and adjusting the agent. This also means that the communication and interfacing has to be only changed within the module six-axis robot. To the environment it looks still the same and no further integration activities are needed. Beside these synergies and advantages (see also [WHE10], [WSE08] and [Ins11]) which are accomplished based on the chosen integration approach, all advantages of MAS, HMS and Mechatronics may also be utilized (depending on the characteristics of the implemented module intelligence): Efficiency, e.g. implementation of re-routing mechanisms in job production systems. Extensibility, e.g. by raising the possibilities to exchange, add or remove modules from the production system and in parallel minimizing the adaptation efforts due to automatic adaptation or fixed interfaces. Flexibility, e.g. using re-routing or scheduling algorithms or exploiting modular structuring and defined interfaces for system adjustments. Maintainability, by using higher level descriptions of behavior instead of behavior on code level. Reliability, by enabling local troubleshooting due to modular structuring and by enabling reuse of tested and proven modules. Responsiveness, e.g. using mechatronic unit modules with control code on [IEC 61131] level to ensure system compliance with real-time requirements and in parallel establishing a higher level distributed control structure with integrated agents or stand-alone agents improving the response to changes. Reuse, e.g. by exploiting standardized modules/mechatronic units and interfaces enabling a common semantic and understanding among modules/mus 26

27 Robustness, e.g. overcoming bottleneck performance problems by distributing control functions over a network of interconnected agents 27

28 3. Engineering activities Within chapter 4.4 of [Sie11] a description of generic engineering activities was already given. The aim of this chapter is to extend the list of engineering activities. Chapter 3.1 will therefore add activities from a MAS perspective, while chapter 3.2 will add additional general engineering activities. Thus, the basic activities for the GRACE engineering methodology can be provided. To improve readability and comparability among the different activities, the following template was used for activity description. Name Description Application cases Engineering phases Short name of the activity (status new/changed in terms of [Sie11]) Short textual or key word description of the corresponding activity Special engineering action usually exploiting this activity Naming of the engineering phases where the activity is used 3.1. MAS engineering activities Identification of mechatronic units Name Description Application cases Identification of mechatronic units (new) Gathering of domain information and identification of mechatronic units as an aggregation of several requirements belonging to a defined set of system(sub)functionalities Structuring of the facility into different layers (e.g. cell, main groups, function groups, ) Function-oriented approach to develop a functional model of the production steps Differentiation between complex functions, basic functions, help functions For further description of the module identification process see Appendix A Manufacturing system structuring Device structure definition Hierarchy definition Reuse of engineering results 28

29 Engineering phases Specification of manufacturing system capabilities Development of mechatronic units o Identification o Analysis and modeling Engineering project o Process Planning o Basic Engineering Identification of integrated agents Name Description Application cases Identification of integrated agents (new) Following the chapter 2, each mechatronic unit might be controlled by an agent Agents can be identified using results of activity Identification of mechatronic units For each unit an appropriate agent can be identified For GRACE MAS these are typically all types of Resource agents (machine agent, quality control agent, transport agent and operator agent) see [Ins11] o This may vary if other MAS-architectures are used The existence of a controlled behavior is a necessary but not sufficient condition for the identification of agents o If there is a controlled behavior, then there might be an agent o If the controlled behavior is simple, e.g. function block of a single motor, then no agent might be identified as it is just a dumb piece of control code o Agents can be characterized by an adaptive, (self-) optimizing and/or (self-)organizing behavior o This condition aims to keep complexity and amount of agents low, as agents are only identified for complex behavior. A mechatronic unit like a motor is one, can, in theory, also be controlled by an agent. That would lead to the fact, that for each actuator/sensor at least one agent is identified (thus leading to exponential growth of the MAS). Manufacturing system structuring 29

30 Engineering phases Hierarchy definition Reuse of engineering results Specification of manufacturing system capabilities Development of mechatronic units o Identification o Analysis and modeling Engineering project o Process Planning o Basic Engineering Identification of stand-alone agents Name Description Application cases Engineering phases Identification of stand-alone agents (new) In addition to the integrated agents which are directly connected to a mechatronic unit there might also be stand-alone agents Stand-alone agents are not directly connected to a physical device Stand-alone agents cooperate with other agents They can be identified using the MAS architecture: o E.g within GRACE MAS PTAs, PAs and IMAs are not directly connected to physical devices o No generic way to identify those agents o Identification can be supported by analyzing MAS requirements, see [Ins10] Manufacturing system structuring Hierarchy definition Reuse of engineering results Specification of manufacturing system capabilities Development of mechatronic units o Identification o Analysis and modeling Engineering project o Process Planning o Basic Engineering 30

31 Derivation of a System architecture Name Description Application cases Engineering phases Derivation of a System architecture (new) System architecture represents the basic solution for fulfillment of requirements Multiple solutions might be discussed and decision (incl. reasons) why, which solution was chosen is documented Defines hierarchical structure of the system Modules (mechatronic units) are treated as black boxes and are detailed within following steps Defines interfaces between the mechatronic units Defines black-box behavior of the system and modules System architecture might also define general boundary conditions (e.g. safety levels etc.) Decomposition of manufacturing system Tracing of requirements Specification of manufacturing system capabilities Definition of necessary module characteristics Parallel and distributed engineering Development of mechatronic units o Analysis and modeling o Realization Engineering project o Process Planning o Basic Engineering o Detailed Engineering o Commissioning Instantiation Name Description Instantiation (changed) Instantiation is the process of applying templates to get real existing plant components After the instantiation the templates have to be concretized with respect to: o Setting up all parameters 31

32 Application cases Engineering phases o Choosing the right variant/version o Adding additional information to fit the standard template to the current plant design The goal of instantiation is to reduce time and simultaneously improve the overall quality of the engineering by reusing tested structures Use of template libraries within plant planning to define the plant structure Use of templates within the process of device structure definition and implementation Development of mechatronic units o Analysis and modeling o Realization Engineering project o Process Planning o Basic Engineering o Detailed Engineering Implementation Name Description Application cases Engineering phases Implementation (new) previously instantiated templates are detailed instantiated templates (agents and mechatronic units) will most likely never fit project specific needs to 100 percent Adaption, organization and optimization of instantiated agents and mechatronic units are needed Interfaces have to be adjusted to ensure right communication among agents and mechatronic units Provision of specific information for engineering disciplines Specification of manufacturing system capabilities Development of mechatronic units o Analysis and modeling o Realization Engineering project o Basic Engineering o Detailed Engineering o Commissioning 32

33 Module tests Name Description Application cases Engineering phases Module tests (new) Testing of single agents and mechatronic units if they are fit for use Test is done as a white-box test, so that also the internal behavior could be verified Test cases have to be independent from each other Test is done by using the predefined interface of agents and mechatronic units to avoid module interaction failures Module test is done to improve integration of modules and integration tests Different standards for module testing can be used e.g. [Sof09], [Bin00] Acceptance tests based on paper/digital information Engineering project management and quality control Acceptance test preparation Behavior simulation Virtual commissioning Development of mechatronic units o Realization Engineering project o Detailed Engineering o Commissioning Integration Name Description Integration (new) Aggregating/linking all single modules into one system in order to ensure the system functionalities Connecting module interfaces (information interface as well as material and energy interfaces) Using different integration methods, see [GoR07] o Vertical integration o Horizontal integration o Star integration 33

34 Application cases Engineering phases o Common data format/semantics (e.g. ontologies) Composition of manufacturing system Specification of manufacturing system capabilities Use of templates within the process of device structure definition and implementation Development of mechatronic units o Realization Engineering project o Detailed Engineering o Commissioning Integration test Name Description Application cases Engineering phases Integration test (new) Combination of modules is tested Based on module tests Verifying requirements fulfillment (functional, quality, etc.) Is done by a black-box test only using interfaces of modules Prevents unexpected behavior especially when using intelligent, adaptive self-optimizing and/or self-organizing modules like agents and mechatronic units Different testing techniques like top-down, bottom-up or big-bang can be used e.g. [Bei90], [Bin00] Acceptance tests based on paper/digital information Engineering project management and quality control Acceptance test preparation Behavior simulation Virtual commissioning Development of mechatronic units o Realization Engineering project o Commissioning 34

35 3.2. Additional general engineering activities Project management Name Description Application cases Engineering phases Project management (new) Managing (planning, organizing, securing) resources to successfully process a specific project Each Project is underlying typical constraints: o Scope o Time o budget traditionally distinguished between five stages [Pro08]: o initiation o planning o execution o monitoring & controlling o closing covering nine basic knowledge areas [Pro08]: o Project Integration Management o Project Scope Management o Project Time Management o Project Cost Management o Project Quality Management o Project Human Resource Management o Project Communications Management o Project Risk Management o Project Procurement Management Project spanning activities Development of mechatronic units o Identification o Analysis and modeling o Realization Engineering project o Process Planning 35

36 o Basic Engineering o Detailed Engineering o Realization & Commissioning Procurement Name Description Application cases Engineering phases Procurement (new) Goal is to ensure that all resources needed for the project execution are available at the right time, at the right place in the right quality and quantity Consists of the following seven steps o Information gathering o Supplier contact o Background re o Negotiations o Fulfillment o Consumption, maintenance, disposal o Renewal o Tender notification Project spanning activities Development of mechatronic units o Analysis and modeling o Realization Engineering project o Basic Engineering o Detailed Engineering o Realization & Commissioning 36

37 4. Engineering workflow This chapter will summarize the activities presented in [Sie11] and this deliverable and will describe the resulting workflow. This workflow as one major part of the engineering methodology was developed based on the general engineering process reference model presented in [Sie11]. It can be divided into two sub-processes. The process development of mechatronic units was renamed to development of modules just to avoid wording conflicts. Never the less its purpose is to develop reusable artifacts (modules) and to store them in a module library for reusing them within the engineering projects. The development process starts with the identification of reusable modules. Here different projects are taken as an input to first identify which are the modules of a plant and then to elaborate their reusability potential. Thus, also a current project may be input for the Identification. A methodology to perform this identification process will be shown in detail within Appendix A to this deliverable. The outcome of these activities is a list of reusable modules. This list is the main input for the second phase analysis of the development process. Here the modules are analyzed regarding the requirements related to them and regarding to their structure. Therefore, the requirements and the module itself are decomposed/composed, resulting in a requirements specification and in an internal module hierarchy. These documents or models are also the basic inputs for the third development phase, named modeling. Here, the templates and variants for/of the module are developed. Based on these templates and variants and also taking into account the internal hierarchy as a basis and adjusting the modules regarding to their requirements, the modules are implemented, resulting in a module model with a certain abstraction level to obtain engineering tool independency and reusability within multiple projects. The last engineering phase realization takes this module model as an input for a second implementation step. Here, the model is implemented as an engineering artifact (module) within a specific engineering tool. This tool specific implementation is done in a way that the module is still reusable within different engineering projects. After the engineering artifact is finished it is tested. Here a module test includes simulation/execution of the module behavior and also requirements driven test. After all tests are successfully performed, all requirements are traced for fulfillment, resulting in an acceptance of the module as an engineering artifact. With this acceptance, the module is stored into the library of reusable objects and then can be used within the engineering projects. This development process of modules is shown in the lower part of Figure 9 to Figure 12. The second sub-process within the general engineering process reference model is the sub-process for the engineering projects. It starts with process planning phase and herein the definition and decomposition of requirements. This requirement specification is then used as a basis for the plant modularization. First the plant is composed and decomposed to obtain a plant hierarchy which is then used for the identification of modules (agents + 37

38 mechatronic units). Again this identification approach is specified within Appendix A. The main outputs of this phase are the requirements specification and the modularized plant hierarchy. Within the second phase basic engineering these outputs are used to select modules of the library for reusing them. If all modules needed are already deposited in the library then the system concept and the system architecture can be easily created. If not all modules are available, the module development process has to be started. Here it may also be possible that not every needed module of a single project is evaluated as reusable, resulting in a cancelation of the module development process. If this case occurs the modules have to be developed later in the engineering project. Thus, the derived system concept and architecture also contain information about which modules could be instantiated and which have to be manually implemented. The instantiation of the reusable modules is done first. Then the different s and working layers on/for the system are generated. This is done in a discipline specific manner. Thus the main result of the second engineering phase is a system architecture with instantiated general modules and different s and working layers for each engineering discipline (mechanics, electrics, hydraulics, automation, ). The next phase detailed design starts with the domain specific implementation of the modules. Here the instantiated modules are refined and modules which are project specific and thus not reusable are created. Besides not every part of the plant might be also part of a specific module. These plant components are also refined in parallel to the implementation activity. The result of both activities is a detailed module/component specification. These single modules are then tested. This includes, like every test, a requirement driven test as well as a simulation/execution of the module behavior. When all tests are passed this lead to a first acceptance of the module drawings. Afterwards the modules and components are integrated into the overall plant which is then undergoing an integration test. The final result of the detailed design is a tested detailed system specification of the plant taking into account the information of every involved discipline. This is the starting point for the last project phase realization & commissioning. The phase starts with the testing of the physical modules and components delivered by the suppliers out of the procurement activity (see below). Here the real modules are tested by simulation and/or behavior execution. Additionally the compliance of the module with its requirements is verified. If all modules are accepted they are physically integrated into the real plant, resulting in the real working plant. The final step of the engineering process is the final integration test (also called FAT) of the plant. Here, every part of the plant is checked, the behavior is executed and tested and the fulfillment of all requirements is traced. When all tests are successfully passed the plant is accepted and handed over to the customer. This process for the engineering projects is shown in the middle of Figure 9 to Figure 12. Within both sub-processes development of reusable modules and engineering project there are additional project spanning activities not mentioned before. These are shown in the upper part of Figure 9 to Figure 12. The activities project management, consistency management, change management and user guidance are interacting and influencing practically every single activity of both sub-processes. They are generating timetables, 38

39 project milestones, employee trainings, configuration management, change reports and validations, manuals, guidelines, documentations and many more. For details please see the according activity descriptions above and within [Sie11]. The last project spanning activity is the procurement which is primary interacting with the engineering project sub-process. The procurement activity covers every action needed starting from the specification documents and resulting in the handover/acceptance of equipment, components, modules, etc. The detailed interactions of this particular activity can be seen in Figure 9 to Figure 12. Thus, the whole engineering workflow starting from the identification of reusable modules, over the storing and reusing of modules in and out of libraries right up to the final handover of the plant is shown. REMARK: Due to the size of the graphical representation of the engineering workflow Figure 9 to Figure 12 are also available as one separate.png file attached to this document. 39

40 Figure 9: GRACE engineering workflow model Phase 1 40

41 Figure 10: GRACE engineering workflow model Phase 2 41

42 Figure 11: GRACE engineering workflow model Phase 3 42

43 Figure 12: GRACE engineering workflow model Phase 4 43

44 5. Conclusion The approaches presented within this paper will supplement the engineering methodology. For the complete understanding it is crucial to understand, that the engineering methodology is not just one monolithic piece. Instead the methodology is a big picture that accrues by putting a lot of puzzle pieces together. Some basic models on which the engineering methodology is based on are the MAS-approach and the according GRACE MAS architecture presented in [Ins11], the mechatronic unit approach presented in [Sie11] and finalized within chapter 2 of this deliverable the engineering process reference model and the engineering process metamodel presented in [Sie11] the basic engineering activities presented in [Sie11], [Sie11] Appendix A and in chapter 3 of this deliverable, and the House of Quality presented in [Sie11]. The subsumption of these approaches and findings builds the foundation for the whole engineering methodology. This deliverable completed the foundation by adding the last MAS-related engineering activities. Utilizing these basic input models comes the next level within the engineering methodology. These are the central methodology models. The general MAS engineering workflow model with its phases and sub-processes was presented within chapter 4 of this deliverable, using the MAS approach, the MU approach, the general engineering process reference model and the engineering activities as a basic input, describing the interrelations among these concepts and resulting in a general workflow model for MAS engineering. In addition to this workflow model there will be a Material-Process-Function-Quality Model (MPFQ model), based on the House of Quality, the engineering activities and the engineering process reference model. A first version of this model was already used by SIEMENS within the common workshop with Whirlpool to identify crucial engineering activities from a quality point of and to work out the dependencies between the final product quality (e.g. of a washing machine) and the engineering of the manufacturing line. This model (already presented in [Sie11] and [FLW11]) will be combined with the MPF model presented by Whirlpool during the Technical Meeting in Trondheim to form a consistent dependency model. This will be done within Appendix A to this deliverable. On top of these central models are some extended usages of the methodology. The synergies between the mechatronic unit approach and the MAS-approach were already highlighted within chapter 2 of this deliverable. Within Appendix A to this deliverable we will give also some approaches for the identification of reusable modules, the prediction of quality influences within the engineering and also an OEM specific workflow containing confidential information from 44

45 Whirlpool. Thus, Appendix A will complete the big picture of the GRACE engineering methodology. Finally Figure 13 will give an over how the above mentioned puzzle pieces fit together, forming the GRACE Engineering methodology Engineering methodology Extended usage of methodology Synergies between MU & MAS Identification of reusable modules OEM specific Workflow Model Quality influence prediction Central models General MAS engineering Workflow Model Phases Sub-processes MPFQ Model Basic models Multi agent system approach & architecture Mechatronic unit approach Engineering process reference model Engineering activities Quality related MAS related House of Quality Key (described in document): Deliverable 4.1 Deliverable 4.2 Deliverable 1.2 Deliverable 4.1 Appendix A Deliverable 4.2 Appendix A Figure 13: Engineering methodology framework 45