document defining the engineering process reference...

inteGration of pRocess and quAlity Control using multi-agEnt technology

Document defining the engineering process reference model

Deliverable D4.1

Engineering methodology

Work Package 4

: Deliverable 4.1 – Document defining the enginnering process reference model_v1.0.pdf

File Name

: SIEMENS Author(s)

Public : Classification

29/03/2011 : Document Preparation Date

Final : Document version

Deliverable : Document type

www.grace‐project.org : Website

36 months : Project Duration

01/07/2010 : Project Start Date

246203 : Project Ref. Number

Project funded by the European Commission under the “Seventh Framework Programme” (2007-2013)

Contract n° NMP2-SL-2010-246203

Deliverable D4.1 Document defining the engineering process reference model

Rev. Content Resp. Partner Date 0.1 Document structure and preliminary

description of engineering processes SIEMENS 14/02/2011

0.2 Preliminary description of mechatronic plant modularization

SIEMENS 22/02/2011

0.3 Description of general engineering process reference model

SIEMENS 24/02/2011

0.4 Harmonization of contributions SIEMENS 07/03/2011 0.5 Internal revision SIEMENS SIEMENS 17/03/2011 0.6 Adding Glossary and internal revision SIEMENS 19/03/2011 0.8 Revision SIEMENS 21/03/2011 0.9 Draft of Deliverable available to all partners

for review ALL 22/03/2011

1.0 Include review comments and prepare submission

SIEMENS 29/03/2011

2


Table of contents

Table of contents........................................................................................................................ 3

Table of figures........................................................................................................................... 5

Glossary ...................................................................................................................................... 6

1. Introduction........................................................................................................................ 9

2. Mechatronic plant design ................................................................................................ 12

2.1. Introduction to mechatronic plant design ........................................................... 12

2.2. Concept of mechatronic plant design .................................................................. 13

3. Engineering Processes for industrial facilities.................................................................. 16

3.1. Engineering process of VDI Guideline 5200......................................................... 16

3.2. AutomationML engineering process.................................................................... 17

3.3. Engineering process of Schnieder ........................................................................ 18

3.4. Engineering process of Kiefer............................................................................... 19

3.5. PABADIS’PROMISE engineering process .............................................................. 19

3.6. MEDEIA engineering process ............................................................................... 20

3.7. AQUIMO engineering process.............................................................................. 21

3.8. Domain engineering ............................................................................................. 21




4. General engineering process reference model................................................................ 26

4.1. Meta‐model for engineering processes ............................................................... 26

4.2. Engineering processes.......................................................................................... 27

4.3. Engineering phases .............................................................................................. 28

4.3.1. Development of mechatronic units ........................................................................ 28

4.3.2. Engineering project................................................................................................. 29

4.4. Generic Engineering activities.............................................................................. 31

4.4.1. Decomposition of the plant / plant components ................................................... 31

3


4.4.2. Composition of Plant components ......................................................................... 32

4.4.3. Refinement of Plant components........................................................................... 33

4.4.4. Variants Development ............................................................................................ 33

4.4.5. Template Development .......................................................................................... 34

4.4.6. Instantiation............................................................................................................ 34

4.4.7. Flexible View Generation........................................................................................ 35

4.4.8. Layer Generation .................................................................................................... 36

4.4.9. Definition of Requirements .................................................................................... 36

4.4.10. Decomposition of Requirements........................................................................ 37

4.4.11. Requirement driven Test and Validation............................................................ 38

4.4.12. Consistency Management .................................................................................. 39

4.4.13. Selection of Plant components Based on Requirements ................................... 40

4.4.14. Simulation / Execution of Behaviour Model....................................................... 40

4.4.15. Plant component Library Management ............................................................. 41

4.4.16. User Guidance within the Engineering Process.................................................. 42

4.4.17. Change Management ......................................................................................... 43

4.4.18. Requirement Fulfillment Tracing........................................................................ 44

4.5. Technical Engineering activities ........................................................................... 44

5. Interrelation model of product quality and engineering process.................................... 47

5.1. Derivation of the interrelation model.................................................................. 47

5.2. Integrated meta‐model for engineering, product properties and product quality.

.............................................................................................................................. 52

References................................................................................................................................ 54

Appendix A – GRACE engineering process reference model ................................................... 57

4


Table of figures

Figure 1: Relations between Engineering process and engineering artefacts........................... 8

Figure 2: Intention and goals of GRACE WP 4............................................................................ 9

Figure 3: Discipline specific modularization............................................................................. 13

Figure 4: Mechatronic modularization..................................................................................... 14

Figure 5: Counter weight screwing station .............................................................................. 14

Figure 6: Modularized production system............................................................................... 15

Figure 7: Engineering process of VDI Guideline 5200.............................................................. 17

Figure 8: AutomationML reference engineering process ........................................................ 18

Figure 9: Engineering process of Schnieder ............................................................................. 18

Figure 10: Engineering process of Kiefer.................................................................................. 19

Figure 11: PABADIS'PROMISE engineering process ................................................................. 20

Figure 12: MEDEIA engineering process .................................................................................. 21

Figure 13: AQUIMO engineering process................................................................................. 21

Figure 14: Domain engineering process................................................................................... 22

Figure 15: Engineering process of VDI Guideline 2206............................................................ 23



Figure 18: Meta‐model for structural and attributive features of engineering activities. ...... 26

Figure 19: Overview: General engineering process reference model ..................................... 28

Figure 20: Engineering defining the manufacturing system.................................................... 48

Figure 21: Manufacturing system influencing the product properties.................................... 49

Figure 22: Cause‐Effect‐Chain for the production process...................................................... 49

Figure 23: Product properties defining the product quality .................................................... 50

Figure 24: House of Quality [SKC02] ........................................................................................ 51

Figure 25: causal chain for engineering influencing product quality....................................... 52

Figure 26: Meta‐model for engineering and product quality .................................................. 53

5


Glossary

The following section defines the understanding and uses of different terms within this whitepaper.

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.

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

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.

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.

6


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) behaviour 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 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.

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 behaviour 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.

7


Figure 1: Relations between Engineering process and engineering artefacts

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 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.

Engineering tool ‐ An engineering tool is a software system designed to model, process, and store plant components or facets within an engineering process.

8


1. Introduction

The Deliverable 4.1 is the first 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 behaviour modeling for control application and overall behaviour analysis.

Identify impact of GRACE control concepts on manufacturing engineering activitiesCreate suitable and effective engineering concepts for decentralized automationRender them applicable for industrial applications

Main Objective: A new engineering methodology for decentralized manufacturing control systems based on the GRACE MAS platform

Figure 2: Intention and goals of GRACE WP 4

9


Subject of task 4.1 is the definition of a general engineering process reference model for manufacturing systems, which is developed and evaluated in domains like automotive production lines and its adaptation/extension towards a detailed GRACE specific engineering process for home appliance production lines including process and quality control. The creation of such a model is done

• by dissecting the engineering of the production line in its phases,

• by decomposition of the working processes (e.g., layout planning) within the individual phases into individual activities and

• by identification of their relations, and influences (causes and effects) with system properties of the process & quality control system.

This deliverable will be divided in two parts. The intention is to develop the engineering process in two sequential steps.

The first step will be the definition of a general engineering process reference model, 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.

The second step includes a domain and potentially also OEM specific detailing of the general engineering process reference model, containing

• Analysis of Whirlpool factory of washing machines: process, production line structure, equipment, process and quality control functions

• Analysis of engineering workflows for home appliance production lines using Whirlpool factory example or similar examples in the same domain (using expert interviews and documentation)

• Structured collection of critical factors in engineering based on an existing standardized criteria catalogue

• Integration of analysis results to engineering process reference model for home appliance production line

Results of step 2 will be given in Appendix A to this paper. Within the GRACE project this detailed model will serve as the GRACE engineering process reference model and will therefore only be available to the project partners due to confidentiality of Whirlpool specific information.

With the help of this bisection GRACE project will provide a sort of public red line for engineering processes including a basic set of disciplines and tasks which have to be considered. Never the less we are also aware that there will be no engineering reference process applicable for all domains. Therefore the general process could be modified to fit the specific target domain.

This document is structured as follows. An important prerequisite for a general engineering reference model is the idea of mechatronic plant modularization which is described in chapter 2. To understand current engineering processes in factory automation

10


chapter 3 will present a rough overview of multiple actual engineering processes also using the before mentioned mechatronic principles.

Both chapters will result in the general engineering process reference model, presented in chapter 4, which in turn will be the basis of the GRACE engineering process reference model described in Appendix A (separated from this document).

Chapter 5 will close this paper with an explanation of the importance of the developed engineering process reference model to the GRACE Project.

11


2. Mechatronic plant design

2.1. Introduction to mechatronic plant design

To reduce the engineering cost, simultaneously increasing the flexibility of manufacturing cells and additionally obtain a high product quality several research activities in the last few years have developed similar structuring models for plant design data. The home entertainment industry has developed the KOALA concept [OLK00] for modular electronic consumer goods. Research projects like MEDEIA [MED10], PABADIS’PROMISE [WHE10], AQUIMO [AQU10b] and The Internet of Things [Elg07] have introduced the combined approaches of

• Mechatronic engineering to improve interdisciplinary working processes and design data handling

• Mechatronic plant modularization to improve standardization and reusability of engineering artefacts

All abovementioned research activities specified structural objects as a basis for the system implementation. Following [Kie07] and [Foe10] these objects could be described as mechatronic units. For a common understanding of the wording and semantics of mechatronic units see [LHF10].

Based on the concept of mechatronic units, appropriate Computer Aided Design and Engineering tools (CAD/CAE ‐ tools) together with libraries of pre‐designed engineering artefacts can support the complete design process and information handling of a (production) system. The positive effect by using and re‐using mechatronic objects was examined multiple times now. Examples for the benefits that could be achieved by using mechatronic objects are:

a) during the design process of a production system

• Integrated work and handling of design data of all involved disciplines like mechanical, electrical, instrumentation and automation & control

• Standardization of interdisciplinary collaboration and interfaces

• Improved quality of engineering artefacts and improved efficiency when re‐using pre‐developed and tested engineering artefacts

b) during operation of a production system

• Increase and improve the flexibility, adaptability and efficiency (throughput, use of resources, degree of automation) of the production system.

• Increase robustness and reliability by local troubleshooting (within the mechatronic objects).

12


• Reduce the integration complexity for integration of resources/machines.

• Reduce time and effort for setup and reconfiguration of the production system.

2.2. Concept of mechatronic plant design

Up to now, conceptual structuring and modularization of (production) systems is aiming mostly at the creation of modules within each single discipline, like mechanics, electrics, field control, process control, etc. Thus modularization is done horizontally as shown in Figure 3, where every discipline creates its "optimum" modules and standards that help to improve the level of integration between those discipline‐specific modules. The problem here is that the integration between the systems of the different disciplines – and, therefore, the integration of the entire facility – is not addressed through such horizontal approach and, therefore, must be implemented specifically for each project. This fact leads, according to experience, to substantial additional costs, particularly during the commissioning phase.

Figure 3: Discipline specific modularization

The concept of mechatronic modularization states that modularization is oriented towards the physical structure of production systems, and it is designed vertically with each module containing parts of the mechanical, field control and process control engineering disciplines; see Figure 4. This modularization concept is applied in a consistent and uniform manner to all engineering tasks that have to be performed during the lifecycle of a production system, in the design phase as well as in the commissioning and the reconfiguration phases.

13


Figure 4: Mechatronic modularization

An example of such a mechatronic module/unit within a home appliance production system could be a counter weight screwing station that attaches a counter weight to the washing unit. This mechatronic unit consists of mechanics and electrics like the robot that performs the screwing, the transportation system of the washing unit and also sensors and actuators for measuring and assembling. Additionally, the whole automation part like field control and parts of the process control are needed for a smoothly assembly process. Figure 5 shows the counter weight screwing station of a washing machine production line.

Figure 5: Counter weight screwing station

In contemporary production systems, the functionality of the process control level is mostly implemented in a Material Flow Control (MFC) System. Once this functionality is also

14


integrated into the concept of the mechatronic modularization, it means the dissection of the previously centralized MFC System into autonomous modules. This procedure is necessary since the modules must be easily combinable with each other and, therefore, must not have interdependences with each other. Existing, possibly complex interdependences should remain encapsulated within the modules and not appear outside of the modules (cohesion). The total functionality is dissected into independent partial functionalities, which are integrated again in the engineering process. For this purpose, the automation functions of the system must be dissected at all levels, which leads to the decentralization of the system as shown in Figure 6.

Figure 6: Modularized production system

The use of pre‐integrated modules, the encapsulation of the functionalities, as well as the ability of the modules for identification and coordination among each other, lead to the fact, that modules can, referring to automation engineering, be integrated with each other to an entire facility on a “Plug&Play” basis. This allows supporting the mentioned requirements for flexibility regarding construction and reconfiguration of facilities.

Therefore, the engineering process reference model will be developed towards a mechatronic oriented view.

15


3. Engineering Processes for industrial facilities

This chapter will shortly introduce some of the current knowledge on engineering processes. The goal is to create a broad overview of the engineering processes used within different domains. Engineering processes have been developed for different purposes in the area of production systems. They can be distinguished with respect to the business model followed, the industrial domain addressed, the completeness with respect to the life cycle of products and production systems, and the involved engineering disciplines and stakeholders.

Within the following a mechatronic‐oriented view will be used to describe existing engineering processes and the relevance of mechatronic units within them.

Clearly, the considered set of processes is not complete. Here, processes standardized by industry or developed within leading international and national industrial driven development projects are analyzed and can be considered as a generalized knowledge for a wide range of domain and application specific processes.

3.1. Engineering process of VDI Guideline 5200

The engineering process of VDI Guideline 5200 has been developed to formalize the factory planning process [VDI5200]. It is based on a definition of all relevant engineering information and considers the process as a controlled information enrichment process by concretization of engineering information.

This engineering process consists of eight phases. The first phase is the aim definition phase. Within this phase the company goal and the bordering conditions of the intended production system are analyzed, the production system functionalities and the project aims are defined, the assessment properties for the project progress and results are developed, and work packages are defined. In the subsequent phase the basic conditions for the engineering process execution are generated. Here all necessary information for the process execution is collected and preprocessed. This basic phase is followed by the concept design phase. Here the structure of the production system is defined with respect to its structural and functional decomposition, the different functional units are dimensioned, an ideal layout of the production system without consideration of layout restrictions is created, and finally this layout is adapted to the real facilities it is implemented within. After the concept design the detailed planning is made. Here the detailed engineering of the production system is made, all necessary permission requests are created, and the faction descriptions are made. Afterward the realization of the production system is prepared. Therefore, the necessary offers are solicited, contracting is made, and the execution of contracts is controlled. In the next phase the realization of the production system is controlled at the intended facilities. Here, the realization of the production system is coordinated, supervised, and documented, as well as the final documentation is made. Finally the ramp up of the manufacturing system is made. Here, the production system startup is done and the reach

16


production system is assessed. In parallel to all these phases the project management and finally the project termination is made. The complete process is depicted in Figure 7.

Aimdefinition

BasicConceptdesign

Detailplanning

Project Management / Project termination

Realisa‐tion pre‐

paration

Realisa‐tion

controlRamp up

Figure 7: Engineering process of VDI Guideline 5200

The VDI 5200 engineering process will not directly address mechatronic thinking. But, within this process mechatronic units are usually considered in the different phases to provide basic structures to deal within the planning and engineering as well as to offer or order components of the production system.

3.2. AutomationML engineering process

The AutomationML engineering process has been developed by the members of the AutomationML initiative in 2008 as reference process for the application of the AutomationML data exchange format [DWM08], [Dra10]. It targets the design of a new manufacturing system. Thus it addresses mainly the solution business. But it has also components of the component business.

AutomationML engineering process is based on five phases with a set of engineering activities within the different phases. The first phase is the product design. Within this phase all relevant about the product to be produced will be developed. This includes the development of the characteristic properties of the product, the bill of material relevant, and the bill of operation required to produce the product. The second phase is the factory planning phase. Here the layout & cost planning with a selection of the production resources to be used, the basic process planning, the basic electrical planning, the logistics planning, the planning of quality assurance and a first simulation of the system are made. As a result a first draft paper version of the intended production system is established. This draft version of the plant is detailed in the functional engineering phase. Within this phase the mechanical engineering, the electrical engineering, the control engineering, the robot programming and simulation, and the HMI programming are made. In addition the initial layout and process planning is detailed if necessary. As the result of this phase the complete engineered plant information is available. In the commissioning phase the plant is set up physically, tested and put into operation resulting in a running production system. In parallel the first four phases the standardization phase intends to identify reusable components of the engineered manufacturing system and, therefore, has to be seen as a process of component business. Within this phase reusable components and reusable engineering processes are defined and documented. The complete AutomationML engineering process is depicted in Figure 8.

17


Productdesign

Factory planning

Functionalengineering

Commiss‐ioning

Standardisation

Figure 8: AutomationML reference engineering process

Within the AutomationML engineering process the application of mechatronic units is addressed within the first three phases. In the product design phase mechatronic units as manufacturing system equipment able to provide production functionalities are exploited to define the bill of operation of the product. In the second phase the same type of mechatronic units is used to define the initial factory layout based on predefined function oriented components. In the third phase the complete engineering of the mechatronic units is used to connect the components and enhance engineering quality by using proven solutions.

3.3. Engineering process of Schnieder

E. Schnieder [Sch99] defines an engineering process for production systems against the background of control system engineering. This process consists of five phases. Within the first phase, the planning phase, the basic requirements to the intended system are developed. Based on this, the second phase designs the intended system. Therefore, at first a raw planning with system decomposition and association of functions to the system components is made. Afterwards a detailed planning will specify the system components with its behavior and interfaces. The system design is used in the third phase as a system specification for system implementation. Thus, in the realization phase the system components and its interfaces are implemented by hard‐ and software and partially validated. Then the different system components are integrated resulting in the complete system. This complete system is validated in the tasting phase. Therefore, the implemented system, its behavior, and its functionality are compared with the initially defined requirements. Finally, the implemented and tested system is used including production use and maintenance. This overall process is depicted in Figure 9.

Planning Design Realization Testing Use

Figure 9: Engineering process of Schnieder

Within this engineering process the application of mechatronic units is of interest in the design and realization phases. In the design phase the system decomposition can be based

18


on existing mechatronic units. These mechatronic units can establish system components and thereby, provide its complete design and realization.

3.4. Engineering process of Kiefer

J. Kiefer [Kie07]has developed an explicitly mechatronic oriented engineering process intended to be used in the automotive industry domain. This process consists of 5 phases. Within the initial concept planning phase the product related and the customer related requirements to the intended production system are collected and preprocessed, the necessary manufacturing steps are evaluated and translated to a high level production system structure, design alternatives are considered and weighted, and finally the intended production system structure is specified. In the subsequent following phase of detailed planning the complete construction of the production system is made. This includes the mechanical, electrical and control system design which is executed semi‐parallel. Within the realization phase the designed system is implemented and tested. Here virtual commissioning is of great importance. The ramp up phase contains the start up of the production system including the initial production and the initial quality control. The final phase covers the normal production run and the support during these activities by engineering information. The complete process is depicted in Figure 10

Supportin serial

production

Concept Planning

Detailed Planning Realization Ramp up

Figure 10: Engineering process of Kiefer

As the engineering process of [Kie07] is mechatronic oriented mechatronic units will play an important role within. They are especially addressed in the first three phases as pre‐developed engineering artefacts providing proven knowledge and engineering details. Thereby, they intend to limit failures, improve engineering quality, and reduce engineering process duration.

3.5. PABADIS’PROMISE engineering process

Within the PABADIS’PROMISE engineering process the design process of a distributed control system and a manufacturing system integrating this control system are addresses [PAB08] , [WHE10]. It has been designed integrating leading companies within the fields of control systems and automotive industry.

This engineering process consists of 6 phases. The first phase contains the definition of the production order and its physical and logical sequence. This is followed by the layouting phase. Here, the production system layout is generated out of the process description and

19


the types of required resources are defined based on the required capabilities. In the next phase the detailed design is made. This includes the specification of all technical details of production system equipment, instrumentation, and automation. Afterwards the purchasing and/or the manufacturing of the production system components are done. This includes the construction and implementation toward functional units covering all involved technical disciplines. Within the construction and commissioning phase the production system components are integrated as functional units toward complete production system and the system capabilities and component capabilities within the system are tested and verified. Parallel to the last three phases the ERP and MES systems are integrated. Therefore the necessary interfaces are defined and implemented. The process is given in Figure 11.

Processplanning

Layouting DesignPurchasing & Manufac‐

turing

Construction& Commis‐

sioning

ERP and MES integration

Figure 11: PABADIS'PROMISE engineering process

The application of mechatronic units is integral part of the PABADIS’PROMISE engineering process. They are seen as engineering artefacts providing production capabilities to the overall system which can be automatically integrated in the overall system. Thus in the first two phases the mechatronic units are seen as capability providers while they are used in the third phase as best practice solutions for the engineering of used components.

3.6. MEDEIA engineering process

The MEDEIA engineering process has been developed within the EC project MEDEIA under integration of several industrial partners [MED10], [SRE08]. It is targeted to the component based engineering of production systems and its inherent control systems.

The MEDEIA engineering process consists of five phases. The first phase is dedicated to the identification of system functionalities required and its decomposition. In the next phase to each identified function relevant components are selected which are realized in the third phase of the process. As each of the components finally is based on embedded devices for sensors and actuators these embedded devices and their controls as well as the control of the components are implemented in the fourth phase. Finally, the resulting system is simulated and commissioned.

Functionaldecompo‐sition

Component selection

Componentrealization

Embedded system

designSimulation

20


Figure 12: MEDEIA engineering process

The strongly control system oriented engineering process emphasis the use of mechatronic units providing the necessary control related hard‐ and software for the production system implementation. It will combine a functional view on the system with an implementation view.

3.7. AQUIMO engineering process

The AQUIMO engineering process has been designed within an industrial development project with several SME partners [AQU10a], [AQU10b]. The main aim of this project was the development of an engineering process and a supporting tool for the development of machines and equipment as mechatronic systems useable within the design and implementation of machines and production systems.

This engineering process contains three phases. Within the initial phase, the analysis phase, the requirement to the components to be developed will be collected and preprocessed. Based on these requirements the overall component design is made in the design phase. This will include the geometries and behavior but also design possible alternatives. The third phase is dedicated to the engineering of the system within the different involved engineering disciplines like mechanical engineering, electrical engineering, and control engineering, as well as the integration of the different engineering results to a unique engineering artefact.

Analysis Design Construction

Figure 13: AQUIMO engineering process

The AQUIMO engineering process targets in the development of mechatronic units. I.e., this engineering process will create engineering artefacts which are complete mechatronic units including all relevant engineering information.

3.8. Domain engineering

The domain engineering process aims at systematical development of reusable engineering artefacts, usable within the engineering of production systems for a special industrial domain of interest [JMG10]. This includes the development of all information, models, methodologies, etc. which can be used to improve the design of production systems. Therefore, the domain engineering contains four phases. The first phase is dedicated to the

21


domain analysis. Here existing engineering artefacts coming from different projects of the solution business are analyzed possibly usable for basic evaluation, initial planning, and conceptual design. Therefore, the domain borders and stake holders are identified, basic requirements are specified, and existing solutions of the domain are identified. Within the subsequent domain design engineering artefacts are established useable for the project execution within a basic or detailed engineering of a solution business project. This includes the functional analysis for the identification and definition or required or used production functions, the development of components, the design of a reference structure of the production system, and the specification of methods for the combination of components to the overall systems. The third phase is the domain realization. Here, the different engineering artefacts intended including the production system components are implemented and tested. Therefore, among others, the components and its engineering information are completed and generic project execution plans are developed. The final phase of the domain engineering is the application engineering. This phase in fact is equal to a solution business project.

Domainanalysis

Domain design

Domain realization

Application engineering

Figure 14: Domain engineering process

The domain engineering will use and develop among other engineering artefacts mechatronic units usable as production system components. Therefore, it will identify within existing solutions these mechatronic units and will establish all relevant engineering information required for its later reuse.


The VDI Guideline 2206 [VDI2206] has been developed to describe the design process of products1 based on mechatronic thinking. Therefore, it combines the mechatronic thinking with the product design process resulting in a parallelization of engineering activities within the different engineering disciplines.

Generally this engineering process can be divided into 6 phases and follows the well known V‐model. Within the first phase the collection of requirements to the intended product within the problem description phase. It is followed by the system design phase. Here the overall structure of the product is developed by defining the system component hierarchy and its interfaces. Based on this overall structure the detailed engineering of the product is made in the third phase. This phase is for domain specific engineering, i.e. the

1 For more information on product design see [UlE08], [ScS05]

22


different engineering domains like mechanical, electrical, control, etc. engineering will work in parallel creating all documents for the detailed engineering. The results of the domain specific engineering will be integrated to the complete product in the system integration phase. The thereby developed product will be validated in fifth phase with respect to the fulfillment of the requirement to the product defined in the first phase. In parallel to the phases two to five the modeling and analysis phase will run. Here the other phases are supported by overall modeling of the intended product and its properties and capabilities. The complete process is depicted in Figure 15.


Within the VDI 2206 engineering process nearly all phases will exploit mechatronic thinking as the consistent design and engineering within all engineering disciplines targets to the design of a mechatronic unit focusing on the generation of technical, functional, and economical benefits.


The VDI guideline 3695 [VDI3695] has been developed to provide means for the improvement of engineering organizations with respect to engineering efficiency and engineering quality. As one result an engineering process has been developed combining the component business with the solution business.

Problem description

System design

Domain specific engineering

System integration

Validation

Modeling and Analysis

23


Productdesign

Planning Engineering RealizationCommis‐sioning

Analysis Planning Engineering Realization Test

Engineering artifacts

Best practice


For both businesses this process defines 5 phases. Within the component business the process starts with the analysis phase. Here best practice from solution business projects and the current market end technology conditions are analyzed resulting in a basic specification of intended components. In the subsequent planning and engineering phases for the intended components the basic design and the detailed engineering are executed. This is followed by the physical realization and testing of the component. Finally, reusable components for the solution business are developed. The solution business process starts with the definition of the bill of material and the bill of operation definition for the intended product as a basic requirement definition for the production process to be executed within the engineering process. Here, the component functionalities defined before are used as basic definition of usable activities within the bill of operation. Within the next phase, the planning phase, the intended production system is planned as a combination of components executing the bill of operation. Here, the plant layout is defined, the components are sequenced, and the system is simulated to validate the fulfillment of basic requirements. This is followed by the engineering phase. In this phase the detailed engineering of the manufacturing system is made containing mechanical, electrical, control, and HMI engineering exploiting the pre‐engineered components. Within the realization phase the engineered system components are set up including the ordering of components. Within the commissioning phase the complete system is established at the intended production seat and tested. The complete process is depicted in

Figure 16.

The engineering process following VDI guideline 3695 directly addresses the use of mechatronic units as engineering artefacts. They are the intended goal of the activities within the component business process and are directly exploited within the solution business as input. Thereby, the reuse of engineering results and, thus, the enhancement of the overall engineering process quality is reached.

24



The VDI Guideline 4499 has been developed to enable the beneficiary application of information technology within the complete life cycle of products and production systems [VDI4499‐1], [VDI4499‐2]. Thereby, it combines the product business with the solution business. The resulting engineering process contains a product related part and a production system related part.

The product related part is covered by the complete process of product data management starting with the product design and engineering over the complete production process of the product until the sales and after logistics of a product. This process will not be detailed here.

Nevertheless, this process is strongly related to the production system oriented process. It will provide requirements for this process and will influence the information management within it.

The production system oriented process consists of five phases. It starts with the process planning phase creating the necessary sequence of production steps and naming / designing the necessary devices, appliances, and tools for its execution. It is followed by the factory planning. In this phase the different production resources are detailed and engineered, the logistic systems are defined and engineered, the safety systems are developed, and the complete control system is implemented. In phase three the designed and engineered production system is physically realized. Here, the different production resources are implemented in hard‐ and software, the overall system is assembled, and the system is tested. After successful tests the commissioning and ramp up of the production system is made in phase four. Within both phase three and four virtual commissioning can assist the process progress and avoid errors. Finally, the manufacturing system is used. In this phase product related information are sent back to the product related process. The complete process is given in Figure 17.

Within the VDI guideline 4499 mechatronic systems are not addressed explicitly. But, especially the focus to virtual commissioning leads to the consideration of function oriented components within the production system which can be modeled and used in a virtual system. Thereby, mechatronic principles have to be applied.

Process planning

Factoryplanning

Design &Implemen‐

tationRamp up Use

Product Data Management


25


4. General engineering process reference model

4.1. Meta‐model for engineering processes

The engineering process of industrial plants is a sequence of steps beginning with the production concept and ending with the plant ready for operation. Different actors and roles need to interact with each other during this complex process in order to realize the milestones set by the customer. To get the full picture of the process, a systematic approach for describing engineering processes is required.

Figure 18 shows a simplified version of the meta‐model which is used within this work package. Essential elements are activities, artefacts, and their relationships, which represent information flows in the work process.

Figure 18: Meta‐model for structural and attributive features of engineering activities.

The meta‐model examines the following entities:

• Actor: An actor is an organization which is actively involved in the industrial value chain (planning, installation and commissioning) of the plant. The main actors are: System Integrator, Component Supplier, Equipment Supplier and Operator.

• Engineering Process: The process is structured in several phases describing all activities to plan, design and commission a plant.

26


• Engineering Phase: A process phase describes a certain sequence of technical activities within the plant lifecycle such as detailed planning.

• Roles: The role represents a certain engineering actor, e.g. an electrical engineer, mechanical engineer, automation engineer, etc.

• Activity: An activity is a task that needs to be accomplished within a defined period of time.

• Artefact: An artefact can be both input and output for an activity.

The interactions between the entities are defined as follows:

• An Actor owns a Process

• A Phase is part of a Process

• An Activity is part of a Phase

• An Activity is executed by one or more Roles

• An Activity has impact on the design of a Subsystem

• One or more activities output(s) one or more Artefacts

• An Artefact is input for one or more Activities

The following general engineering process reference model has been built upon this Meta‐model. The entities “process”, “phases” and “activities” will be considered in more detail, while the other activities will be detailed specifically in Appendix A.

4.2. Engineering processes

Regarding the results of chapter 2 and 3 the general engineering process has to be divided into two separate processes. The first process is independent of a specific engineering project. Here the mechatronic units used within the engineering of a facility are developed. This is achieved by identifying reusable mechatronic units based on either a market analysis or project feedback. After that, the reusable units are analyzed, modeled and realized within an engineering tool.

The second process is the engineering project where a specific facility is engineered using the pre‐developed mechatronic units. During all four phases (process planning, basic

27


engineering, detailed engineering and commissioning) the mechatronic resource library is used to support the engineering process. The complete general engineering process reference model is depicted in Figure 19.

Figure 19: Overview: General engineering process reference model

4.3. Engineering phases

4.3.1. Development of mechatronic units

The essential precondition for the feasibility of the engineering of production facilities according to the described procedure is that in the run‐up, mechatronic modules are prepared in order to be available as a template in a library for the facility planner. This task is achieved within the process of developing mechatronic units.

During the design of these facility and project independent mechatronic modules, the following information must be specified and provided in an integrated manner:

• Description of the mechanical parts, e.g., in CAD layout.

• Description of the behaviors of the facility resource, such as kinematic behavior.

• Description of the machine functionalities that the resource offers for the design of production steps (function oriented view).

• Description of the automation portions: control and communication interfaces, required connections for hydraulics, pneumatics, and electrics, as well as models or implementations of baseline control, HMI, and communication building blocks.

• Description of combination possibilities or limitations with other resources in order to integrate individual functionalities into one overall functionality.

Identification

28


Prior to the creation of reusable mechatronic units an identification step is needed. Herein the facility is analyzed in respect of potential reusable components. This identification can be done in two steps.

First an identification of all components of the facility is needed. An identification of mechatronic units follows a functional‐oriented approach, where each unit is described by the function it offers to the facility/system. Additionally a hierarchical structuring, e.g. using the level‐model of [Kie07], could be done. As a result of this first step we obtain a structured list of all components of the facility.

The second step analyses these components regarding their reuse‐potential. This could follow an approach similar to [Jos07]. During this analysis some components might be rated as not reasonable reusable.

The outcome of the whole identification step would be a structured list of components, which should be realized as reusable mechatronic components.

Analysis and modeling

After a list of reusable components of the facility is set up, these components need to be analyzed and modeled. Practically these both steps would most often proceed in parallel, so that the analyzed data is modeled within an engineering tool. Examples for the data to be analyzed could be:

• Mechanical data like geometrics, kinematics, material, … (CAD‐Tool)

• Electrical data like power supply, wiring plans, routing, … (ECAD‐Tool)

• Automation data like signals, Hardware, behaviour, … (Process Control Systems)

• Miscellaneous data like instruction manuals, data sheets, maintenance manuals, … (office tools, …)

Realization

In a final step the analyzed and modeled components need to be realized and stored into a library with the help of engineering tools. The result is a library of reusable mechatronic units usable within the following engineering projects.

4.3.2. Engineering project

The engineering project is divided in four phases. In depth analysis of the engineering processes of chapter 2 show that all mentioned phases are in some kind part of one of the four phases of the general engineering process.

Additionally some engineering processes of chapter 2 also consider additional “phases” like MES and ERP integration in the PABADIS’PROMISE engineering process. Having a more detailed look at these “phases” shows that they are actually no real engineering phases but

29


more kind of thematic engineering clusters. These clusters describe a collection of engineering activities which could also be assigned to one of the four general engineering process phases. Regarding this each engineering cluster is fully performed within the four general engineering phases.

Process Planning

The production process for the product to be produced is described by a specification of the production steps by the operator of the production. In addition, the production process has to be structured hierarchically in production steps, and the predecessor‐successor relation, as well as parallel processing between production steps, must be described. Likewise, the machine functionalities for the performance of a production step have to be characterized. This concerns both the control functionality and the kinematic behavior of machines. All mentioned additional steps serve for the preparation of the efficient implementation of the subsequent steps.

Basic Engineering

Based on these information and the available mechatronic modules, the system integrator derives the facility parts to be installed and their technical interrelationship. Mechatronic modules that offer the desired functionalities are attributed to each production step. For this purpose, the mechatronic modules will be selected from a library that may also contain complete process steps realizing production cells. For selection and matching, the predefined production functions of the mechatronic modules are used. If the production process was specified comprehensively as described in Process Planning, the basic engineering may be performed in a supported or automated manner.

In addition to the pre‐specified, mechanical and electronic data, the mechatronic module also contains predefined control applications for the realization of the production functions. In addition, the specific data of the utilized mechatronic modules for the geometrical positioning in the facility, their kinematic behavior, and their geometries in the 3D factory layout has to be substantiated. Furthermore, the interdependence is considered for the dimensioning of mechanics and electrics, e.g., for the layout of the power of motors.

Detailed Design

In the next step, the configuration of the predefined control functionalities of the utilized mechatronic modules is done in accordance with the specific process parameters, and, if necessary, the programming of auxiliary functions is performed. In addition, the connections between mechatronic modules and the corresponding parameterizations of these connections have to be specified:

• Connection of electrical, pneumatic, and hydraulic systems.

• Connection of the communication devices to communication networks.

• Connection of material flow relations.

30


• Attribution of I/O signals between sensors/actuators and control applications.

The connections are generated automatically or manually, depending on to what extent the connections have been specified in advance. PLC and HMI programs are usually generated automatically from the control applications of mechatronic modules. In this planning phase, the design or the adaptation of the facility mechanics (CAD) and the electrical design (CAE) are also done unless large extends have been already predefined in the mechatronic modules.

Realization & Commissioning

As the real used facility resources correspond to pre‐integrated mechatronic modules, they can be provided in a manner in which they can be integrated into the automation system via plug and play. After corresponding adaptation, these facility parts can be used immediately.

4.4. Generic Engineering activities

As a third level of detail this chapter will give an overview of general engineering activities. Therefore the following Template is used to describe the activities.

Name Short name of the activity Description Short textual or key word description of the corresponding activity Application cases

Special engineering action usually exploiting this activity

Engineering phases

Naming of the engineering phases where the activity is used

Note: The term plant component is used for generalization purposes. In most cases this term is synonymous to the term mechatronic unit

4.4.1. Decomposition of the plant / plant components

Name Decomposition of the plant / plant components Description • Decomposition is the top down consideration of the hierarchy of the

plant / plant components • Decomposition can be executed based on different guidelines like

o Structural decomposition o Functional decomposition o Behavior based decomposition o …

• Decomposition reflects the creation of substructures of the plant /

31


plant components based on the decomposition guidelines2 • Each plant component of the substructures contains external and

internal interface definitions and connections and facets

Application cases • Manufacturing system structuring • Device structure definition

Engineering phases

• Development of mechatronic units o Identification o Analysis and modeling

• Engineering project o Process Planning o Basic Engineering

4.4.2. Composition of Plant components

Name Composition of plant components Description • Composition of plant components is the bottom up view on plant

components a building of hierarchies • Composition can be executed based on different guidelines like

o Structural composition o Functional composition o Behavior based composition o …

• Composition reflects the creation of superstructures of plant components based on the composition guidelines3

• The resulting plant component contains external and internal interfaces definitions and connections and facets

Application cases • Manufacturing system structuring • Device integration

Engineering phases


• Engineering project o Process Planning o Basic Engineering

2 Decomposition guidelines represent the best practice of top‐down breakdown of manufacturing systems in hierarchies of manufacturing system components of different nature (see [VDI2206], [Jos00]). 3 Composition guidelines represent the best practice of bottom ‐up aggregation of manufacturing system component in hierarchies to manufacturing systems (see [VDI2206], [Jos00]).

32


4.4.3. Refinement of Plant components

Name Refinement of Plant components Description • Within the mechatronic engineering process plant components and

its facets can include information of different level of detail depending on the engineering phases and in different states depending on the finalization state of engineering activities

• Refinement is the process of concretization and enrichment of information of plant components and its facets within the course of the mechatronic engineering process

• Refinement ensures, that the level of detail of information within the plant components and its facets is increased

• Refinement ensures the generation of new versions of information

Application cases • Hierarchy definition • Facet definition / refinement • Interface definition • Behaviour generation • Code generation

Engineering phases

• Development of mechatronic units o Identification o Analysis and modeling o Realization

• Engineering project o Process Planning o Basic Engineering o Detailed Engineering o Commissioning

4.4.4. Variants Development

Name Variants Development Description • Variants of plant components represent similar plant components

differing with respect to a limited amount of information within the facets

• Variants development is the process of adaptation of a plant component to different application cases by

o Changing facet information o Adding facet information o Adding facets

• Usually variant generation follows the need of o Adding additional behaviour to a plant component

33


o Changing plant component hierarchical structure (replace devices or used technologies)

• Variant development results in a set of different plant components

Application cases • Reuse of engineering project results / development of plant component libraries

• Product development • Adaptation of project results to further needs

Engineering phases

• Development of mechatronic units o Analysis and modeling o Realization

• Engineering project o Detailed Engineering o Commissioning

4.4.5. Template Development

Name Template Development Description • Template development is the engineering activity of creating a plant

component template • Within template development to following questions will be taken:

o Which information deviations can have the plant components creatable by the template?

o What are the differences within facets that can be parameterized in the template?

o What are selectable facets in the template and how are they related to each other?

o What additional information can be added to the template?

Application cases • Reuse of engineering results • Template library definition

Engineering phases


4.4.6. Instantiation

Name Instantiation Description • Instance Generation is the process of applying templates to get real

existing plant component

34


• Within instance generation a plant component template will be concretized with respect to

o Definition of necessary parameters o Selection of facet versions4 o Addition of facet information

with the aim to reach a plant component describing a real existing plant component.

• Instance generation targets in the provision of consistent plant components useable in a project structure of a solution business project

Application cases • Use of template libraries within plant planning to define the plant structure

• Use of templates within the process of device structure definition and implementation

Engineering phases


• Engineering project o Process Planning o Basic Engineering o Detailed Engineering

4.4.7. Flexible View Generation

Name Flexible View generation Description • Based on the engineering tasks different engineering disciplines

needs various views on plant components • Views provide all information necessary for the execution of

engineering activities • Views can be based on content of single facets of plant components,

the combination of several facets or an information subset of one facet

Application cases • Provision of specific information for engineering disciplines • User assistance within engineering activities

Engineering • Development of mechatronic units 4 Within templates the same facet in different versions can be integrated to represent different variants following the METUS [MET10] concept. Examples can be control behavior facets covering basic bahavior and advanced behavior with additional safety functions.

35


phases o Identification o Analysis and modeling o Realization

• Engineering project o Basic Engineering o Detailed Engineering o Commissioning

4.4.8. Layer Generation

Name Layer generation Description • Distributed and parallel engineering requires a parallel access to

plant components • Each discipline needs a separate working layer on the engineering

data based on a shared planning status • Each working layer should provide

o Discipline specific views on plant components o Access rights to the relevant data only5 o Discipline specific hierarchies of plant components

• Merging of working layer cloud be done by an engineering tool or manually

Application cases • Parallel and distributed engineering Engineering phases



4.4.9. Definition of Requirements

Name Definition of requirements Description • Definition of requirements is the activity of modeling applicability

conditions of plant components within mechatronic systems

5 As working layers are usually engineering role or engineering discipline oriented, at this point, the term „relevant data only“ addresses the amount of information required to execute the relevant engineering activities oft he engineering role or engineering discipline efficiently and in a high quality.

36


• Definition of requirements covers the specification of process, technical, economical, employee knowledge or further conditions

• Definition of requirements is the explicit integration of requirement information to an plant component into the representing plant components by creating

o Independent requirement facets or o Requirement information within facets

like o Integration of functional requirements like maximal

speed of motions in the behavior facets o Integration of non‐functional CO2 pollution limitation

requirements within an additional requirement facet

Application cases • Specification of manufacturing system capabilities • Definition of necessary device of module characteristics within the

order process

Engineering phases



4.4.10. Decomposition of Requirements

Name Decomposition of requirements Description • Requirements can be given in different levels of detail resulting in

different versions of requirement specifications like o Maximal speed is at x m/s o Speed should be limited at x m/s with a maximal

acceleration of y m/s² o Speed should be limited at x m/s with a maximal

acceleration of y m/s² with a linear acceleration curve • Decomposition of requirements is the process of requirement

concretization by adding more detailed requirements • Examples of requirement decompositions are:

o More detailed description of an intended manufacturing process by decomposition of manufacturing process steps like producing a toothbrush is decomposed in

37


producing the toothbrush handle piece, producing the bristle clusters, gluing the bristle clusters in the toothbrush handle piece, finalization

o More detailed description of environmental requirements by adding of additional environmental parameters like adding NO2 pollution data to CO2 pollution data

o More detailed description of employee knowledge requirements by detailing required scientific knowledge and professional skills like detailing the required knowledge about chemical process to be able to act as a plant supervisor

Application cases • Specification of manufacturing system capabilities • Specification of application requirements for mechatronic systems

Engineering phases



4.4.11. Requirement driven Test and Validation

Name Requirement driven test and validation Description • Within mechatronic engineering processes requirements are defined

to be fulfilled by the plant components of the resulting mechatronic system

• Requirement fulfillment can be checked by comparing requirements with further plant component information

• Requirement driven test and validation is the process of validation of requirement fulfillment by a plant component or a set of plant components exploiting the information within plant component and its relations / dependencies / associations / etc.

Application cases • Engineering project management and quality control • Acceptance test preparation

Engineering phases

• Development of mechatronic units o Identification

38


o Analysis and modeling o Realization


4.4.12. Consistency Management

Name Consistency management Description • An important success factor for (mechatronic) engineering processes

is the avoidance of data inconsistencies among planning stages and engineering disciplines

• Consistency management is the process of inconsistency avoidance based on

o Unique object identification of each plant components o One to one relation between plant component and plant

component, the following terms apply plant components do not contain the complete

information about plant component in any case Information based engineering artefacts that are

independent from plant component are templates

o Association and dependency management between plant component and facets of plant components e.g.:

Interface connection management Behaviour dependency management

o Automatic actualization of dependencies within different planning objects

Change tracing and propagation Delta views between different planning stages

and disciplines • Consistency management provides means to guarantee engineering

quality

Application cases • Combination of planning stages • Version creation based on different working layers • Consistency checks • Change trace of planning stages

Engineering phases


39


o Realization • Engineering project

o Process Planning o Basic Engineering o Detailed Engineering o Commissioning

4.4.13. Selection of Plant components Based on Requirements

Name Selection of plant components based on requirements Description • The mechatronic engineering process bases on the principle that the

complete manufacturing system is designed as aggregation of plant component.

• The plant components respectively their information representation plant component can be selected by several criteria e.g. cost or interfaces or requirements fulfill by the plant component

• The selection process is based on the mapping of requirements to a plant component represented in a plant component with the characteristics of a plant component

Application cases • Composition of manufacturing system • Selection of plant components for manufacturing tasks

Engineering phases



4.4.14. Simulation / Execution of Behaviour Model

Name Simulation / execution of behaviour model Description • Simulation of behavior of manufacturing systems is one key

approach the reduce failure within the different phases of planning • Behaviour models of plant component (uncontrolled internal

behavior of the plant component6) as facet of the corresponding

6 The uncontrolled internal behavior of the MU is the complete behavior a MU can have if no control is active and any external signals are allowed. Is represents the maximal possible behavior an MU can show.

40


plant components can be used to create an overall behavior model of MSs

• Behavior should cover plant control sequences as well as internal models of plant components building of closed loop model

• Therefore, translation/ aggregation of the behaviour models (control and uncontrolled) of single plant components in on execution model is necessary7

• Model execution requires execution rules which are basement of the behavior models

• Simulation can be the starting point for behavior validation and verification

Application cases • Virtual commissioning • Behaviour simulation

Engineering phases


• Engineering project o Detailed Engineering o Commissioning

4.4.15. Plant component Library Management

Name Plant component Library Management Description • For reuse purposes it is necessary to store existing solutions

• Suitable solution representations are libraries of plant components or plant component templates with adapted management for the handling of plant components / templates

• Usually library elements can be seen as reference structures of useable engineering artefacts, these artefacts have to be managed in a proper way to be useable in a efficient and correct way

• Examples for management task o Handling of separated facets o Constancy over different facets of one plant component o Versioning of plant component o Hierarchical structures for plant component (reuse in

different levels) o plant component selection based on requirements

7 For more details about the existing approaches about behavior modeling and generation and application of closed loop models see for example [HHM09].

41


Application cases • Reuse of proved plant components • Project independent development of plant components • Assembly of manufacturing systems exploiting plant components

(building set principle)

Engineering phases



4.4.16. User Guidance within the Engineering Process

Name User guidance within engineering process Description • Engineering processes follow predefined application of engineering

activities, these engineering activities usually have predefined input data sets and expected results it is possible to automate the navigation through the course of the engineering activities

• User guidance within engineering processes are all actions, capabilities, guidelines, etc. assisting the persons executing the engineering process within its engineering activities

• User guidance includes o First level passive user guidance provides information

useable to understand and execute the engineering process like help systems and documentations,

o Second level passive user guidance provides basic engineering results which can be applied and improved within the engineering process like pre‐developed templates

o Third level active user guidance analyses engineering result consistency and quality based on consistency and quality rules like observation of code syntax within PLC programming

o Fourth level active user guidance provides active engineering activity navigation through the engineering process with engineering result observation like Microsoft Office letter assistant

Application cases • All engineering activities

42


Engineering phases



4.4.17. Change Management

Name Change Management and Change Impact Analysis Description • Within the mechatronic engineering process information within the

different facets are integrated, enriched, changed or deleted. • Information within facets may have dependencies, i.e. integration,

enrichment, changes or deletions of information within one facet may require integration, enrichment, changes or deletions of related information within another facet

• The process of integration, enrichment, changes or deletions of related information can

o Have multiple levels o Be cyclic o Be executed automatically

• Change Management is the engineering activity assisting the execution of necessary integration, enrichment, changes or deletions of related information caused by integration, enrichment, change or deletion of information within facets

Application cases • Changes of control device interfaces influences wiring planning • Changes in plant structure definition changes E‐CAD • Additional safety requirements causes additional PLC code and

additional safety devices which cause additional wiring

Engineering phases



43


4.4.18. Requirement Fulfillment Tracing

Name Requirement Fulfillment Tracing Description • Manufacturing systems have to fulfill various application conditions

defined as requirements. • Fulfillment of requirement is usually reached by the combination of

technical and technological means, i.e. the developed manufacturing system will meet the requirements by its components.

• Requirement fulfillment tracing is the engineering activity o Associating plant components or facets or content of

facets realizing the fact, that a manufacturing system will meet a requirement, to the requirement

o Providing an overview which requirements are meet and which requirements are not meet

o Enabling an overview about the effects of changes within plant components or facets or content of facets on the meeting of requirements

• Requirement fulfillment tracing calls for the continuous definition and decomposition of requirements and the association of plant components or facets or content of facets meeting the requirements during its generation within engineering activities

Application cases • Acceptance tests based on paper / digital information • Information retrieval for the development of reinvest or

maintenance projects • Project management

Engineering phases



4.5. Technical Engineering activities

Besides the generic engineering activities there are also technical engineering activities within the different engineering phases. These can be described by fields of activities, whereas each field of activity represents multiple technical engineering activities aiming for

44


the same goal‐ The following table gives an overview of technical engineering activities. Pleas note that in each application case these activities ma be completed by others nit specifically named here. The Technical engineering activities regarding the GRACE reference engineering process are listed in Appendix A.

Fields of activities Technical engineering activities

• Creating plant layout drawings

• Arrangement of equipment

• Definition of project/plant structurePlant Layout Design

• Creating Material flow sheets

• Manufacturing Process Planning

• Manufacturing Process Simulation & Validation

• Drafting of CAD/CAM dataManufacturing Engineering

• Calculate / determine the kinematics of equipment

• Determine E&IC (EMR/ EMSR)

• Drafting of Electrical diagrams, wiring and circuit diagrams

• Drafting of cable and terminal diagrams, marshalling

• Planning of switching and control cabinets

• Hardware and network planning

• Creation of I/O lists, measuring‐point/tag list, set‐point/alarm list

• Cable Planning

• Planning of Power supply system and switching stations

• Grounding Design & Lightning Protection

Electrical & Power Supply Engineering

• Planning of Safety features and equipment

• Specification & configuration of automation hardware

• Creation of basic automation functions and sequences

• Closed loop control, continuous functions, batch planning

• Visualization of interlocks and sequence controllers

• Engineering /programming of Process control

• Code generation for PLCs

Automation & Process control

• HMI programming

• Product definition, production operations

• Configuration of plant structure

MES modeling & configuration

• Machine functionality & behavior

45


Fields of activities Technical engineering activities

• Equipment and process specific production rules

• Detailed production scheduling

• Production resource management

• Building design, architecture & construction drawing Civil Engineering / Steel Structures / Auxiliaries • Fundation, concrete and steel structure layout

• Mechanical construction 2D/3D

• Planning of equipments / components

• Crane Design Mechanical Engineering

• FEM calculations, stress analysis

46


5. Interrelation model of product quality and engineering process

5.1. Derivation of the interrelation model

One of the main aims of the GRACE Project is to significantly raise the quality of manufactured products and improve the related processes. Therefore four research working packages were defined. While WP1, WP2 and WP3 are directly dealing with the quality related processes and equipment of a production line and their integration within production/assembly related processes, WP4 – Engineering Methodology is not explicitly related to the product’s quality properties. Never the less, there is a significant influence and indirect interrelation of both of them.

The objective of the engineering is

• to create engineering artefacts (models, documents and data sheets) which define and specify all properties of the technological (manufacturing) process, used equipment and the technical (automation) system from all required point of views and

• to provide these information in a level of abstraction, completeness and consistency that guarantees the correct physical realization of the manufacturing process and the manufacturing facility with regards to the requirements (product properties, production properties, safety properties, etc.).

The engineering of a manufacturing facility consists of activities, engineering artefacts (results) and roles (e.g. technical disciplines). Structuring these elements leads to the engineering process, where activities, artefacts and roles are grouped in engineering phases and processes owned by an actor. The final result of an engineering process is the physically existing manufacturing system. This is where the direct influence of the engineering process typically ends (see Figure 20).

47


Figure 20: Engineering defining the manufacturing system

From this point the influence of the engineering is only of indirect manner. Revealing these indirect interdependencies is one of the main tasks in WP 4 in order to understand the effects of integrated process and quality control to manufacturing systems engineering activities, to do systematic elaboration of required changes in manufacturing systems engineering and to develop new engineering methodology accordingly.

The manufacturing system is producing the products. Therefore the process and quality related properties of the manufacturing system are directly influencing the product properties and quality. This way the engineering is important for the product quality as it defines indirectly how manufacturing system ensures this quality. Also other parameters are directly set within the engineering, e.g. the fault tolerance of a production component is defined within the engineering process. A high fault tolerance e.g. regarding the positioning of the product component to be processed leads to a better product quality as it is processed in the right way (e.g. position of drill holes are adjusted regarding the current workpiece position).

Figure 21 shows how the production process is influencing the product properties.

48


Figure 21: Manufacturing system influencing the product properties

Figure 21Figure 22 shows the enlarged Cause‐Effect‐Chain diagram of a production line

manufacturing process of . From left to right the logical order of manufacturing and quality control stations is depicted. At the end stands a product with a defined set of properties created and affected by the manufacturing stations. Related to each manufacturing station is the part entering the production process at this station, e.g. a motor that is attached to the washing unit. Also each manufacturing station has a set of production parameters. These could be technical parameters (like torque, force, geometrics, …) or a parameter called “human operation” which means that this manufacturing step is done by a human operator. This differentiation is done because technical parameters could be influenced by the engineering process while human operators can’t be “engineered”.

Figure 22: Cause‐Effect‐Chain for the production process

49


The last missing link from the product properties to the product quality is normally established at first. It is the establishment of a systematic product quality model defining the dependencies between product quality and product properties (see Figure 22). One method to define such a model is the House of Quality (see [Ham11]), which is exemplary explained in the following.

Figure 23: Product properties defining the product quality

The House of Quality is also shown enlarged in Figure 24. It contains eight arrays / blocks (so called “rooms”) describing the relation between the technical engineering of a product and the costumer requirements regarding a product. Within work package 4 only two of the rooms are from interest.

• the main room – defining the relation between the product quality features and the product properties and

• the roof – describing the dependencies among the product properties.

The main room is a simple matrix. For each product quality feature is depicted whether a property influences it positive, negative or if there is no dependency. This scale is mostly distributed over five values (strong positive effect, positive effect, no effect, negative effect, strong negative effect) but could also be scaled individually.

Within WP4 these dependencies enable the tracking of product properties to product quality and thus the tracking of the indirect influences of the engineering on product quality.

The roof of the House of Quality shows the dependencies among the single product properties. This is a very useful input regarding the dependency analysis, as it limits the optimization possibilities. E.g. if the washing machine is to heavy (e.g. regarding transport) and in parallel shows not enough stability during the spin cycle, one optimization opportunity would be to increase the mass of the counter weights to improve the stability. But this would negatively affect the quality regarding transportability. So other optimization

50


potentials should be exploited, e.g. improving the quality of bearing insertion and therefore reducing vibrations.

Although this is a very simple example it shows the importance to known as much as possible about the dependencies among product properties.

Figure 24: House of Quality [SKC02]

Figure 25 shows the complete causal chain in which the engineering is influencing the quality of a manufactured product.

51


Figure 25: causal chain for engineering influencing product quality

Hence, the importance of the engineering methodology to the GRACE Project is not only towards ensuring industrial applicability but also towards systematically defining all required properties of the manufacturing system that target the quality of manufactured products.

5.2. Integrated meta‐model for engineering, product properties and product quality

Based on the results of section 5.1 a meta‐model can be developed integrating the dependencies between engineering, product properties and product quality. Like shown in Figure 18 the lowest layer in the engineering processes is the engineering activities and engineering artefacts. While the engineering activities output the artefacts, those artefacts themselves are defining the manufacturing system with its production lines, quality control and manufacturing stations as well as the testing and production steps.

From a hierarchical view the whole manufacturing system is producing a product. This product is an aggregation of its product components which are produced by production lines. These production lines consist of quality control stations and manufacturing stations. The quality control stations are testing the quality of a product component while the manufacturing stations are processing these components. Processing in this context means creating, transforming or assembling components.

The product components can be seen as an aggregation of product properties. These properties can be dissected into quality related properties and non‐quality related properties. Each manufacturing station consists of one or more production steps. These steps are directly influencing the product properties by defining, setting or changing them. The quality control station correspondingly consists of testing steps, which are directly

52


measuring the quality related product properties. These quality related properties are in total defining the Product quality. This interrelation was described before in Figure 24.

The before described integrated meta‐model for engineering, product properties and product quality is shown in Figure 26.

Figure 26: Meta‐model for engineering and product quality

53


References

[AQU10a] AQUIMO Konsortium: Aquimo project web page. www.aquimo.de, 15.03.2011.

[AQU10b] AQUIMO Konsortium: Aquimo Adaptierbares Moldellierungswerkzeug und Qualifizierungsprogramm für den Aufbau firmenspezifischer mechatronischer Engineeringprozesse ; ein Leitfaden für Maschinen‐ und Anlagenbauer. VDMA‐Verl, Frankfurt, M, 2010.

[Dra10] Drath, R. Hrsg.: Datenaustausch in der Anlagenplanung mit AutomationML Integration von CAEX, PLCopen XML und COLLADA. Springer, Berlin, 2010.

[DWM08] Drath, R.; Weber, P.; Mauser, N.: An evolutionary approach for the industrial introduction of virtual commissioning. In: 2008 IEEE Conference on Emerging Technologies & Factory Automation. ETFA 2008 ; Hamburg, Germany, 15 ‐ 18 September 2008. IEEE, Piscataway, NJ, 2008.

[Elg07] Elger, J.: Das Internet der Dinge ‐ Der Weg zur modularen Automatisierung. In 25. Dortmunder Gespräche, Bundesvereinigung Logistik in Kooperation/Fraunhofer Institut für Materialfluss und Logistik, 2007.

[Enc11] Encyclopedia Britannica: Engineering. http://www.britannica.com/EBchecked/topic/187549/engineering, 21.03.2011.

[Foe10] Foehr, M.: Wiederverwendungskonzepte für das mechatronische Engineering der Fabrikautomation Diplomarbeit, Magdeburg, 2010.

[Ham11] Hammer, E.: House of Quality (HoQ). http://www‐classic.uni‐graz.at/inmwww/NEU/lehre/pdf/Hammer_House_of_Quality.pdf, 21.03.2011.

[HHM09] Hanisch, H.‐M.; Hirsch, M.; Missal, D.; Preusse, S.; Gerber, C.: One Decade of IEC 61499 Modeling and Verification ‐ Results and Open Issues. In: IFAC ‐ 13th Symposium on Information Control Problems in Manufacturing. INCOM'09; Moscow, Russia; June 3‐ 5, 2009. preprints, 2009; S. 211–216.

[JMG10] Jazdi, N.; Maga, C.; Göhner, P.; Ehben, T.; Tetzner, T.; Löwen, U.: Mehr Systematik für den Anlagenbau und das industrielle Lösungsgeschäft — Gesteigerte Effizienz durch Domain Engineering. In at ‐ Automatisierungstechnik, 2010, 58; S. 524–532.

[Jos00] Jost, P.: Identifizierung von Komponenten für Domänen in der Automatisierungstechnik. In: Fachtagung Verteilte Automatisierung. Magdeburg, 22 ‐ 23 März 2000, 2000.

54


[Jos07] Jost, P.: Evolutionäres Domain‐Engineering zur Entwicklung von Automatisierungssystemen. Shaker; Univ, Aachen, Stuttgart, Stuttgart, 2007.

[Kie07] Kiefer, J.: Mechatronikorientierte Planung automatisierter Fertigungszellen im Bereich Karosserierohbau. Univ. des Saarlandes Lehrstuhl für Fertigungstechnik, Saarbrücken, Saarbrücken, 2007.

[LHF10] Lüder, A.; Hundt, L.; Foehr, M.; Holm, T.; Wagner, T.; Zaddach, J.‐J.: Manufacturing system engineering with mechatronical units. In: 2010 IEEE Conference on Emerging Technologies & Factory Automation. ETFA 2010 ; Bilbao, Spain, 13 ‐ 16 September 2010. IEEE, Piscataway, NJ, 2010; S. 1–8.

[MED10] The MEDEIA Consortium: MEDEIA – Model‐Driven Embedded Systems Design Environment for the Industrial Automation Sector Whitepaper. http://www.medeia.eu/fileadmin/Publications/MEDEIA_WhitePaper_V001_2010‐03‐16.pdf, 15.03.2011.

[MET10] ID‐Consult GmbH: METUS ‐ The System Design Method. http://www.id‐consult.com/metus‐software/, 14.03.2011.

[OLK00] van Ommering, R.; van der Linden, F.; Kramer, J.; Magee, J.: The Koala component model for consumer electronics software. In IEEE Computer Society Press, 2000, 33; S. 78–85.

[PAB08] PABADIS’PROMISE consortium: Industrial Application of the PABADIS’PROMISE System – white paper. www.pabadis‐promise.org, October 2008.

[Sch99] Schnieder, E.: Methoden der Automatisierung Beschreibungsmittel, Modellkonzepte und Werkzeuge für Automatisierungssysteme ; mit 56 Tabellen. Vieweg, Braunschweig, 1999.

[ScS05] Schäppi, B.; Schäppi‐Andreasen‐Kirchgeorg‐Radermacher: Handbuch Produktentwicklung. Hanser, München, 2005.

[SKC02] Shin, J.‐S.; Kim, K.‐J.; Chandra, M. J.: Consistency check of a house of quality chart. In International Journal of Quality & Reliability Management, 2002, 19; S. 471–484.

[SRE08] Strasser, T.; Rooker, M.; Ebenhofer, G.; Hegny, I.; Wenger, M.; Sunder, C.; Martel, A.; Valentini, A.: Multi‐domain model‐driven design of Industrial Automation and Control Systems. In: 2008 IEEE Conference on Emerging Technologies & Factory Automation. ETFA 2008 ; Hamburg, Germany, 15 ‐ 18 September 2008. IEEE, Piscataway, NJ, 2008; S. 1067–1071.

55


[UlE08] Ulrich, K. T.; Eppinger, S. D.: Product design and development. McGraw‐Hill/Irwin, Boston, 2008.

[VDI2206] VDI2206: Entwicklungsmethodik für mechatronische Systeme. Beuth, Berlin, 2004.

[VDI3695] VDI3695: Engineering von Anlagen ‐ Evaluieren und optimieren des Engineerings. Beuth, Berlin, 2009.

[VDI4499‐1] VDI4499 ‐ Blatt 1: Digitale Fabrik ‐ Grundlagen. Beuth, Berlin, 2008.

[VDI4499‐2] VDI4499 ‐ Blatt 2: Digitale Fabrik. Beuth, Berlin, 2009.

[VDI5200] VDI5200: Fabrikplanung ‐ Planungsvorgehen. Beuth, Berlin, 2009.

[WHE10] Wagner, T.; Hausner, C.; Elger, J.; Löwen, U.; Lüder, A.: Engineering Processes for Decentralized Factory Automation Systems. In: Factory automation, INTECH, 2010; S. 1–28.

56

57


Appendix A – GRACE engineering process reference model

document defining the engineering process reference...

Documents