Integration of GRACE multi-agent systems with manufacturing

inteGration of pRocess and quAlity Control using multi-agEnt technology

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

Contract n° NMP2-SL-2010-246203

Project Ref. Number : 246203

Project Start Date : 01/07/2010

Project Duration : 36 months

Website : www.grace-project.org

Document type : Deliverable

Document version : Final

Document Preparation Date : 30/11/2012

Classification : Public

Author(s) : SIEMENS

File Name : Deliverable 4.3 – Integration of GRACE multi-agent systems with manufacturing CAE systems_v1.0.pdf

Work Package 4

Engineering methodology

Deliverable D4.3

Integration of GRACE multi-agent systems with manufacturing CAE systems

Deliverable D4.3 Integration of GRACE multi-agent systems with manufacturing CAE systems

Rev. Content 0.1 Document structure0.2 Adding chapter 2 0.3 Adding chapter 4 0.4 Adding chapter 3 0.5 Adding chapter 5 0.6 Adding Glossary and internal revision0.8 Revision 0.9 Draft of Deliverable available to all partners

for review 1.0 Include review comments and prepare

submission

agent systems with manufacturing CAE systems

Resp. PartnerDocument structure & chapter 1 SIEMENS

SIEMENS SIEMENS SIEMENS SIEMENS

Adding Glossary and internal revision SIEMENS SIEMENS

Draft of Deliverable available to all partners ALL

Include review comments and prepare SIEMENS

2

Resp. Partner Date 15/10/2012 23/10/2012 26/10/2012 12/11/2012 16/11/2012 19/11/2012 21/11/2012 22/11/2012

30/11/2012


Table of contents

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

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

Glossary ................................................................

1. Introduction ................................

2. Concept for engineering tool analysis

2.1. Concept of perspectives

2.1.1. Perspective –



2.2. Applicability of the modeling approach

2.2.1. Definition of process model

2.2.2. Analysis of re-

2.2.3. Analysis of tool chain coverage and continuity

2.2.4. Analysis of lossless information flow

2.3. Consideration of engineering process consistency

2.3.1. Fractions and gaps within engineering processes

2.3.2. Engineering process evaluation

2.4. Tool chain scenarios

2.4.1. Best of bread tools

2.4.2. Integrated tool chain

2.4.3. All-in-one tools

3. Description of selected e

3.1. AutomationML ................................

3.1.1. Tool description

3.1.2. Mechatronical concepts


................................................................................................

................................................................................................

................................................................................................

................................................................................................

Concept for engineering tool analysis ................................................................

of perspectives ................................................................

Engineering Activity Chain ................................................................

Tool chain ................................................................

Information exchange ................................................................

cability of the modeling approach ...............................................................

Definition of process model ................................................................

-use capabilities ................................................................

Analysis of tool chain coverage and continuity ................................

Analysis of lossless information flow ................................................................

Consideration of engineering process consistency ................................

Fractions and gaps within engineering processes ................................

Engineering process evaluation ................................................................

n scenarios .............................................................................................

Best of bread tools ................................................................................................

Integrated tool chain ..............................................................................................

one tools ................................................................................................

Description of selected engineering tools ................................................................

................................................................................................

Tool description ................................................................................................

Mechatronical concepts................................................................

3

........................................................ 3

........................................................... 6

...................................... 9

...................................................... 13

.............................................. 15

....................................................... 15

................................ 17

......................................................... 18

...................................... 18

............................... 19

.................................................... 19

................................................. 20

...................................................... 20

...................................... 20

.............................................. 21

.................................................. 24

.............................................. 27

............................. 32

.................................. 32

.............................. 33

........................................ 33

....................................... 35

..................................... 35

...................................... 35

.......................................................... 38


3.2. Bentley Microstat



3.3. Comos / Automation Designer



3.4. JADE ................................


3.5. NetBeans IDE ................................


3.6. Protégé ................................


3.7. Tecnomatix Plant Simula



3.8. Tecnomatix Process Designer



3.9. Tecnomatix Process Simulate



3.10. Tecnomatix RobCAD



3.11. TIA Portal ................................




Bentley Microstation ............................................................................................



Comos / Automation Designer ................................................................

tion ................................................................................................


................................................................................................


................................................................................................


................................................................................................


Tecnomatix Plant Simulate ................................................................



Tecnomatix Process Designer ................................................................

tion ................................................................................................


Tecnomatix Process Simulate................................................................



Tecnomatix RobCAD .............................................................................................



................................................................................................



4

............................ 40

...................................... 40

.......................................................... 43

............................................. 45

...................................... 45

.......................................................... 50

...................................................... 54

...................................... 54

........................................ 58

...................................... 58

................................................. 61

...................................... 61

................................................... 64

...................................... 64

.......................................................... 71

.............................................. 73

...................................... 73

.......................................................... 77

............................................... 79

...................................... 79

.......................................................... 80

............................. 82

...................................... 82

.......................................................... 88

.............................................. 89

...................................... 89

.......................................................... 91


4. Engineering Tool chain based on general engineering workflow

5. Additional tool requirements for industrial engineering tools supporting GRACE MASarchitecture ................................

5.1. Case studies ................................

5.2. Additional tool requirements

References ................................

Appendix A – Engineering tool evaluation

Appendix B – Modeling examples for engineering tools

Appendix C – Engineering tool chain based on OEM specific engineering workflow

Appendix D – Bearing insertion station

Appendix E – Bearing insertion station


Engineering Tool chain based on general engineering workflow ................................

Additional tool requirements for industrial engineering tools supporting GRACE MAS................................................................................................

................................................................................................

Additional tool requirements ................................................................

................................................................................................................................

Engineering tool evaluation ................................................................

Modeling examples for engineering tools ................................

Engineering tool chain based on OEM specific engineering workflow

Bearing insertion station – Whirlpool documentation ................................

Bearing insertion station – Comos documentation ................................

5

.................................... 93

Additional tool requirements for industrial engineering tools supporting GRACE MAS-...................................................... 95

.......................................... 95

............................................... 96

................................ 98

............................................. 102

....................................................... 103

Engineering tool chain based on OEM specific engineering workflow ........... 104

.................................... 105

......................................... 106


Table of figures

Figure 1: Relations between Engineering process and eng

Figure 2: Intention and goals of GRACE WP 4

Figure 3: Design decision dependability

Figure 4: Engineering artifact flow

Figure 5: Problem location in the engineering process

Figure 6: Possible evaluation of information logistics

Figure 7: AutomationML base architecture

Figure 8: Possible modeling of mechatronical units by AutomationML

Figure 9: Microstation main window

Figure 10: Element parameter example and tool box examples

Figure 11: Cell file management and use

Figure 12: Information sets covered by MS

Figure 13: Cell definition structure

Figure 14: Cell example ................................

Figure 15: Base object structure with project structures

Figure 16: Relation between base object and planning object

Figure 17: Information sets covered by ENGINEERING ARTIFACT

Figure 18: Implementation of engineering artifact within SIMATIC AD

Figure 19: Containers in the JADE Platform

Figure 20: Graphical User Interface of the Remote Monitoring Agent

Figure 21: Graphical User Interface of the Sniffer Agent

Figure 22: Graphical User Interface of the Introspector Agent

Figure 23: Graphical User Interface of the Director Facilitator

Figure 24: NetBeans runtime container (see http://platform.netbeans.org/tutorials/nbm

runtime-container.html) ................................

Figure 25: NetBeans user interface

Figure 26: NetBeans Swing GUI Builder


Figure 1: Relations between Engineering process and engineering artifacts

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

Figure 3: Design decision dependability ................................................................

ineering artifact flow ...........................................................................................

Figure 5: Problem location in the engineering process ...........................................................

Figure 6: Possible evaluation of information logistics .............................................................

Figure 7: AutomationML base architecture ................................................................

sible modeling of mechatronical units by AutomationML ................................

Figure 9: Microstation main window ................................................................

Figure 10: Element parameter example and tool box examples ................................

Figure 11: Cell file management and use ................................................................

formation sets covered by MS ................................................................

Figure 13: Cell definition structure ................................................................

................................................................................................

Figure 15: Base object structure with project structures ................................

Figure 16: Relation between base object and planning object ................................

Figure 17: Information sets covered by ENGINEERING ARTIFACT ................................

Figure 18: Implementation of engineering artifact within SIMATIC AD ................................

Figure 19: Containers in the JADE Platform ................................................................

Graphical User Interface of the Remote Monitoring Agent ................................

Figure 21: Graphical User Interface of the Sniffer Agent ................................

Figure 22: Graphical User Interface of the Introspector Agent ................................

Figure 23: Graphical User Interface of the Director Facilitator ................................


................................................................................................

Figure 25: NetBeans user interface ................................................................

: NetBeans Swing GUI Builder ................................................................

6

ineering artifacts .......................... 10

.......................................... 13

.................................................. 16

........................... 22

........................... 24

............................. 25

............................................. 36

.................................. 39

....................................................... 41

............................................. 42

................................................. 42

............................................. 43

.......................................................... 44

............................................ 45

........................................................ 46

............................................... 47

........................................... 51

.................................. 53

............................................. 55

................................... 56

......................................................... 56

............................................... 57

............................................... 57

Figure 24: NetBeans runtime container (see http://platform.netbeans.org/tutorials/nbm-

.......................................... 58

.......................................................... 59

................................................... 60


Figure 27: NetBeans project structure

Figure 28: Screenshot of the Protégé editor

Figure 29: Details of the Protégé editor

Figure 30: Protégé architecture diagram related to the 3.x series of Protégé

Figure 31: Use of Tecnomatix Plant Simulate in Engineering Phases

Figure 32:Windows for variables and methods of objects

Figure 33: Attribute configuration of moveable objects

Figure 34: Attribute configuration of material flow objects

Figure 35: Class library example

Figure 36: Network example ................................

Figure 37: Information sets reflected by Tecnomatix Plant Simulate

Figure 38: Basic Implementation for Mechatronical Units in TPS

Figure 39: Software architecture of PD

Figure 40: PD user interface ................................

Figure 41: PD library example

Figure 42: Information sets of engineering artifact covered by PD

Figure 43: Example of a engineering artifactin PD

Figure 44: Tecnomatix Process Designer software structure

Figure 45: information sets covered by PS

Figure 46: engineering artifact implementation in PS

Figure 47: Geometry modeling in RobCAD

Figure 48: Kinematics editor ................................

Figure 49: Behavior modeling

Figure 50: Main modeling objects of RobCAD

Figure 51: Basic work cell ................................

Figure 52: Robot examples ................................

Figure 53: Controller example in RobCAD

Figure 54: engineering artifact information representation in RobCAD

Figure 55: Start window of TIA Portal

Figure 56: Information sets covered by TIA Portal


Figure 27: NetBeans project structure ................................................................

Figure 28: Screenshot of the Protégé editor ................................................................

Details of the Protégé editor ................................................................

Figure 30: Protégé architecture diagram related to the 3.x series of Protégé

Figure 31: Use of Tecnomatix Plant Simulate in Engineering Phases ................................

Figure 32:Windows for variables and methods of objects ................................

nfiguration of moveable objects ................................

Figure 34: Attribute configuration of material flow objects ................................

Figure 35: Class library example ...............................................................................................

................................................................................................

Figure 37: Information sets reflected by Tecnomatix Plant Simulate ................................

Figure 38: Basic Implementation for Mechatronical Units in TPS ................................

Figure 39: Software architecture of PD ................................................................

................................................................................................

................................................................................................

Figure 42: Information sets of engineering artifact covered by PD ................................

Figure 43: Example of a engineering artifactin PD ................................................................

ure 44: Tecnomatix Process Designer software structure ................................

Figure 45: information sets covered by PS................................................................

Figure 46: engineering artifact implementation in PS .............................................................

Figure 47: Geometry modeling in RobCAD ................................................................

................................................................................................

................................................................................................

Figure 50: Main modeling objects of RobCAD ................................................................

................................................................................................

................................................................................................

Figure 53: Controller example in RobCAD ................................................................

Figure 54: engineering artifact information representation in RobCAD ................................

Figure 55: Start window of TIA Portal ................................................................

rmation sets covered by TIA Portal ................................................................

7

..................................................... 61

............................................ 62

................................................... 63

Figure 30: Protégé architecture diagram related to the 3.x series of Protégé ........................ 64

...................................... 65

...................................................... 66

......................................................... 67

.................................................... 68

............................... 70

.................................... 71

..................................... 72

........................................... 73

.................................................... 74

..................................... 76

.................................. 77

......................................... 78

................................... 79

.................................................. 79

............................................... 81

............................. 81

.............................................. 83

.................................... 84

.................................. 85

......................................... 86

......................................... 86

....................................... 87

................................................ 88

................................. 89

...................................................... 90

.................................. 91


Figure 57: engineering artifact structure in TIA Portal

Figure 58: Engineering tool chain based on general engineering workflow


Figure 57: engineering artifact structure in TIA Portal ............................................................

Figure 58: Engineering tool chain based on general engineering workflow ...........................

8

............................ 92

........................... 94


Glossary

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

Domain - An area of knowledge that

(1) is scoped to maximize the satisfaction of the requirements of its stakeholders,

(2) includes a set of concepts and terminology understood by practitioners in that area and

(3) includes the knowledge of how to build (software) systems in that area

Engineering – Following 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 operate the same with full cognizance of their design; or to forecast their bspecific operating conditions; all as respects an intended function, economics of operation and safety to life and property.”

Engineering process – An engineeriactions. It is divided into a set of phases targeting different levels of detail and concreteness of the engineering objects.

Mechatronic engineering process process where the involved engineering objects are mechatronic units and mechatronic systems.

Engineering artifact – An engineering more actions of an engineering process. Within early phases of engineering processes engineering artifacts are usually of informational nature while in later phases they can also be of physical nature.


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

An area of knowledge that

is scoped to maximize the satisfaction of the requirements of its stakeholders,

includes a set of concepts and terminology understood by practitioners in that area and

includes the knowledge of how to build (software) systems in that area

Following (Encyclopedia Britannica 2011) engineering is “tapplication of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct operate the same with full cognizance of their design; or to forecast their bspecific operating conditions; all as respects an intended function, economics of operation and safety to life and property.”

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

Mechatronic engineering process – A mechatronic engineering process is an engineering process where the involved engineering objects are mechatronic units and mechatronic

An engineering artifact is an object created or used within one or engineering process. Within early phases of engineering processes

s are usually of informational nature while in later phases they can also

9

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

is scoped to maximize the satisfaction of the requirements of its

includes a set of concepts and terminology understood by practitioners in

includes the knowledge of how to build (software) systems in that area

engineering is “the creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation

ng process is a coordinated course of knowledge use actions. It is divided into a set of phases targeting different levels of detail and concreteness

A mechatronic engineering process is an engineering process where the involved engineering objects are mechatronic units and mechatronic

is an object created or used within one or engineering process. Within early phases of engineering processes

s are usually of informational nature while in later phases they can also


Figure 1: Relations between Engineering process and engineering

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

Manufacturing Industry -of geometric determined solid bodies (workpiece, assembly group, products) with preset attributes by application of various manufacturing methods.

Mechatronic system - A mechatronic system is a closed actuating elements, its sensor system and its control a defined (usually physical) bwithin a manufacturing system. It is composed of one or more mechatronic units and may be processed like a mechatronic unit during the e

Mechatronic engineering activity engineering activity) is an action within the mechatronic engineering process. It is assigned to one or more phases of the engineering process, executed by one invorole, and has impact on the design of a mechatronic system or unit.

Mechatronic modeling concept mechatronic systems or units to plant components or facets by structure and relations

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.


Relations between Engineering process and engineering

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

- Task and aim of manufacturing engineering is the producof geometric determined solid bodies (workpiece, assembly group, products) with preset

of various manufacturing methods.

A mechatronic system is a closed system that realizes by its actuating elements, its sensor system and its control a defined (usually physical) bwithin a manufacturing system. It is composed of one or more mechatronic units and may be processed like a mechatronic unit during the engineering.

Mechatronic engineering activity - A mechatronic engineering activity () is an action within the mechatronic engineering process. It is assigned

to one or more phases of the engineering process, executed by one invorole, and has impact on the design of a mechatronic system or unit.

Mechatronic modeling concept - A mechatronic modeling concept is an approach to map mechatronic systems or units to plant components or facets by structure and relations

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.

10

Relations between Engineering process and engineering artifacts

An engineering tool is a software system designed to model, process,

aim of manufacturing engineering is the production of geometric determined solid bodies (workpiece, assembly group, products) with preset

system that realizes by its actuating elements, its sensor system and its control a defined (usually physical) behavior within a manufacturing system. It is composed of one or more mechatronic units and may be

A mechatronic engineering activity (general ) 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

A mechatronic modeling concept is an approach to map mechatronic systems or units to plant components or facets by structure and relationship.

A mechatronic unit (plant component) is a mechatronic system that can be described by its functionality and is composed of software (control) and


Model - A model is a representation of a realthree 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 havejust those, which seem to be relevant to the model user or creator.

(3) Intended purpose. Creating a model has always a purpose defined byintended use of the model.aspects.

A model is featured by abstractionstress model features important for the modeler or for the model intention.

Modules – In the context of this deliverable understood as a collective term to describe the entirety of both agents and mechatronic units. This is done to cover all application cases e.g. agents interacting with agents, agents interacting with mechatronic units, vice versa and mechatronic units imechatronic units.

Plant - Plants are large assemblies of technical devices to produce certain technical products usually in a fully or semiwhich produce the technical products from se

Plant components - Reusable unit, which is completed and encapsulated, with defined interfaces to the outside. A component is an aggregation of building blocks.

The following terms of multiPolitécnico de Bragança 2011):

Agent - An autonomous component, that represents physical or logical objects in the system, capable to act in order to achieve its goals, and being able to interact with other agents, when it doesn’t possess

Distributed Control System (DCS) processes that are continuous or batchactuators, normally through Programmable Logic Controllers (PLCs) and use setto control the flow of material through the plant.


A model is a representation of a real system or a couple of systems. Models have

Representation. A model is always a representation of natural and artificial originals which could be models, too.

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.

Intended purpose. Creating a model has always a purpose defined byintended use of the model. The usage defines the model

A model is featured by abstraction which means the conscious reduction of stress model features important for the modeler or for the model intention.

In the context of this deliverable the use of the word module understood as a collective term to describe the entirety of both agents and mechatronic

. This is done to cover all application cases e.g. agents interacting with agents, agents interacting with mechatronic units, vice versa and mechatronic units i

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.

Reusable unit, which is completed and encapsulated, with defined interfaces to the outside. A component is an aggregation of building blocks.

The following terms of multi-agent-systems are defined according toPolitécnico de Bragança 2011):

An autonomous component, that represents physical or logical objects in the system, capable to act in order to achieve its goals, and being able to interact with other agents, when it doesn’t possess knowledge and/or skills to reach its objectives on its own.

Distributed Control System (DCS) - A dedicated system used to control manufacturing processes that are continuous or batch-oriented. DCSs are connected to sensors and

Programmable Logic Controllers (PLCs) and use setto control the flow of material through the plant.

11

systems. Models have

Representation. A model is always a representation of natural and artificial

all attributes and aspects of the original, just those, which seem to be relevant to the model user or creator.

Intended purpose. Creating a model has always a purpose defined by the relevant parts and

he conscious reduction of reality to stress model features important for the modeler or for the model intention.

the use of the word module should be understood as a collective term to describe the entirety of both agents and mechatronic

. This is done to cover all application cases e.g. agents interacting with agents, agents interacting with mechatronic units, vice versa and mechatronic units interacting with

Plants are large assemblies of technical devices to produce certain technical automatic way. Plants execute technological processes

Reusable unit, which is completed and encapsulated, with defined interfaces to the outside. A component is an aggregation of building blocks.

systems are defined according to (Instituto

An autonomous component, that represents physical or logical objects in the system, capable to act in order to achieve its goals, and being able to interact with other

knowledge and/or skills to reach its objectives on its own.

A dedicated system used to control manufacturing oriented. DCSs are connected to sensors and

Programmable Logic Controllers (PLCs) and use set-point control


Holon - An identifiable part of a (manufacturing) system that has a unique identity, yet is made up of sub-ordinate parts and in turn is par

Multi-agent systems (MAS) that interact with each other to reach the system objectives.

Moby - is an electronic RFiD tag attached to the pallet carrying the products along thproduction line, identifying univocally each product. The tag contains information that can be accessed by a RFiD reader.

Product - In the sense of this work, a product is not only related to final products commercialized by OEM companies, but also intecomplex products. Examples of products are washing machines or drums.

Computer-aided Engineering (CAE)engineering tasks. It includes computercomputer-integrated manufacturing (CIM), computerrequirements planning (MRP), and computer

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


An identifiable part of a (manufacturing) system that has a unique identity, yet is ordinate parts and in turn is part of a larger whole.

agent systems (MAS) - Society of agents that represent the objects of a system that interact with each other to reach the system objectives.

is an electronic RFiD tag attached to the pallet carrying the products along thproduction line, identifying univocally each product. The tag contains information that can be accessed by a RFiD reader.

In the sense of this work, a product is not only related to final products commercialized by OEM companies, but also intermediate parts/components that comprise complex products. Examples of products are washing machines or drums.

aided Engineering (CAE) - is the broad usage of computer software to aid in engineering tasks. It includes computer-aided design (CAD), computer-aided analysis (CAA),

integrated manufacturing (CIM), computer-aided manufacturing (CAM), material requirements planning (MRP), and computer-aided planning (CAP).

An activity is a task that needs to be accomplished within a defined

12

An identifiable part of a (manufacturing) system that has a unique identity, yet is

Society of agents that represent the objects of a system

is an electronic RFiD tag attached to the pallet carrying the products along the production line, identifying univocally each product. The tag contains information that can

In the sense of this work, a product is not only related to final products rmediate parts/components that comprise

is the broad usage of computer software to aid in aided analysis (CAA),

aided manufacturing (CAM), material

An activity is a task that needs to be accomplished within a defined


1. Introduction

The Deliverable 4.3 is the Within this work package the suitability of typical industrial CAEautomation will be evaluated. can be foreseen and additional tool requirements may be identified. This will be done within three steps:

· Comparison of developed engineering manufacturing systems to available engineering concepts of selected CAE tools

· Derivation of (additional) requirements to CAE tool concepts

· Prototypical implementation of interfaces of CAE tools to GRACE platform enabling generation of configuration data for GRACE production process control and quality control

Figure

Within task 4.1 a general systems was defined, which production lines or home appliance production lines. It was thentowards a detailed GRACE specific linesincluding process and quality control.

· dissecting the engineering of the production line in its phases

§ Identify impact of GRACE control concepts on manufacturing engin§ Create suitable and effective engineering concepts for decentral§ Render them applicable for industrial applications

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


is the last output of work package 4 “Engineering methodology”. the suitability of typical industrial CAE tools for modular factory

automation will be evaluated. Thus, a tool chain for the GRACE engineering methodology can be foreseen and additional tool requirements may be identified. This will be done within

Comparison of developed engineering methodology for decentralized manufacturing systems to available engineering concepts of selected CAE tools

Derivation of (additional) requirements to CAE tool concepts

Prototypical implementation of interfaces of CAE tools to GRACE platform ation of configuration data for GRACE production process control

and quality control

Figure 2: Intention and goals of GRACE WP 4

general engineering process reference model for manufacturing , which was developed and evaluated for domain

or home appliance production lines. It was then adapted and extended GRACE specific engineering process for home appliance production

ding process and quality control. The model was created by

the engineering of the production line in its phases,

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

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

13

output of work package 4 “Engineering methodology”. tools for modular factory

Thus, a tool chain for the GRACE engineering methodology can be foreseen and additional tool requirements may be identified. This will be done within

methodology for decentralized manufacturing systems to available engineering concepts of selected CAE tools

Prototypical implementation of interfaces of CAE tools to GRACE platform ation of configuration data for GRACE production process control

engineering process reference model for manufacturing domains like automotive

adapted and extended engineering process for home appliance production

eering activitiesized automation

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


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

· identification of their relationproperties of the process

This model and especially the general engineering activities will serve as a basis for the tool evaluation

Like the previous deliverables of WP 4 also Deliverable 4.3 The intention is to present the general results within a public part, but to deepen the analysis in parallel within the confidential

With the help of this bisection GRACE project will provide CAE tools regarding the GRACE use confidential information of the consoresults.

This document is structured as follows. already introduced as an important describe how these activities can be used for the evaluation of engineering toolschapter 3 we will give an introduction to twelve CAE tools respectively data platforms used within the engineering tool chain. Additionally the tools will be evaluated regarding their coverage of mechatronical data as presented in Deliverable 4.2.

Chapter 4 will show how these tools may be applied as part of a tool chain at the general engineering workflow presented in Deliverable 4.2.

Based on these results chapter 5 will present additionthe analysis.

Within Appendix A a detailed analysis of the industrial CAE tools will be shown based on the general engineering activities presented in Deliverable 4.1. Appendix B will deepen the tool understanding by showing typical modeling examples Appendixes A and B will complete the tool analysis carried out in chapter 3.

Respectively, Appendix C will complete the tool chain analysis by applying the tools to the OEM specific engineering w

As a last part the Appendixes D and E will provide insights to the modeling of the bearing insertion station of the washing unit production line of Whirlpool in Naples. Appendix D will show which results were used to the results of the reengineering of the production line within between a typical all-in-one industrial CAE tool and the GRACE architecture will be shown by reengineering this part of the production line based on the GRACE engineering methodology.

Additional interfaces / influences of industrial CAE tools manufacturing system can be also found within the tool descriptions and the the general engineering activities for each tool.interface between GRACE MAS and Labview® or GRACE MAS and GraDaCo database will be shown in more detail within deliverable 5.1.


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

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

especially the general engineering activities presented in Deliverable 4.1 tool evaluation presented within this deliverable

the previous deliverables of WP 4 also Deliverable 4.3 will be divided in two parts. to present the general results within a public part, but to deepen the

ithin the confidential appendixes.

With the help of this bisection GRACE project will provide a public suitability analysis of CAE tools regarding the GRACE engineering methodology. In Addition the Appendixes will use confidential information of the consortium partners for further discussion of these

This document is structured as follows. The concept of general engineering activities important prerequisite within deliverable 4.2

ivities can be used for the evaluation of engineering toolschapter 3 we will give an introduction to twelve CAE tools respectively data platforms used within the engineering tool chain. Additionally the tools will be evaluated regarding their

rage of mechatronical data as presented in Deliverable 4.2.

Chapter 4 will show how these tools may be applied as part of a tool chain at the general engineering workflow presented in Deliverable 4.2.

Based on these results chapter 5 will present additional tool requirements derived from

Within Appendix A a detailed analysis of the industrial CAE tools will be shown based on the general engineering activities presented in Deliverable 4.1. Appendix B will deepen the

ing typical modeling examples for some of these tools. Thus, Appendixes A and B will complete the tool analysis carried out in chapter 3.

Respectively, Appendix C will complete the tool chain analysis by applying the tools to the OEM specific engineering workflow presented in Deliverable 4.2 - Appendix A.

As a last part the Appendixes D and E will provide insights to the modeling of the bearing insertion station of the washing unit production line of Whirlpool in Naples. Appendix D will

ere used to engineer the station for the first time. Appendix E will show the results of the reengineering of the production line within COMOS

one industrial CAE tool and the GRACE architecture will be shown by engineering this part of the production line based on the GRACE engineering methodology.

Additional interfaces / influences of industrial CAE tools with / to GRACE based modular manufacturing system can be also found within the tool descriptions and the the general engineering activities for each tool. Special interfaces used within GRACE e.g. the interface between GRACE MAS and Labview® or GRACE MAS and GraDaCo database will be shown in more detail within deliverable 5.1.

14

of the working processes (e.g., layout planning) within the

s, and influences (causes and effects) with system

presented in Deliverable 4.1 presented within this deliverable D4.3.

will be divided in two parts. to present the general results within a public part, but to deepen the

suitability analysis of In Addition the Appendixes will

rtium partners for further discussion of these

general engineering activities was within deliverable 4.2. Chapter 2 will

ivities can be used for the evaluation of engineering tools. Within chapter 3 we will give an introduction to twelve CAE tools respectively data platforms used within the engineering tool chain. Additionally the tools will be evaluated regarding their

Chapter 4 will show how these tools may be applied as part of a tool chain at the general

al tool requirements derived from

Within Appendix A a detailed analysis of the industrial CAE tools will be shown based on the general engineering activities presented in Deliverable 4.1. Appendix B will deepen the

for some of these tools. Thus, Appendixes A and B will complete the tool analysis carried out in chapter 3.

Respectively, Appendix C will complete the tool chain analysis by applying the tools to Appendix A.

As a last part the Appendixes D and E will provide insights to the modeling of the bearing insertion station of the washing unit production line of Whirlpool in Naples. Appendix D will

the station for the first time. Appendix E will show COMOS. Thus, interfaces

one industrial CAE tool and the GRACE architecture will be shown by engineering this part of the production line based on the GRACE engineering methodology.

with / to GRACE based modular manufacturing system can be also found within the tool descriptions and the evaluation of

Special interfaces used within GRACE e.g. the interface between GRACE MAS and Labview® or GRACE MAS and GraDaCo database will be


2. Concept for engineering tool analysisWithin this chapter the idea of an analysis method for tool evaluation based on

engineering workflows will be shown. The method itself has been used by Siemens Corporate Technology more than a hundred times to evaluate tool suitabilitycustomer use cases. As the methodology contains highly confidential knowledge and intellectual property, only the basic idea will be shown. Additionally three typical tool scenarios will be discussed.

2.1. Concept of perspectivesThe following section will present a set of perspectives on engineering processes relevant

for their evaluation and optimization

The engineering process of production systems is executed within an engineering organization and consists, usually, of a set of design decis(Helmus 2003),(Grundig 2009)

VDI Guideline 3695 (VDI 3695)firm or engineering subunit of a company (supplier, plant manufacturer, plant operator) executing one or more engineering processes. A project team cooperating for a limited time (also across companies) is also regarded to be an EO.

VDI Guideline 3695 additionally states, that for an EO there are key aspects of relevance related to the quality of an EO. The mostthe workflow, the methods used, the tools, the organizational structure, and the economics.

To capture the structure and behavior of an EO the procedure model of the EO can be exploited. The procedure mengineering activities taking the necessary design decisions to incrementally enrich the intended technical solution, the required input and output information for the design decisions, tools to be used, and respective responsible human roles. It formalizes the engineering process and examines the technical content of an EO’s process. The use of a procedure model thus facilitates a structured engineering process, which optimizes the engineering and data workflow and the resource utilization. Besides the technical tasks, a procedure model should also describe activities in project management, quality control, change management as well as verification and validation of the engineering solution.

For the appropriate execution of the design decisions within the engineering process a set of preconditions have to be fulfilled. These preconditions include:

· the availability of the required input information for the decision activity in the required quality at t

· the execution of the design decision by a team of well trained and skilled persons, and

· the adequate tool support for the efficient execution of the design decision.


eering tool analysis Within this chapter the idea of an analysis method for tool evaluation based on

engineering workflows will be shown. The method itself has been used by Siemens Corporate Technology more than a hundred times to evaluate tool suitabilitycustomer use cases. As the methodology contains highly confidential knowledge and intellectual property, only the basic idea will be shown. Additionally three typical tool

of perspectives tion will present a set of perspectives on engineering processes relevant

evaluation and optimization.

The engineering process of production systems is executed within an engineering organization and consists, usually, of a set of design decisions which have to be taken

(Grundig 2009).

(VDI 3695) defines an Engineering Organization (EO) is an engineering firm or engineering subunit of a company (supplier, plant manufacturer, plant operator)

engineering processes. A project team cooperating for a limited time (also across companies) is also regarded to be an EO.

VDI Guideline 3695 additionally states, that for an EO there are key aspects of relevance related to the quality of an EO. The most relevant key aspects from authors point of view are the workflow, the methods used, the tools, the organizational structure, and the economics.

To capture the structure and behavior of an EO the procedure model of the EO can be exploited. The procedure model of an engineering process determines a sequence of engineering activities taking the necessary design decisions to incrementally enrich the intended technical solution, the required input and output information for the design

ed, and respective responsible human roles. It formalizes the engineering process and examines the technical content of an EO’s process. The use of a procedure model thus facilitates a structured engineering process, which optimizes the

a workflow and the resource utilization. Besides the technical tasks, a procedure model should also describe activities in project management, quality control, change management as well as verification and validation of the engineering solution.

appropriate execution of the design decisions within the engineering process a set of preconditions have to be fulfilled. These preconditions include:

the availability of the required input information for the decision activity in the required quality at the right moment,

the execution of the design decision by a team of well trained and skilled persons,

the adequate tool support for the efficient execution of the design decision.

15

Within this chapter the idea of an analysis method for tool evaluation based on engineering workflows will be shown. The method itself has been used by Siemens Corporate Technology more than a hundred times to evaluate tool suitability for special customer use cases. As the methodology contains highly confidential knowledge and intellectual property, only the basic idea will be shown. Additionally three typical tool

tion will present a set of perspectives on engineering processes relevant

The engineering process of production systems is executed within an engineering ions which have to be taken

defines an Engineering Organization (EO) is an engineering firm or engineering subunit of a company (supplier, plant manufacturer, plant operator)

engineering processes. A project team cooperating for a limited time

VDI Guideline 3695 additionally states, that for an EO there are key aspects of relevance relevant key aspects from authors point of view are

the workflow, the methods used, the tools, the organizational structure, and the economics.

To capture the structure and behavior of an EO the procedure model of the EO can be odel of an engineering process determines a sequence of

engineering activities taking the necessary design decisions to incrementally enrich the intended technical solution, the required input and output information for the design

ed, and respective responsible human roles. It formalizes the engineering process and examines the technical content of an EO’s process. The use of a procedure model thus facilitates a structured engineering process, which optimizes the

a workflow and the resource utilization. Besides the technical tasks, a procedure model should also describe activities in project management, quality control, change management as well as verification and validation of the engineering solution.

appropriate execution of the design decisions within the engineering process a

the availability of the required input information for the decision activity in the

the execution of the design decision by a team of well trained and skilled persons,

the adequate tool support for the efficient execution of the design decision.


Within an EO design decisions have to be taken reflecting the incrementalthe technical solution by knowledge and skill use. These design decisions are part of engineering activities. For each engineering activity the following conditions will hold: enable the execution of the engineering activity a (possibly eengineering activities have to be finished, special information have to be available, appropriate engineering tools should be useable. Humans with the required skills and knowledge should execute the engineering activities. The enginformation reflecting the taken design decisions and provide them for a (possibly empty) set of successor design decisions within further engineering activities. This structure is depicted in the following Figure

Figure

Thus an engineering process can be seen from different positions facing the different requirements to the design decision to be taken. This can be reflected by the term of a perspective on an engineering process.

A perspective on an engineering processor further aspect of an engineering process covering the comprocess. It subsumes all process objects within an engineering process related to the considered aspect. Thus, a perspective on an engineering process has to be seen as the set of required process objects of a defined obje(set of object types) defines the considers aspect of the engineering process execution describing needs for an efficient and correct execution of the engineering process. Perspectives do not need to be di

Following this definition a perspective on an engineering process can be defined by the process objects covered by this perspective. Thus, within different engineering organizations there might be different perspectives following the different bordering conditions for engineering processes. Nevertheless, there are some perspectives which are common for all engineering processes. in the next subsections.

Predecessordesign decisions

Information required


Within an EO design decisions have to be taken reflecting the incrementalthe technical solution by knowledge and skill use. These design decisions are part of engineering activities. For each engineering activity the following conditions will hold: enable the execution of the engineering activity a (possibly empty) set of predecessor engineering activities have to be finished, special information have to be available, appropriate engineering tools should be useable. Humans with the required skills and knowledge should execute the engineering activities. The engineering activity will create information reflecting the taken design decisions and provide them for a (possibly empty) set of successor design decisions within further engineering activities. This structure is

Figure 3.

Figure 3: Design decision dependability

Thus an engineering process can be seen from different positions facing the different design decision to be taken. This can be reflected by the term of a

perspective on an engineering process.

perspective on an engineering process models one structural, organizational, technical or further aspect of an engineering process covering the complete lifecycle of an engineering process. It subsumes all process objects within an engineering process related to the considered aspect. Thus, a perspective on an engineering process has to be seen as the set of required process objects of a defined object type (set of object types) were the object type (set of object types) defines the considers aspect of the engineering process execution describing needs for an efficient and correct execution of the engineering process. Perspectives do not need to be disjunctive.

Following this definition a perspective on an engineering process can be defined by the process objects covered by this perspective. Thus, within different engineering organizations there might be different perspectives following the different industrial fields and its different bordering conditions for engineering processes. Nevertheless, there are some perspectives which are common for all engineering processes. Three of these perspectives are the given

Design decision(engineering activity to

be executed)

Humans with the rightskills and knowledge

Engineering tools Successor design decisions

decisions

Information Information created

16

Within an EO design decisions have to be taken reflecting the incremental enrichment of the technical solution by knowledge and skill use. These design decisions are part of engineering activities. For each engineering activity the following conditions will hold: to

mpty) set of predecessor engineering activities have to be finished, special information have to be available, appropriate engineering tools should be useable. Humans with the required skills and

ineering activity will create information reflecting the taken design decisions and provide them for a (possibly empty) set of successor design decisions within further engineering activities. This structure is

Thus an engineering process can be seen from different positions facing the different design decision to be taken. This can be reflected by the term of a

models one structural, organizational, technical plete lifecycle of an engineering

process. It subsumes all process objects within an engineering process related to the considered aspect. Thus, a perspective on an engineering process has to be seen as the set of

ct type (set of object types) were the object type (set of object types) defines the considers aspect of the engineering process execution describing needs for an efficient and correct execution of the engineering process.

Following this definition a perspective on an engineering process can be defined by the process objects covered by this perspective. Thus, within different engineering organizations

industrial fields and its different bordering conditions for engineering processes. Nevertheless, there are some perspectives

of these perspectives are the given

Information


The use of the perspectives and its semantics within an engineering process analysis depends on the application case. Examples for the semantic use are given in the following Chapter 3.

2.1.1. Perspective

The perspective “Engineering Activity Chain”engineering process related to the sequence of necessary engineering activities for the intended engineering result. Thus, it covers among others

· the engineering activities itself with the design decisions taken within,

· the predecessor-successor

· the timing requirements of the engineering activities like minimal and maximal duration or earliest and latest starting and end point.

In addition this perspective has relations to the otheHere it will be especially relevant:

· which engineering tools should be used for the execution of the design decisions, and

· which engineering artifacts are required for the execution for the design decisions and which are created during the design decisions.

For the analysis of this perspective the following table can be exploited:

Activity Name of the activity

Description Short description of the design decisions engineering activity

Timing Definition of durations, start time and end time of the activity Predecessor activities Activities creating the engineering artifacts required for the activity

Successor activities Activities requiring the activity

Involved human resources

Description of required engineering roles with competences, knowledge, and skills required for the execution of the engineering activity

Exploited tools Description of of the engineering activity

Required artifacts Description of engineering artifacts required for the execution of the engineering activity

Created artifacts Description of engineering artifacts of the engineering activity


perspectives and its semantics within an engineering process analysis depends on the application case. Examples for the semantic use are given in the following

Perspective – Engineering Activity Chain

The perspective “Engineering Activity Chain” subsumes all process objects of an engineering process related to the sequence of necessary engineering activities for the intended engineering result. Thus, it covers among others

the engineering activities itself with the design decisions taken within,

successor-relation of engineering activities, and

the timing requirements of the engineering activities like minimal and maximal duration or earliest and latest starting and end point.

In addition this perspective has relations to the other perspectives named in this chapter. Here it will be especially relevant:

which engineering tools should be used for the execution of the design decisions,

which engineering artifacts are required for the execution for the design decisions re created during the design decisions.


Table 1: Activity perspective

Name of the activity

Short description of the design decisions taken within the engineering activity Definition of durations, start time and end time of the activity

Activities creating the engineering artifacts required for the activity

Activities requiring the engineering artifacts developed within the activity Description of required engineering roles with competences, knowledge, and skills required for the execution of the engineering activity Description of engineering tools usable or required for the execution of the engineering activity Description of engineering artifacts required for the execution of the engineering activity Description of engineering artifacts developed within the execution of the engineering activity

17

perspectives and its semantics within an engineering process analysis depends on the application case. Examples for the semantic use are given in the following

subsumes all process objects of an engineering process related to the sequence of necessary engineering activities for the

the engineering activities itself with the design decisions taken within,

relation of engineering activities, and

the timing requirements of the engineering activities like minimal and maximal

r perspectives named in this chapter.

which engineering tools should be used for the execution of the design decisions,

which engineering artifacts are required for the execution for the design decisions


taken within the

Definition of durations, start time and end time of the activity


engineering artifacts developed within the

Description of required engineering roles with competences, knowledge, and skills required for the execution of the engineering

engineering tools usable or required for the execution

Description of engineering artifacts required for the execution of the

developed within the execution


2.1.2. Perspective

The perspective “Tool chain” subsumes all process objects of an engineering process related to the sequence of engineering tools used for the execution of the intended engineering activities. Thus it covers among others

· the type of the engineering tools required,

· the input and output artifacts consumed or created by the engineering tool,

· the data formats consumable or producible by the tool and

· the skills and knowledge r


Tool Name of the toolDescription Short description of the toolTool type Give the category of tools the tool belongs Involved human resources

Description of engineering roles with competences, knowledge, and skills required for use of the tool

Required artifacts Description of engineering artifacts consumable by the toolCreated artifacts Description of engineeringInput formats Name data formats consumable by the tool or input technology usedOutput formats Name data formats created by the tool or output technology used

2.1.3. Perspective

The perspective “Information exchange” subsumes all process objects of an engineering process related to the exchange of engineering artifacts between different engineering tools along the tool chain, different human resources within the engineering organization, and among different engineering activities. These process objects can be of virtual nature (i.e. information coded within IT artifacts) or physical nature (parts of the physical system implementation). Thus this perspective can be described by naming the engineeriexchanged including

· the type and semantics of the artifact exchanged,

· the data format and/or technology used for the artifact exchange

· the tools able to create the artifacts,

· the tools able to load and use the artifacts,

1Thetechnologiesaddressedherecanhaveaverybroadrangefromdefinitionoffiletypesovercharacterizationofdatabasetypes,usedXMLschema,andexploitedcommunicationprotocolsuptocommunicationarchitectOPC.


Perspective – Tool chain

The perspective “Tool chain” subsumes all process objects of an engineering process related to the sequence of engineering tools used for the execution of the intended engineering activities. Thus it covers among others

the type of the engineering tools required,

the input and output artifacts consumed or created by the engineering tool,

the data formats consumable or producible by the tool and

the skills and knowledge required .


Table 2: tool perspective

Name of the tool Short description of the tool Give the category of tools the tool belongs to Description of engineering roles with competences, knowledge, and skills required for use of the tool Description of engineering artifacts consumable by the toolDescription of engineering artifacts developed by the toolName data formats consumable by the tool or input technology usedName data formats created by the tool or output technology used

Perspective – Information exchange

“Information exchange” subsumes all process objects of an engineering process related to the exchange of engineering artifacts between different engineering tools along the tool chain, different human resources within the engineering organization, and

g different engineering activities. These process objects can be of virtual nature (i.e. information coded within IT artifacts) or physical nature (parts of the physical system implementation). Thus this perspective can be described by naming the engineeri

the type and semantics of the artifact exchanged,

the data format and/or technology used for the artifact exchange

the tools able to create the artifacts,

the tools able to load and use the artifacts,

Thetechnologiesaddressedherecanhaveaverybroadrangefromdefinitionoffiletypesovercharacterizationofdatabasetypes,usedXMLschema,andexploitedcommunicationprotocolsuptocommunicationarchitect

18

The perspective “Tool chain” subsumes all process objects of an engineering process related to the sequence of engineering tools used for the execution of the intended

the input and output artifacts consumed or created by the engineering tool,


Description of engineering roles with competences, knowledge, and

Description of engineering artifacts consumable by the tool artifacts developed by the tool

Name data formats consumable by the tool or input technology used Name data formats created by the tool or output technology used

“Information exchange” subsumes all process objects of an engineering process related to the exchange of engineering artifacts between different engineering tools along the tool chain, different human resources within the engineering organization, and

g different engineering activities. These process objects can be of virtual nature (i.e. information coded within IT artifacts) or physical nature (parts of the physical system implementation). Thus this perspective can be described by naming the engineering artifacts

the data format and/or technology used for the artifact exchange1,

Thetechnologiesaddressedherecanhaveaverybroadrangefromdefinitionoffiletypesovercharacterizationofdatabasetypes,usedXMLschema,andexploitedcommunicationprotocolsuptocommunicationarchitectureslike


· the humans and its skills and knowledge required to create and use the artifacts.


Artifact Name of the artifactDescription Short description of the artifactType of artifact Give the category of artifact, the artifact belongs toSemantics of artifact

Give the meaning of the artifact within the engineering process executed

Data format If the artifact is exchanged by a file give definition of the content structure of the file.

Exchange technology

If technologies are used for t1he artifact exchange going beyond the use of files name the technologies used and the type and version of software and hardware exptechnologies should be given.


Description of engineering roles with competences, knowledge and skills required for development and use of the artifact

Creating tools Name the tools possibly Consuming tools Name the tools possible consuming the artifactCreating activity Name the engineering activities possibly creating the artifactConsuming activity Name the engineering activities possible consuming the artifact

2.2. Applicability of the modeling approachBased on a set of completed tables of all

network of engineering activities, artifacts, tools and human roles can be characterized. It depends on the application case how some cases it can be regarded as property or feature in some other cases as requirement. In the following some examples of application cases are named.

2.2.1. Definition of process model

As mentioned in (VDI 3695)models for the project dependent and project independent engineering process. In both cases it has to be defined:

· which engineering activities have to be executed in which sequence

· which artifacts are required for these engineering activities,

· which artifacts are created by these engineering activities,

· which human roles are required for these engineering activities, and

· which tools have to be exploited for these activities.


humans and its skills and knowledge required to create and use the artifacts.


Table 3: artifact perspective

Name of the artifact description of the artifact

Give the category of artifact, the artifact belongs toGive the meaning of the artifact within the engineering process executed If the artifact is exchanged by a file give the file format and the definition of the content structure of the file. If technologies are used for t1he artifact exchange going beyond the use of files name the technologies used and the type and version of software and hardware exploited for the implementation of the technologies should be given. Description of engineering roles with competences, knowledge and skills required for development and use of the artifactName the tools possibly creating the artifact Name the tools possible consuming the artifact Name the engineering activities possibly creating the artifactName the engineering activities possible consuming the artifact

Applicability of the modeling approach Based on a set of completed tables of all three types for an engineering organization a

network of engineering activities, artifacts, tools and human roles can be characterized. It depends on the application case how the information within the tables is interpreted. In some cases it can be regarded as property or feature in some other cases as requirement. In the following some examples of application cases are named.

Definition of process model

95) one central criterion for EOs is the definition of process models for the project dependent and project independent engineering process. In both

which engineering activities have to be executed in which sequence

acts are required for these engineering activities,

which artifacts are created by these engineering activities,

which human roles are required for these engineering activities, and

which tools have to be exploited for these activities.

19

humans and its skills and knowledge required to create and use the artifacts.


Give the category of artifact, the artifact belongs to Give the meaning of the artifact within the engineering process

the file format and the

If technologies are used for t1he artifact exchange going beyond the use of files name the technologies used and the type and version of

loited for the implementation of the


Name the engineering activities possibly creating the artifact Name the engineering activities possible consuming the artifact

types for an engineering organization a network of engineering activities, artifacts, tools and human roles can be characterized. It

the information within the tables is interpreted. In some cases it can be regarded as property or feature in some other cases as requirement. In

one central criterion for EOs is the definition of process models for the project dependent and project independent engineering process. In both


which human roles are required for these engineering activities, and


In this case the Engineering Activity Chain perspective is the leading perspectives providing the properties and all further perspectives are seen as requirements to the engineering organization and the engineering process execution.

2.2.2. Analysis of re

Following (VDI 3695), another interesting criterion for EOs are the reengineering artifacts. Therefore, it has to be determined, which engineering artifacts created in one engineering project can be exploited in other engineering projects. To capability the Information Exchange perspective is the leading perspective. It has to be evaluated (in this order):


· which artifacts are created by these engineering activities

· which artifacts are required for these engineering activities.

If there is an artifact created which can be used in a another engineering process later on, this can be identified.

2.2.3. Analysis of tool chain coverage and continuity

Based on (VDI 3695) the tool chain coverage of an EOs and its continuity can be one criterion for the EO quality. To analyze the tool chain the following information have to be collected:


· which tools have to

Here a main focus has to be the amount of engineering activities covered by one tool and its continuity in the activity chain as well as on the import and export formats (and technologies) supported by the different toolto execute the design decisions of the engineering activities been in predecessor – relation. In this case the import and export formats (and technologies) are seen as the driving requirements.

2.2.4. Analysis of lossless information flow

Finally, one interesting criterion is the lossless information flow within an EO. This lossless information flow is given in the case were the logistics of engineering artifacts within an EO is correct and free from pr

For the evaluation of this fact it has to be evaluated:

· which engineering activity covering which design decision has to be executed in which sequence


gineering Activity Chain perspective is the leading perspectives providing the properties and all further perspectives are seen as requirements to the engineering organization and the engineering process execution.

Analysis of re-use capabilities

, another interesting criterion for EOs are the reengineering artifacts. Therefore, it has to be determined, which engineering artifacts created in one engineering project can be exploited in other engineering projects. To capability the Information Exchange perspective is the leading perspective. It has to be


which artifacts are created by these engineering activities, and

which artifacts are required for these engineering activities.

there is an artifact created which can be used in a another engineering process later on,

Analysis of tool chain coverage and continuity

the tool chain coverage of an EOs and its continuity can be one criterion for the EO quality. To analyze the tool chain the following information have to be


which tools have to be exploited for these activities.

Here a main focus has to be the amount of engineering activities covered by one tool and its continuity in the activity chain as well as on the import and export formats (and technologies) supported by the different tools at the points were different tools will be used to execute the design decisions of the engineering activities been in predecessor

relation. In this case the import and export formats (and technologies) are seen as the

Analysis of lossless information flow

Finally, one interesting criterion is the lossless information flow within an EO. This lossless information flow is given in the case were the logistics of engineering artifacts within an EO is correct and free from problems (see chapter 2.3).

For the evaluation of this fact it has to be evaluated:

which engineering activity covering which design decision has to be executed in

20

gineering Activity Chain perspective is the leading perspectives providing the properties and all further perspectives are seen as requirements to the

, another interesting criterion for EOs are the re-use capabilities of engineering artifacts. Therefore, it has to be determined, which engineering artifacts created in one engineering project can be exploited in other engineering projects. To analyze this capability the Information Exchange perspective is the leading perspective. It has to be


there is an artifact created which can be used in a another engineering process later on,

the tool chain coverage of an EOs and its continuity can be one criterion for the EO quality. To analyze the tool chain the following information have to be


Here a main focus has to be the amount of engineering activities covered by one tool and its continuity in the activity chain as well as on the import and export formats (and

s at the points were different tools will be used to execute the design decisions of the engineering activities been in predecessor – successor

relation. In this case the import and export formats (and technologies) are seen as the

Finally, one interesting criterion is the lossless information flow within an EO. This lossless information flow is given in the case were the logistics of engineering artifacts within

which engineering activity covering which design decision has to be executed in


· which artifacts are required for these engineering activities,

· which artifacts are created by these engineering activities,

· which tools have to be exploited for these activities, and

· which human roles are required for these engineering acti

In a first stage the Information Exchange perspective is considered as a requirement for the Tool Chain perspective. It will be investigated whether a defined data format for an artifact can be provided or consumed by a tool.

In the second stage the Engineering Activity Chain perspective and the Tool Chain perspective are considered. It is evaluated whether the available human resource roles will provide all required skills, capabilities, and knowledge required by tools and engineering activities.

For more information on this analysis method see

2.3. Consideration of engineering process consistency The engineering process of production systems is cha

decisions contained in engineering activities. By this sequence of design decisions the engineering artifacts required to characterize, model, parameterize, program, and implement the production system are established. Foappropriate tools are exploited which are used by humans (see


which artifacts are required for these engineering activities,

which artifacts are created by these engineering activities,

which tools have to be exploited for these activities, and

which human roles are required for these engineering activities.

In a first stage the Information Exchange perspective is considered as a requirement for the Tool Chain perspective. It will be investigated whether a defined data format for an artifact can be provided or consumed by a tool.

e Engineering Activity Chain perspective and the Tool Chain perspective are considered. It is evaluated whether the available human resource roles will provide all required skills, capabilities, and knowledge required by tools and engineering

or more information on this analysis method see chapter 2.3.

Consideration of engineering process consistency he engineering process of production systems is characterized by a sequence of design

decisions contained in engineering activities. By this sequence of design decisions the engineering artifacts required to characterize, model, parameterize, program, and implement the production system are established. For the execution of the design decisions appropriate tools are exploited which are used by humans (see Figure 4).

21

vities.

In a first stage the Information Exchange perspective is considered as a requirement for the Tool Chain perspective. It will be investigated whether a defined data format for an

e Engineering Activity Chain perspective and the Tool Chain perspective are considered. It is evaluated whether the available human resource roles will provide all required skills, capabilities, and knowledge required by tools and engineering

Consideration of engineering process consistency racterized by a sequence of design

decisions contained in engineering activities. By this sequence of design decisions the engineering artifacts required to characterize, model, parameterize, program, and

r the execution of the design decisions


Figure

Thus, for an appropriate engineering process the migrating engineering artifacts and the information contained within should be considered. To ensure a proper information logistic as stated in VDI guideline 3695, it will be necess

· the right information (artifact)

· in the right quality (data type, file type)

· at the right moment

· to the right tool and

· to the right human able to interpret them.

Problems will occur, if this information logistic will not may be caused by the following problems.

Problem 1: The information required is not available. This can happen, if a required input to an engineering activity cannot be provided by a human, tool or activity of the scope of aengineering chain.

Problem 2: The information cannot be provided in the right quality. This happens, if an engineering artifact is available only in a format that cannot be


Figure 4: Engineering artifact flow

Thus, for an appropriate engineering process the migrating engineering artifacts and the information contained within should be considered. To ensure a proper information logistic as stated in VDI guideline 3695, it will be necessary to enable the provision of

the right information (artifact)

in the right quality (data type, file type)

at the right moment

to the right tool and

to the right human able to interpret them.

Problems will occur, if this information logistic will not have the required quality. This may be caused by the following problems.

The information required is not available. This can happen, if a required input to an engineering activity cannot be provided by a human, tool or activity of the scope of activity of the considered engineering chain.

The information cannot be provided in the right quality. This happens, if an engineering artifact is available only in a format that cannot be

22

Thus, for an appropriate engineering process the migrating engineering artifacts and the information contained within should be considered. To ensure a proper information logistic

ary to enable the provision of

have the required quality. This

The information required is not available. This can happen, if a required input to an engineering activity cannot be provided by a

ctivity of the considered

The information cannot be provided in the right quality. This happens, if an engineering artifact is available only in a format that cannot be


automatically imported to the engineering tool used for design decision.

In such a case there are two options possible. The first one is a data transformation executed by another software system mapping the available data format to a data format importable to the intended tool. The second one is a manuintended tool.

In both cases problems resulting from the necessary data conversion may happen resulting from human error

Problem 3: The information can only be partially provided in the right quality. Thihappens, if the engineering tool to be used has either a data model not able to interpret the information contained in the provided artifact or

Problem 4: The information cannot be provided in the right moment. This will happen, if the information or thpredecessor activity which is not completed at the moment the information /artifact is required.

Problem 5: The used tool is not the right tool for the intended design decision. This will happen on the one hand, ifwill not contain the intended design decision. On the other hand this will happen if the tool chain design decisions.

Problem 6: The involved human has not the right skills or knintended design decision. This will happen, if the human is either not able to use the intended tool or to interpret the information provided in the right way necessary for the design decision.

Problem 7: The provided information within theconsistent. This will happen, if the work within an engineering tool will lead to not consistent information within this tool or the parallel work within more than one tool will result in contradicting artifacts.

The location of the seven problems in the engineering process is depicted in


automatically imported to the engineering tool used for design decision.

In such a case there are two options possible. The first one is a data transformation executed by another software system mapping the available data format to a data format importable to the intended tool. The second one is a manual integration of the information to the intended tool.

In both cases problems resulting from the necessary data conversion may happen resulting from human error-proneness.

The information can only be partially provided in the right quality. Thihappens, if the engineering tool to be used has either a data model not able to interpret the information contained in the provided artifact or

The information cannot be provided in the right moment. This will happen, if the information or the artifact required will be created by a predecessor activity which is not completed at the moment the information /artifact is required.

The used tool is not the right tool for the intended design decision. This will happen on the one hand, if the scope of activity of the tool will not contain the intended design decision. On the other hand this will happen if the tool chain at all is not suitable for the sequence of design decisions.

The involved human has not the right skills or knintended design decision. This will happen, if the human is either not able to use the intended tool or to interpret the information provided in the right way necessary for the design decision.

The provided information within the engineering process are not consistent. This will happen, if the work within an engineering tool will lead to not consistent information within this tool or the parallel work within more than one tool will result in contradicting artifacts.

f the seven problems in the engineering process is depicted in

23

automatically imported to the engineering tool used for the next

In such a case there are two options possible. The first one is a data transformation executed by another software system mapping the available data format to a data format importable to the intended tool.

al integration of the information to the

In both cases problems resulting from the necessary data conversion proneness.

The information can only be partially provided in the right quality. This happens, if the engineering tool to be used has either a data model not able to interpret the information contained in the provided artifact or

The information cannot be provided in the right moment. This will e artifact required will be created by a

predecessor activity which is not completed at the moment the

The used tool is not the right tool for the intended design decision. the scope of activity of the tool

will not contain the intended design decision. On the other hand this all is not suitable for the sequence of

The involved human has not the right skills or knowledge for the intended design decision. This will happen, if the human is either not able to use the intended tool or to interpret the information provided

engineering process are not consistent. This will happen, if the work within an engineering tool will lead to not consistent information within this tool or the parallel work within more than one tool will result in contradicting artifacts.

f the seven problems in the engineering process is depicted in Figure 5.


Figure 5: Problem location in the engineering proce

Within the following subsections these problems will be considered in more detail. To enable the selection of appropriate measure to avoid these problems based on mechatronical concepts two classes of problems named fractions and gaps within the engineering process of production systems are considered. Therefore the terms fraction and gap will be defined, typical examples are given based on the results of the questionnaire, a methodology for evaluation of engineering organizations and the identified 7 prinformation logistics within the engineering chain. Finally, possibilities to eliminate the fractions and gaps by exploiting mechatronical concepts are named.

2.3.1. Fractions and gaps within engineering processes

Within this section the terms informatiengineering execution are defined. Some basic examples for fractions and gaps are given.


: Problem location in the engineering process

Within the following subsections these problems will be considered in more detail. To enable the selection of appropriate measure to avoid these problems based on mechatronical concepts two classes of problems named fractions and gaps within the

ring process of production systems are considered. Therefore the terms fraction and gap will be defined, typical examples are given based on the results of the questionnaire, a methodology for evaluation of engineering organizations and the identified 7 prinformation logistics within the engineering chain. Finally, possibilities to eliminate the fractions and gaps by exploiting mechatronical concepts are named.

Fractions and gaps within engineering processes

Within this section the terms information fraction and information gap with respect to engineering execution are defined. Some basic examples for fractions and gaps are given.

24

Within the following subsections these problems will be considered in more detail. To enable the selection of appropriate measure to avoid these problems based on mechatronical concepts two classes of problems named fractions and gaps within the

ring process of production systems are considered. Therefore the terms fraction and gap will be defined, typical examples are given based on the results of the questionnaire, a methodology for evaluation of engineering organizations and the identified 7 problems of information logistics within the engineering chain. Finally, possibilities to eliminate the

Fractions and gaps within engineering processes

on fraction and information gap with respect to engineering execution are defined. Some basic examples for fractions and gaps are given.


Figure 6: Possible evaluation of information logistics

Figure 6 provides a qualitative visualization of the analysis results of an example engineering process. In this figure two problems can be easily seen.C and D there is a kind of fraction. Within each perspective there is a switch to another entity responsible for the project. Thus, there is a risk of losing information at this point of the project resulting in errors or double wortool available to execute engineering activity B.C. This also might result in problems of the information chains since design decisions cannot be taken creating information.

Exploiting this thinking the folquality of an engineering organization.

An information fraction engineering activity cannot be used within this engineering activity by reasons provision process. Information fractions are given in the case were the provided information are either not the right information for the engineering activity, not in the right data format thus not readable, not consistent, or not available in the An information gap is given in the case, were the information provided to an engineering activity cannot be used within this engineering activity by reasons of decision process execution. Information gaps are given in cases were toobased on the information (the tool is not appropriate for the design decision based on the provided information) or human cannot execute engineering activity based on the information (the humans have not the right skilthe design decisions based on the provided information).

Facing the migration and use of information within an engineering organization the risk of fractions and gaps is related to the amount of separations within tperspectives at the same qualitative point in time of the engineering organization. Thus risk factor can be defined as follows.


: Possible evaluation of information logistics

provides a qualitative visualization of the analysis results of an example engineering process. In this figure two problems can be easily seen. Between project phases C and D there is a kind of fraction. Within each perspective there is a switch to another entity responsible for the project. Thus, there is a risk of losing information at this point of the project resulting in errors or double work. The second problem visible is that there is no tool available to execute engineering activity B.C. This also might result in problems of the information chains since design decisions cannot be taken creating information.

Exploiting this thinking the following definitions can be taken defining measures for the quality of an engineering organization.

is given in the case where information provided to an engineering activity cannot be used within this engineering activity by reasons provision process. Information fractions are given in the case were the provided information are either not the right information for the engineering activity, not in the right data format thus not readable, not consistent, or not available in the right moment (delayed).

is given in the case, were the information provided to an engineering activity cannot be used within this engineering activity by reasons of decision process

Information gaps are given in cases were tool cannot execute engineering activity based on the information (the tool is not appropriate for the design decision based on the provided information) or human cannot execute engineering activity based on the information (the humans have not the right skills, knowledge, or competences to execute the design decisions based on the provided information).

Facing the migration and use of information within an engineering organization the risk of fractions and gaps is related to the amount of separations within tperspectives at the same qualitative point in time of the engineering organization. Thus risk factor can be defined as follows.

25

provides a qualitative visualization of the analysis results of an example Between project phases

C and D there is a kind of fraction. Within each perspective there is a switch to another entity responsible for the project. Thus, there is a risk of losing information at this point of

k. The second problem visible is that there is no tool available to execute engineering activity B.C. This also might result in problems of the information chains since design decisions cannot be taken creating information.

lowing definitions can be taken defining measures for the

ere information provided to an engineering activity cannot be used within this engineering activity by reasons of data provision process. Information fractions are given in the case were the provided information are either not the right information for the engineering activity, not in the right data format

right moment (delayed). is given in the case, were the information provided to an engineering

activity cannot be used within this engineering activity by reasons of decision process l cannot execute engineering activity

based on the information (the tool is not appropriate for the design decision based on the provided information) or human cannot execute engineering activity based on the

ls, knowledge, or competences to execute

Facing the migration and use of information within an engineering organization the risk of fractions and gaps is related to the amount of separations within the four different perspectives at the same qualitative point in time of the engineering organization. Thus risk


The separation degree of an engineering organizationwithin the perspectives “Engineering Activity Chain”, “Human Resources”, “Tool Chain”, and “Information exchange” at the same point in time. changes in the Engineering Activity Chain” perspective, the number of different person changes in the “Human Resources” perspective, the number of tool changes in the “Tool Chain” perspective, and the number of artifact changes in the “Information exchange” perspective.

Mapped to the problems defined above information fractions are related to problems 1, 2, 3 or 7 and information gaps are related to problems 5 and 6.

Examples of fractions are cases, in which the information exchange among the different involved engineering tools cannot exploit a common data format for the different tools. They result in the high number of paper and questionnaire evaluation.

Typical examples are:

· the transmission of geometry and kinematics information from mechanical engineering to simulation or virtual commissioning in that the usesupport the same graphic data format,

· the transmission of signal data from mechanical engineering over electrical engineering to PLC and robot programming in that appropriate data formats are missed, and

· the roundtrip engineering of robot csimulation based collision detection.

For more information about typical existing fractions see the vision paper of the AutomationML consortium (AutomationML e.V. 2007)

Examples of information gaps are usually notools or its combinations.

Typical examples are tools not directly intended for an engineering decision like

· the use of excel for the design of hierarchical plant structures,

· the use of PLC programming tools for

· the use of UML class diagrams for the modeling of PLC programs,

or humans not qualified for the engineering decisions like

· electricians execution the design of behavior models of plant components for virtual commissioning of

· PLC programmers executing mechanical engineering.

The criticality of an information fraction or an information gap is the level of impact of this fraction/gap on the proper execution of the intended design decision.


separation degree of an engineering organization is the number of separations ineering Activity Chain”, “Human Resources”, “Tool Chain”, and

“Information exchange” at the same point in time. It is evaluated by the number of activity changes in the Engineering Activity Chain” perspective, the number of different person

“Human Resources” perspective, the number of tool changes in the “Tool Chain” perspective, and the number of artifact changes in the “Information exchange”

Mapped to the problems defined above information fractions are related to problems 1, 2, 3 or 7 and information gaps are related to problems 5 and 6.

Examples of fractions are cases, in which the information exchange among the different involved engineering tools cannot exploit a common data format for the different tools.

he high number of paper and .pdf based interfaces as indicated in the

the transmission of geometry and kinematics information from mechanical engineering to simulation or virtual commissioning in that the usesupport the same graphic data format,

the transmission of signal data from mechanical engineering over electrical engineering to PLC and robot programming in that appropriate data formats are

the roundtrip engineering of robot cells between offline robot programming and simulation based collision detection.

For more information about typical existing fractions see the vision paper of the (AutomationML e.V. 2007).

Examples of information gaps are usually not sufficient skilled humans, not appropriate


the use of excel for the design of hierarchical plant structures,

the use of PLC programming tools for requirement specification, or

the use of UML class diagrams for the modeling of PLC programs,

or humans not qualified for the engineering decisions like

electricians execution the design of behavior models of plant components for virtual commissioning of PLC programs or

PLC programmers executing mechanical engineering.

The criticality of an information fraction or an information gap is the level of impact of this fraction/gap on the proper execution of the intended design decision.

26

is the number of separations ineering Activity Chain”, “Human Resources”, “Tool Chain”, and

It is evaluated by the number of activity changes in the Engineering Activity Chain” perspective, the number of different person

“Human Resources” perspective, the number of tool changes in the “Tool Chain” perspective, and the number of artifact changes in the “Information exchange”

Mapped to the problems defined above information fractions are related to problems 1,

Examples of fractions are cases, in which the information exchange among the different involved engineering tools cannot exploit a common data format for the different tools.

pdf based interfaces as indicated in the

the transmission of geometry and kinematics information from mechanical engineering to simulation or virtual commissioning in that the used tool will not

the transmission of signal data from mechanical engineering over electrical engineering to PLC and robot programming in that appropriate data formats are

ells between offline robot programming and

For more information about typical existing fractions see the vision paper of the

t sufficient skilled humans, not appropriate


requirement specification, or

the use of UML class diagrams for the modeling of PLC programs,

electricians execution the design of behavior models of plant components for

The criticality of an information fraction or an information gap is the level of impact of


The value of the level of criticality depends on the intention of its use can be given as a real value or an integer value with or without an admissible range. In any case it is an engineering organization related measure to prioritize the quality of information fractions/gaps within an engineering organization with respect to the execution of countermeasures based on the possible impact on the engineering organization quality or efficiency.

2.3.2. Engineering process evaluation

Within this section a methodology for engineering process the identification and evaluation of information fractions and information gaps. It is based on the different views on engineering processes given in

Step 1. As the first step the tables of the perspective “Engineering Activity Chain” have to be completed by discussion with the persons involved for the engineering organization. It will be important to detail for each identified engineeridescription line, the sets of involved human roles with skills and knowledge required to take the design decisions, used tools and required and created artifacts in the relevant lines as given in the

Activity Name of the activity

Description Short description of the design decisions taken within the engineering activity

Timing Definition of durations, start time and end time of the activity Predecessor activities Activities creating the engineering artifacts required for the activity

Successor activities

Activities requiring the engineering artifacts developed within the activity


Description of engineering roles with competences, knowledge, and skills required for the execution of the engineering activity

Exploited tools Description of engineering tools usable or required for the execution of the engineering activity

Required artifacts Description of engineering artifacts required for the execution of the engineering activity

Created artifacts Description of engineering artifacts developed within the execution of the engineering activity

Step 2. In the second step the tables of the perspective “Information Exchange” have to be completed. For each artifact which is output artifact of one engineering activity and an input artifact of another engineering activity it has to be clearly indicated

a) which tools will create the artifact by taking which design decision and export it using which data format and


of criticality depends on the intention of its use can be given as a real value or an integer value with or without an admissible range. In any case it is an engineering organization related measure to prioritize the quality of information

ithin an engineering organization with respect to the execution of countermeasures based on the possible impact on the engineering organization quality or

Engineering process evaluation

Within this section a methodology for engineering process assessment is given enabling the identification and evaluation of information fractions and information gaps. It is based on the different views on engineering processes given in 2.1.

As the first step the tables of the perspective “Engineering Activity Chain” have to be completed by discussion with the persons involved for the engineering organization. It will be important to detail for each identified engineering activity the sets of design decisions made within the description line, the sets of involved human roles with skills and knowledge required to take the design decisions, used tools and required and created artifacts in the relevant lines as given in the following figure.

Table 4: Filling of activity table

Name of the activity Short description of the design decisions taken within the engineering activity Definition of durations, start time and end time of the activity


Activities requiring the engineering artifacts developed within the activity Description of engineering roles with competences, knowledge, and skills required for the execution of the engineering activityDescription of engineering tools usable or required for the execution

engineering activity Description of engineering artifacts required for the execution of the engineering activity Description of engineering artifacts developed within the execution of the engineering activity

In the second step the tables of the perspective “Information Exchange” have to be completed. For each artifact which is output artifact of one engineering activity and an input artifact of another engineering activity it has to be clearly indicated

tools will create the artifact by taking which design decision and export it using which data format and

27

of criticality depends on the intention of its use can be given as a real value or an integer value with or without an admissible range. In any case it is an engineering organization related measure to prioritize the quality of information

ithin an engineering organization with respect to the execution of countermeasures based on the possible impact on the engineering organization quality or

assessment is given enabling the identification and evaluation of information fractions and information gaps. It is based

As the first step the tables of the perspective “Engineering Activity Chain” have to be completed by discussion with the persons involved for the engineering organization. It will be important to detail for each

ng activity the sets of design decisions made within the description line, the sets of involved human roles with skills and knowledge required to take the design decisions, used tools and required and created

following figure.

Short description of the design decisions taken within the engineering

Definition of durations, start time and end time of the activity Activities creating the engineering artifacts required for the activity Activities requiring the engineering artifacts developed within the

Description of engineering roles with competences, knowledge, and skills required for the execution of the engineering activity Description of engineering tools usable or required for the execution

Description of engineering artifacts required for the execution of the

Description of engineering artifacts developed within the execution of

In the second step the tables of the perspective “Information Exchange” have to be completed. For each artifact which is output artifact of one engineering activity and an input artifact of another engineering activity it

tools will create the artifact by taking which design decision


b) which tool will consume the artifact by taking which design decision and import it using which data format.

as given in the following table.

Artifact Name of the artifactDescription Short description of the artifact and the design decisions the artifact

is involved inType of artifact Give the category of artifact, the artifact belongs toSemantics of artifact

Give the meaning of the artifact within the engineering process executed

Data format If the artifact is exchanged by a file give the file format and the definition of the content structure of the file.

Exchange technology

If technologies are used for the artifact exchange going beyond the use of files name the technologies used and the type and version of software and hardware exploited for the implementation of the technologies should be given.



Creating tools Name the tools possibly creating the artifactConsuming tools Name the tools possible consuming the artifactCreating activity Name the engineering activities possibly creating the artifactConsuming activity

Name the engineering activities possible consuming the artifact

Step 3. In the third step the step the tables of the perspective “Tool Chain” have to be completed. For each tool it has to be indicated

a) which data format the tool can import and which data format the tool can export by containing which information (It should be that in contrast to step 2 here the capabilities of the tools need to be named and not the intention of the engineering chain.)

b) which design decisions can be taken by humans using this tool and which skills and knowledge will the human require fdecisions.

Tool Name of the toolDescription Short description of the tool including the design decisions possibly

taken by using the toolTool type Give the category of tools the tool Involved human resources

Description of engineering roles with competences, knowledge, and skills required for use of the tool

Required artifacts Description of engineering artifacts consumable by the toolCreated artifacts Description of Input formats Name data formats consumable by the tool or input technology used


which tool will consume the artifact by taking which design decision and import it using which data format.

as given in the following table.

Table 5: Filling of artifact table

Name of the artifact Short description of the artifact and the design decisions the artifact is involved in Give the category of artifact, the artifact belongs to Give the meaning of the artifact within the engineering process executed If the artifact is exchanged by a file give the file format and the definition of the content structure of the file.

technologies are used for the artifact exchange going beyond the use of files name the technologies used and the type and version of software and hardware exploited for the implementation of the technologies should be given.

iption of engineering roles with competences, knowledge and skills required for development and use of the artifactName the tools possibly creating the artifact Name the tools possible consuming the artifact Name the engineering activities possibly creating the artifactName the engineering activities possible consuming the artifact

In the third step the step the tables of the perspective “Tool Chain” have to be completed. For each tool it has to be indicated

which data format the tool can import and which data format the tool can export by containing which information (It should be that in contrast to step 2 here the capabilities of the tools need to be named and not the intention of the engineering chain.)

which design decisions can be taken by humans using this tool and which skills and knowledge will the human require fdecisions.

Table 6: Filling of tool table

Name of the tool Short description of the tool including the design decisions possibly taken by using the tool Give the category of tools the tool belongs to Description of engineering roles with competences, knowledge, and skills required for use of the tool Description of engineering artifacts consumable by the toolDescription of engineering artifacts developed by the toolName data formats consumable by the tool or input technology used

28

which tool will consume the artifact by taking which design decision

Short description of the artifact and the design decisions the artifact

Give the meaning of the artifact within the engineering process

If the artifact is exchanged by a file give the file format and the

technologies are used for the artifact exchange going beyond the use of files name the technologies used and the type and version of software and hardware exploited for the implementation of the

iption of engineering roles with competences, knowledge and skills required for development and use of the artifact

Name the engineering activities possibly creating the artifact Name the engineering activities possible consuming the artifact

In the third step the step the tables of the perspective “Tool Chain” have to be completed. For each tool it has to be indicated

which data format the tool can import and which data format the tool can export by containing which information (It should be considered that in contrast to step 2 here the capabilities of the tools need to be named and not the intention of the engineering chain.)

which design decisions can be taken by humans using this tool and which skills and knowledge will the human require for the design

Short description of the tool including the design decisions possibly

Description of engineering roles with competences, knowledge, and

Description of engineering artifacts consumable by the tool engineering artifacts developed by the tool

Name data formats consumable by the tool or input technology used


Output formats Name data formats created by the tool or output technology used

Step 4. In the fourth step the information fractions can be evaluated. Therefore, the tables of the perspective “Tool Chain” and the tables of the perspective “Information Exchange” will be compared. The tables of the perspective “Information Exchange” will be conexchange capabilities which have to be supported by the engineering organization. The tables of the perspective “Tool Chain” are considered as provided exchange capabilities which are supported by the tool chain of the engineering organ

No information fraction based on Problem 1 is given if the following property holds:

Property 1: {For all engineering artifacts having an engineering activity possible consuming the artifact there is an engineering activity possibly creating the

This definition does not reflect the artifacts which are provided from outside of the process or artifacts created but not used on any further activity of the process. Such artifacts would be considered as fractions. This can be omitted by integinformation exchange of the EO with its environment like suppliers and customers.

No information fraction based on Problem 2 is given if for each case an artifact which has to be exchanged between two engineering afollowing property holds:

Property 2: {The two activities exchanging an artifact are executed by the same engineering tool} OR {The intersection of the set of data formats useable to export the artifact from the tool creating the artifact anof data formats useable to import the data to the tool consuming the artifact is not empty}.


Property 3: {Property 1 holds} AND {the information set which can bemodeled by the data format used to export the artifact from the tool creating the artifact and the information set of the which can be modeled by the by data format used to import the data to the tool consuming the artifact contains at least the informatito be exchanged}.


Name data formats created by the tool or output technology used

In the fourth step the information fractions can be evaluated. Therefore, the tables of the perspective “Tool Chain” and the tables of the perspective “Information Exchange” will be compared. The tables of the perspective “Information Exchange” will be considered as required exchange capabilities which have to be supported by the engineering organization. The tables of the perspective “Tool Chain” are considered as provided exchange capabilities which are supported by the tool chain of the engineering organization.


Property 1: {For all engineering artifacts having an engineering activity possible consuming the artifact there is an engineering activity possibly creating the artifact}.

This definition does not reflect the artifacts which are provided from outside of the process or artifacts created but not used on any further activity of the process. Such artifacts would be considered as fractions. This can be omitted by integrating additional activities modeling the information exchange of the EO with its environment like suppliers and

No information fraction based on Problem 2 is given if for each case an artifact which has to be exchanged between two engineering afollowing property holds:

Property 2: {The two activities exchanging an artifact are executed by the same engineering tool} OR {The intersection of the set of data formats useable to export the artifact from the tool creating the artifact anof data formats useable to import the data to the tool consuming the artifact is not empty}.


Property 3: {Property 1 holds} AND {the information set which can bemodeled by the data format used to export the artifact from the tool creating the artifact and the information set of the which can be modeled by the by data format used to import the data to the tool consuming the artifact contains at least the information set required to model the artifact to be exchanged}.

29

Name data formats created by the tool or output technology used

In the fourth step the information fractions can be evaluated. Therefore, the tables of the perspective “Tool Chain” and the tables of the perspective “Information Exchange” will be compared. The tables of the

sidered as required exchange capabilities which have to be supported by the engineering organization. The tables of the perspective “Tool Chain” are considered as provided exchange capabilities which are supported by the tool chain of

No information fraction based on Problem 1 is given if the following

Property 1: {For all engineering artifacts having an engineering activity possible consuming the artifact there is an engineering activity possibly

This definition does not reflect the artifacts which are provided from outside of the process or artifacts created but not used on any further activity of the process. Such artifacts would be considered as fractions. This

rating additional activities modeling the information exchange of the EO with its environment like suppliers and

No information fraction based on Problem 2 is given if for each case an artifact which has to be exchanged between two engineering activities the

Property 2: {The two activities exchanging an artifact are executed by the same engineering tool} OR {The intersection of the set of data formats useable to export the artifact from the tool creating the artifact and the set of data formats useable to import the data to the tool consuming the

No information fraction based on Problem 3 is given if the following

Property 3: {Property 1 holds} AND {the information set which can be modeled by the data format used to export the artifact from the tool creating the artifact and the information set of the which can be modeled by the by data format used to import the data to the tool consuming the

on set required to model the artifact


If Property 1, 2 and/or 3 are violated for an artifact to be exchanged, there is an information fraction based on this artifact.

Step 5. In the fitables of the perspective “Engineering Activity Chain” and the perspective “Tool Chain” will be compared. The tables of the perspective “Engineering Activity Chain” will be considered as required capabilities to execute a design decision which have to borganisation. The tables of the perspective “Tool Chain” are considered as provided capabilities which are supported by the tool chain of the engineering organisation.

No information gap based on Problem 5 is given if the folholds:

Property 4: {For all design decisions to be executed within an engineering activity there is an engineering tool named within this activity with the capability to execute the design decision}.

No information gap based on Problem 6 isholds:

Property 5: {For each design decisions to be taken holds: for all skills required to take the design decision there is a human role providing this skill} AND {For each design decisions to be taken holds: for all knowrequired to take the design decision there is a human role providing this knowledge} AND {For each design decisions to be taken holds: for all competences required to take the design decision there is a human role providing this competence} AND {For decisions holds: for all skills required to use the tool there is a human role providing this skill} AND {For each tool to be used for a design decisions holds: for all knowledge required to use the tool there is a human rproviding this knowledge}.

To make the fraction and gap evaluation more efficient the following checklist can be exploited:

(1) [Is the artifact consumed by an activity of the engineering process]

AND

[Is the engineering artifact not created by an environment]

è Fraction based on Problem 1

2 The consideration of Problem 7 is not possible without considering the semantics of the engineering artefacts and its content. Thus it will not be considered for fraction evaluation.


If Property 1, 2 and/or 3 are violated for an artifact to be exchanged, there is an information fraction based on this artifact.2

fifth step the information gaps are identified. Therefore, ttables of the perspective “Engineering Activity Chain” and the perspective “Tool Chain” will be compared. The tables of the perspective “Engineering Activity Chain” will be considered as required capabilities to execute a design decision which have to be supported by the engineering organisation. The tables of the perspective “Tool Chain” are considered as provided capabilities which are supported by the tool chain of the engineering organisation.

No information gap based on Problem 5 is given if the fol

Property 4: {For all design decisions to be executed within an engineering activity there is an engineering tool named within this activity with the capability to execute the design decision}.

No information gap based on Problem 6 is given if the following property

Property 5: {For each design decisions to be taken holds: for all skills required to take the design decision there is a human role providing this skill} AND {For each design decisions to be taken holds: for all knowrequired to take the design decision there is a human role providing this knowledge} AND {For each design decisions to be taken holds: for all competences required to take the design decision there is a human role providing this competence} AND {For each tool to be used for a design decisions holds: for all skills required to use the tool there is a human role providing this skill} AND {For each tool to be used for a design decisions holds: for all knowledge required to use the tool there is a human rproviding this knowledge}.

To make the fraction and gap evaluation more efficient the following checklist can be

[Is the artifact consumed by an activity of the engineering process]

[Is the engineering artifact not created by an activity or provided from the EO

Fraction based on Problem 1

The consideration of Problem 7 is not possible without considering the semantics of the engineering artefacts and its content. Thus it will not be considered for fraction evaluation.

30

If Property 1, 2 and/or 3 are violated for an artifact to be exchanged, there

step the information gaps are identified. Therefore, the tables of the perspective “Engineering Activity Chain” and the perspective “Tool Chain” will be compared. The tables of the perspective “Engineering Activity Chain” will be considered as required capabilities to execute a

e supported by the engineering organisation. The tables of the perspective “Tool Chain” are considered as provided capabilities which are supported by the tool chain of the

No information gap based on Problem 5 is given if the following property

Property 4: {For all design decisions to be executed within an engineering activity there is an engineering tool named within this activity with the

given if the following property

Property 5: {For each design decisions to be taken holds: for all skills required to take the design decision there is a human role providing this skill} AND {For each design decisions to be taken holds: for all knowledge required to take the design decision there is a human role providing this knowledge} AND {For each design decisions to be taken holds: for all competences required to take the design decision there is a human role

each tool to be used for a design decisions holds: for all skills required to use the tool there is a human role providing this skill} AND {For each tool to be used for a design decisions holds: for all knowledge required to use the tool there is a human role

To make the fraction and gap evaluation more efficient the following checklist can be

[Is the artifact consumed by an activity of the engineering process]

activity or provided from the EO

The consideration of Problem 7 is not possible without considering the semantics of the engineering artefacts


(2) [Is the artifact not created by the same activity of the engineering process consuming it]

AND

[the data format the engineering artifact is provided within by the creating toonot the same data format the consuming tool can understand

è Fraction based on Problem

(3) [Is the artifact not created by the same activity of the engineering process consuming it]

AND

[Is the intersection of the modeling capabilities of the export data formats from the creating tool of the artifact and the import data format of the consuming tool of the artifact smaller than required modeling capability to model the engineering artifact]

è Fraction based on Problem 3

(4) [Is there an engineering activity with a design decision to be taken within and a required tool with special engineering capabilities named to execute the design decision]

AND

[Is the intended design decision not part of tby the engineering tool]

è Gap based on Problem 5

(5) {[Is there an engineering activity with a design decision to be taken within]

AND {{[Is there a competence required to take the design decision of the activity] AND [There is no human role named in the activity providing this competences]} OR

{[Is there a knowledge required to take the design decision of the activity] AND [There is no human role named in the activity providing this knowledge]} OR

{[Is there a skill requno human role named in the activity providing this skill]}}}

OR

{[Is there an engineering activity with a tool to be used within]

AND {{[Is there a competence required to use the tool] AND [Trole named in the activity providing this competences]} OR {[Is there a knowledge required to use the tool] AND [There is no human role named in the activity providing this knowledge]} OR {[Is there a skill required to use the tool] AND [There is no human role named in the activity providing this skill]}}}

è Gap based on Problem 6


[Is the artifact not created by the same activity of the engineering process

the data format the engineering artifact is provided within by the creating toothe same data format the consuming tool can understand]



[Is the intersection of the modeling capabilities of the export data formats from the creating tool of the artifact and the import data format of the consuming tool of the artifact smaller than required modeling capability to model the engineering


[Is there an engineering activity with a design decision to be taken within and a required tool with special engineering capabilities named to execute the design

[Is the intended design decision not part of the set of design decisions executable by the engineering tool]

Gap based on Problem 5

{[Is there an engineering activity with a design decision to be taken within]

AND {{[Is there a competence required to take the design decision of the activity] ere is no human role named in the activity providing this competences]}


{[Is there a skill required to take the design decision of the activity] AND [There is no human role named in the activity providing this skill]}}}

{[Is there an engineering activity with a tool to be used within]

AND {{[Is there a competence required to use the tool] AND [Trole named in the activity providing this competences]} OR {[Is there a knowledge required to use the tool] AND [There is no human role named in the activity providing this knowledge]} OR {[Is there a skill required to use the tool] AND

here is no human role named in the activity providing this skill]}}}

Gap based on Problem 6

31


the data format the engineering artifact is provided within by the creating tool is ]


[Is the intersection of the modeling capabilities of the export data formats from the creating tool of the artifact and the import data format of the consuming tool of the artifact smaller than required modeling capability to model the engineering

[Is there an engineering activity with a design decision to be taken within and a required tool with special engineering capabilities named to execute the design

he set of design decisions executable

{[Is there an engineering activity with a design decision to be taken within]

AND {{[Is there a competence required to take the design decision of the activity] ere is no human role named in the activity providing this competences]}


ired to take the design decision of the activity] AND [There is

AND {{[Is there a competence required to use the tool] AND [There is no human role named in the activity providing this competences]} OR {[Is there a knowledge required to use the tool] AND [There is no human role named in the activity providing this knowledge]} OR {[Is there a skill required to use the tool] AND

here is no human role named in the activity providing this skill]}}}


2.4. Tool chain scenariosWithin this chapter different scenarios of tool chain integration are described. These

scenarios are important when it comes to gaps and fractions within the engineering process, as the degree of tool integration is crucial to the seamless information flowprocess (see section 2.2)

2.4.1. Best of bread tools

The lowest level of integration can be found in the “Best of Bread” philosophy. Here the engineering process is executed using the best fitting engineering tools for the individual engineering activities. Thus a tool chain has to be established. Within this tool chain the engineering artifacts have to be exchangedimplementation of these interfaces can be made using proprietary or standardized data exchange formats (Diedrich et al. 2011), (Drath et al. 2011)exchange formats should have the higher priority as they can provide larger benefits.

The most positive aspect of the “Best of Bread” philosophy is the adaptability of the tool chain to changing engineering process requirements and changing technology conditions. The replacement of tools within the chain by more suitable tools is very eastools provide standardized interfaces for data exchange. But the tool chain is not providing an integrated data model for all relevant information. Data consistency and data integrity have to be ensured independent from the used tool chain. implementation of a tool crossing engineering process management and a data consistency management system is required. Another disadvantage of this approach is the necessary efforts to keep consistency and interoperability among the toolstandardized data exchange formats are used.

Within the mechatronical engineering process a tool chain following the “Best of bread” philosophy has to consider the different engineering disciplines of the used tools. Each tand its interface have to support the exchange of the relevant part of the involved. The tool independent data consistency management system has to ensure the data consistency related to the engineering tools have to implement less engineering activities. Relevant Modularization of Plant componentof Plant components, and Templates of be implemented should be Variant Development, Template Development, Instantiation, Engineering artifact Library Management, and User Guidance wiIn contrast to the “One for all” philosophy the tool independent data consistency management system has to implement the components, and Dependencies between Facets, Facet Aggregatiengineering activities Consistency Management, and Change Management and Change Impact Analysis. This will make the project management using a tool chain much more complicated.


Tool chain scenarios Within this chapter different scenarios of tool chain integration are described. These

scenarios are important when it comes to gaps and fractions within the engineering process, as the degree of tool integration is crucial to the seamless information flow

Best of bread tools

The lowest level of integration can be found in the “Best of Bread” philosophy. Here the ss is executed using the best fitting engineering tools for the individual

engineering activities. Thus a tool chain has to be established. Within this tool chain the engineering artifacts have to be exchanged among tools using appropriate interfaces. The implementation of these interfaces can be made using proprietary or standardized data

(Diedrich et al. 2011), (Drath et al. 2011) were standardized data exchange formats should have the higher priority as they can provide larger benefits.

The most positive aspect of the “Best of Bread” philosophy is the adaptability of the tool chain to changing engineering process requirements and changing technology conditions. The replacement of tools within the chain by more suitable tools is very eastools provide standardized interfaces for data exchange. But the tool chain is not providing an integrated data model for all relevant information. Data consistency and data integrity have to be ensured independent from the used tool chain. A tool independent implementation of a tool crossing engineering process management and a data consistency management system is required. Another disadvantage of this approach is the necessary efforts to keep consistency and interoperability among the tools in case of tool updates if no standardized data exchange formats are used.

Within the mechatronical engineering process a tool chain following the “Best of bread” philosophy has to consider the different engineering disciplines of the used tools. Each tand its interface have to support the exchange of the relevant part of the involved. The tool independent data consistency management system has to ensure the data consistency related to the engineering artifacts. Within this philosophengineering tools have to implement less modular engineering concepts and general

. Relevant modular concepts are Hierarchies of Plant componentPlant components, Level of Detail, Libraries of Plant component

s, and Templates of Plant components. General engineering activities be implemented should be Variant Development, Template Development, Instantiation,

Library Management, and User Guidance within the Engineering Process. In contrast to the “One for all” philosophy the tool independent data consistency management system has to implement the modular concepts Facets Description of

s, and Dependencies between Facets, Facet Aggregation and the Consistency Management, and Change Management and Change

Impact Analysis. This will make the project management using a tool chain much more

32

Within this chapter different scenarios of tool chain integration are described. These scenarios are important when it comes to gaps and fractions within the engineering process, as the degree of tool integration is crucial to the seamless information flow within the

The lowest level of integration can be found in the “Best of Bread” philosophy. Here the ss is executed using the best fitting engineering tools for the individual

engineering activities. Thus a tool chain has to be established. Within this tool chain the among tools using appropriate interfaces. The

implementation of these interfaces can be made using proprietary or standardized data were standardized data

exchange formats should have the higher priority as they can provide larger benefits.

The most positive aspect of the “Best of Bread” philosophy is the adaptability of the tool chain to changing engineering process requirements and changing technology conditions. The replacement of tools within the chain by more suitable tools is very easy supposed the tools provide standardized interfaces for data exchange. But the tool chain is not providing an integrated data model for all relevant information. Data consistency and data integrity

A tool independent implementation of a tool crossing engineering process management and a data consistency management system is required. Another disadvantage of this approach is the necessary

s in case of tool updates if no

Within the mechatronical engineering process a tool chain following the “Best of bread” philosophy has to consider the different engineering disciplines of the used tools. Each tool and its interface have to support the exchange of the relevant part of the plant components involved. The tool independent data consistency management system has to ensure the data

. Within this philosophy the different modular engineering concepts and general

Plant components, components, Variants

General engineering activities to be implemented should be Variant Development, Template Development, Instantiation,

thin the Engineering Process. In contrast to the “One for all” philosophy the tool independent data consistency

Facets Description of Plant on and the general

Consistency Management, and Change Management and Change Impact Analysis. This will make the project management using a tool chain much more


2.4.2. Integrated tool chain

The “Integration Framework” philosophybread tools" and "All-in-one tools"not having its drawbacks. The “Integration Framework” philosophy is characterized by the combination of a centralized data management system implemented as middleware with a tool chain with standardized interfaces. Examples of such Integration Frameworks are the SIEMENS Team Center or the Engineering Service Bus Framework will provide a syntactic and semantic integration of the data sets relevant for the engineering tools associated based on a common data model implemented within the middleware. Using this common data model and the standardized interfaces the main benefits of this philosophy are the easy adaptation of the framework to changing engineering process requirements and changing technology conditions while ensuring consistency within and among the engineering artifacts. The drawback of integration frameworks is seen in the required setup of the common data model at the moment of tool chain definition. In this moment the common data model has to be developed on the basement of the data models of the different involved tools. Within the mechatronical engineering process the integration framework can be based on the establishing the common data model. Thus the different tools involved will implement the modular concepts Hierarchies of Level of Detail, Libraries of Plant componentof Plant components and the Development, Instantiation, within the Engineering Process. The underlying middleware and data storing facility should implement the modular conceptsbetween Facets, Views on Plant componentPlant components, Revisions of Templates of Plant componentManagement, Variant Development, Flexible View Generation, Template Development, Instantiation, engineering artifact Engineering Process, and Change Management and Change Impact Analysis

2.4.3. All-in-one tools

The highest level of integration can be found in thecomprehensive tool is used enabling the engineering organization to execute all necessary engineering steps (or at least the most) with one engineering tool and integrating all relevant engineering disciplines. Examples of such tools are EPlan engineering center, SIMATIC automation designer or COMOS. Within such an engineering tool the engineering artifacts are based on a tool covering integrated data model over all engineering disciplines. The engineering artifacts are stored and managed in a centralized way. Therebyensure consistency within and among the engineering artifacts. Within such a tool it becomes possible to provide essential engineering process support. This may range from automatic engineering process management with process progress monit


Integrated tool chain

The “Integration Framework” philosophy is in between the both philosophies one tools". It tries to provide the benefits of both philosophies while

not having its drawbacks. The “Integration Framework” philosophy is characterized by the ralized data management system implemented as middleware with a

tool chain with standardized interfaces. Examples of such Integration Frameworks are the SIEMENS Team Center or the Engineering Service Bus (Moser et al. 2011)

provide a syntactic and semantic integration of the data sets relevant for the engineering tools associated based on a common data model implemented within the middleware. Using this common data model and the standardized interfaces the main

is philosophy are the easy adaptation of the framework to changing engineering process requirements and changing technology conditions while ensuring consistency within and among the engineering artifacts. The drawback of integration

the required setup of the common data model at the moment of tool chain definition. In this moment the common data model has to be developed on the basement of the data models of the different involved tools. Within the mechatronical

e integration framework can be based on the engineering artifactestablishing the common data model. Thus the different tools involved will implement the

Hierarchies of Plant components, Modularization of Plant components, Variants of Plant component

s and the general engineering activity Variant Development, Template Development, Instantiation, modular concept Library Management, and User Guidance

Engineering Process. The underlying middleware and data storing facility should modular concepts Facets Description of Plant component

Plant component, Level of Detail, Facet Aggregation, Libraries of s, Revisions of Plant component Data, Variants of Plant component

Plant components and the general engineering activitiesManagement, Variant Development, Flexible View Generation, Template Development,

engineering artifact Library Management, User Guidance within the Engineering Process, and Change Management and Change Impact Analysis

one tools

The highest level of integration can be found in the “All-in-one” philosophy. Here a ve tool is used enabling the engineering organization to execute all necessary

engineering steps (or at least the most) with one engineering tool and integrating all relevant engineering disciplines. Examples of such tools are EPlan engineering center,

ATIC automation designer or COMOS. Within such an engineering tool the engineering artifacts are based on a tool covering integrated data model over all engineering disciplines. The engineering artifacts are stored and managed in a centralized way. Therebyensure consistency within and among the engineering artifacts. Within such a tool it becomes possible to provide essential engineering process support. This may range from automatic engineering process management with process progress monit

33

both philosophies of "best of . It tries to provide the benefits of both philosophies while

not having its drawbacks. The “Integration Framework” philosophy is characterized by the ralized data management system implemented as middleware with a

tool chain with standardized interfaces. Examples of such Integration Frameworks are the (Moser et al. 2011). The Integration

provide a syntactic and semantic integration of the data sets relevant for the engineering tools associated based on a common data model implemented within the middleware. Using this common data model and the standardized interfaces the main

is philosophy are the easy adaptation of the framework to changing engineering process requirements and changing technology conditions while ensuring consistency within and among the engineering artifacts. The drawback of integration

the required setup of the common data model at the moment of tool chain definition. In this moment the common data model has to be developed on the basement of the data models of the different involved tools. Within the mechatronical

engineering artifact establishing the common data model. Thus the different tools involved will implement the

s, Modularization of Plant components, Plant components, and Templates

Variant Development, Template Library Management, and User Guidance

Engineering Process. The underlying middleware and data storing facility should Plant components, Dependencies

, Level of Detail, Facet Aggregation, Libraries of Plant components, and

general engineering activities Consistency Management, Variant Development, Flexible View Generation, Template Development,

Library Management, User Guidance within the Engineering Process, and Change Management and Change Impact Analysis

” philosophy. Here a ve tool is used enabling the engineering organization to execute all necessary

engineering steps (or at least the most) with one engineering tool and integrating all relevant engineering disciplines. Examples of such tools are EPlan engineering center,

ATIC automation designer or COMOS. Within such an engineering tool the engineering artifacts are based on a tool covering integrated data model over all engineering disciplines. The engineering artifacts are stored and managed in a centralized way. Thereby, it is easy to ensure consistency within and among the engineering artifacts. Within such a tool it becomes possible to provide essential engineering process support. This may range from automatic engineering process management with process progress monitoring over change


management and tracing up to automatic execution of discipline crossing engineering steps to name only some of the relevant capabilities. The major drawback of this philosophy is the tool complexity. This complexity makes an adaptation ofprocess requirements and changing technology conditions very complicated and slow. Within the mechatronic engineering process such comprehensive tools have to implement data structures enabling the design and use of concepts like Hierarchies of Dependencies between Facets, Views on Aggregation, Libraries of Plant componentgeneral engineering activitiescomponents, Variant Development, Template Development, Instantiation, artifact Library Management, User Guidance within the Engineering Management and Change Impact Analysis can and should be implemented by the universal tool.


management and tracing up to automatic execution of discipline crossing engineering steps to name only some of the relevant capabilities. The major drawback of this philosophy is the tool complexity. This complexity makes an adaptation of the tool to changing engineering process requirements and changing technology conditions very complicated and slow. Within the mechatronic engineering process such comprehensive tools have to implement data structures enabling the design and use of plant components. Thereby,

s like Hierarchies of Plant components, Facets Description of Dependencies between Facets, Views on Plant component, Level of Detail, Facet

Plant components, and Variants of Plant componentactivities like Consistency Management, Refinement of

s, Variant Development, Template Development, Instantiation, Library Management, User Guidance within the Engineering Process, and Change

Management and Change Impact Analysis can and should be implemented by the universal

34

management and tracing up to automatic execution of discipline crossing engineering steps to name only some of the relevant capabilities. The major drawback of this philosophy is the

the tool to changing engineering process requirements and changing technology conditions very complicated and slow. Within the mechatronic engineering process such comprehensive tools have to implement

s. Thereby, modular Plant components,

, Level of Detail, Facet ant components as well as

like Consistency Management, Refinement of Plant s, Variant Development, Template Development, Instantiation, engineering

Process, and Change Management and Change Impact Analysis can and should be implemented by the universal


3. Description of selected engineering toolsWithin this chapter different selected engineering tools will be described. Additionally i

will be shown if and (if yes) how mechatronic concepts are realized within these tools. The tools are listed in alphabetical order.

Notes:

· AutomationML itself is not a tool but a data exchange format. It is listed here to give insights in what is needed from data edata backbone for and integrated tool chain

· JADE, NetBeans IDE and Protégé are no typical industrial CAE tools. They are especially used within GRACE for the engineering of the MAS. Thus, they are shortly described butinput for the additional tool requirements for industrial CAE tools supporting the GRACE MAS architecture.

3.1. AutomationML


Within a typical engineering value creation chain, data ebottleneck. Due to these reasons, the neutral data exchange format AutomationML usable within the engineering process of manufacturing and process systems was developed to improve the exchange of data among the various used tools. follows the needs of engineers regarding interoperability of tools within the today’s heterogeneous tool landscape. Additionally, it intends to become an enabling technology for the topics „virtual commissioning“ and mechatronical

AutomationML is intended to store and exchange different information created and/or applied during the plant engineering. This information are usually created and maintained in different tools following various disciplines, guidelines, busineconventions. This leads to complex and cross linked data.

In this section the basic AutomationML concepts:

· Plant topology description,

· Geometry and Kinematic,

· Behavior description,

· References and relations,

are introduced as well as the main AutomationML architecture and the extended AutomationML concepts.

AutomationML supports the storage of the following basic concepts:


Description of selected engineering tools Within this chapter different selected engineering tools will be described. Additionally i

how mechatronic concepts are realized within these tools. The tools are listed in alphabetical order.

AutomationML itself is not a tool but a data exchange format. It is listed here to give insights in what is needed from data exchange formats if they are used as a data backbone for and integrated tool chain

JADE, NetBeans IDE and Protégé are no typical industrial CAE tools. They are especially used within GRACE for the engineering of the MAS. Thus, they are shortly described but not analyzed in detail as the other industrial tools to give input for the additional tool requirements for industrial CAE tools supporting the GRACE MAS architecture.

utomationML

Tool description

Within a typical engineering value creation chain, data exchange is a significant bottleneck. Due to these reasons, the neutral data exchange format AutomationML usable within the engineering process of manufacturing and process systems was developed to improve the exchange of data among the various used tools. This neutral data format follows the needs of engineers regarding interoperability of tools within the today’s heterogeneous tool landscape. Additionally, it intends to become an enabling technology for the topics „virtual commissioning“ and mechatronical engineering.

AutomationML is intended to store and exchange different information created and/or applied during the plant engineering. This information are usually created and maintained in different tools following various disciplines, guidelines, business rules and naming conventions. This leads to complex and cross linked data.

In this section the basic AutomationML concepts:

Plant topology description,

Geometry and Kinematic,

description,

References and relations,

introduced as well as the main AutomationML architecture and the extended

AutomationML supports the storage of the following basic concepts:

35

Within this chapter different selected engineering tools will be described. Additionally it how mechatronic concepts are realized within these tools. The

AutomationML itself is not a tool but a data exchange format. It is listed here to xchange formats if they are used as a

JADE, NetBeans IDE and Protégé are no typical industrial CAE tools. They are especially used within GRACE for the engineering of the MAS. Thus, they are

not analyzed in detail as the other industrial tools to give input for the additional tool requirements for industrial CAE tools supporting the

xchange is a significant bottleneck. Due to these reasons, the neutral data exchange format AutomationML usable within the engineering process of manufacturing and process systems was developed to

This neutral data format follows the needs of engineers regarding interoperability of tools within the today’s heterogeneous tool landscape. Additionally, it intends to become an enabling technology for

AutomationML is intended to store and exchange different information created and/or applied during the plant engineering. This information are usually created and maintained in

ss rules and naming

introduced as well as the main AutomationML architecture and the extended


Plant topology

The plant topology describes the manufacturing system as a hierarchical strobjects. This structure is stored in the AutomationML top level format. Different aspects of an item are directly associated to the corresponding AutomationML object. Each object has individual properties and interfaces. As basis data format for 62424) is being used.

Geometry and Kinematic description

The geometry and kinematic information description of an object comprises its complete geometric 3D description, its physical interconnections, and its kinematical condiGeometry and kinematic information is stored by means of the data format COLLADA (Arnaud und Barnes 2006) of the industry consortium “Khronos group” as separate XML document. AutomationML defines special reference mechanisms to link CAEX data objectwith a COLLADA file.

Behavior description

The behavior of objects is described as a sequence of actions. These are stored by means of the data format PLCopen XML corresponding I/O-relations and logical variables. Variables of the SFCs can be “published” within CAEX. This allows storing high level interconnections between them in CAEX.

References and relations

AutomationML distinguishes betweenhand describe associations from CAEX objects to externally stored files. Relations, on the other hand, specify interrelations between CAEX objects. These are additionally used in order to link information incorresponding interfaces must be “published” in CAEX. They can be linked with standard CAEX link mechanisms.

Figure

The basic architecture of AutomationML (see PLCopen XML and COLLADA. Thereby CAEX is the top level format and the link between ainformation. It stores the plant topology, while COLLADA stores geometric and kinematic

AutomationMLEngineering

CAEX IEC 62424 Top level format

Plant topologyinformation• Plants• Cells• Components• Attributes• Interfaces• Relations• References

Object A

Object A1

Object A2

Object An

…


The plant topology describes the manufacturing system as a hierarchical strobjects. This structure is stored in the AutomationML top level format. Different aspects of an item are directly associated to the corresponding AutomationML object. Each object has individual properties and interfaces. As basis data format for the plant topology CAEX

Geometry and Kinematic description

The geometry and kinematic information description of an object comprises its complete geometric 3D description, its physical interconnections, and its kinematical condiGeometry and kinematic information is stored by means of the data format COLLADA

of the industry consortium “Khronos group” as separate XML document. AutomationML defines special reference mechanisms to link CAEX data object

of objects is described as a sequence of actions. These are stored by means of the data format PLCopen XML (PLCopen Konsortium 2009) as SFC including the

relations and logical variables. Variables of the SFCs can be “published” within CAEX. This allows storing high level interconnections between them in CAEX.

AutomationML distinguishes between relations and references. References on the one hand describe associations from CAEX objects to externally stored files. Relations, on the other hand, specify interrelations between CAEX objects. These are additionally used in order to link information in the top level format which is stored externally. For this, corresponding interfaces must be “published” in CAEX. They can be linked with standard

Figure 7: AutomationML base architecture

ure of AutomationML (see Figure 7) consists of the standards CAEX, PLCopen XML and COLLADA. Thereby CAEX is the top level format and the link between ainformation. It stores the plant topology, while COLLADA stores geometric and kinematic

AutomationMLEngineering data

1

2

n

COLLADA

GeometryKinematics

Further XML Standard format

Further aspects of engineering information

PLCopen XMLBehaviourSequencing

InitInit

Step 1

EndInterlocking

36

The plant topology describes the manufacturing system as a hierarchical structure of objects. This structure is stored in the AutomationML top level format. Different aspects of an item are directly associated to the corresponding AutomationML object. Each object has

the plant topology CAEX (IEC

The geometry and kinematic information description of an object comprises its complete geometric 3D description, its physical interconnections, and its kinematical conditions. Geometry and kinematic information is stored by means of the data format COLLADA

of the industry consortium “Khronos group” as separate XML document. AutomationML defines special reference mechanisms to link CAEX data objects

of objects is described as a sequence of actions. These are stored by means as SFC including the

relations and logical variables. Variables of the SFCs can be “published” within CAEX. This allows storing high level interconnections between them in CAEX.

relations and references. References on the one hand describe associations from CAEX objects to externally stored files. Relations, on the other hand, specify interrelations between CAEX objects. These are additionally used in

the top level format which is stored externally. For this, corresponding interfaces must be “published” in CAEX. They can be linked with standard

) consists of the standards CAEX, PLCopen XML and COLLADA. Thereby CAEX is the top level format and the link between all information. It stores the plant topology, while COLLADA stores geometric and kinematic


information and PLCopen XML serves for the storage of sequences and behavior descriptions. This architecture results in an inherent distributed file structure.

The application of CAEX is an important part of AutomationML. AutomationML specifies the concrete application of the CAEX concepts. For this, AutomationML uses the following CAEX means and special attributes, classes, interfaces and object identification rules

· Object identification:objects and AutomationML

· InterfaceClassLib: objects. AutomationML delivers a predefined interface library, whichnumber of abstract interface classes for general automation systems. These classes are syntactically and semantically well defined and allow the modeling of user defined interface instances.

· RoleClassLib: A role library serves for the definitclass explains the general functionality of a CAEX object within its context.

· SystemUnitClassLib:AutomationML classes. It is intended as user defined library of modeliAutomationML does not specify a certain SystemUnitClassLib, but it defines rules how to design them.

· InstanceHierarchy:therefore, the core of AutomationML data. The InstanceHierarchy iof object instances with its own individual properties, interfaces, references and relations.

Additional to the basic concept and the basic architecture AutomationML specifies the extended concepts:

· AutomationML Port Concept

· AutomationML Face

· AutomationML Group Concept

· Support of Multiple Roles

· Process-Product-Resource Concept

These concepts are explained below.

AutomationML Port Concept

The Port concept allows a high level description of complex interfaces. AutomationML ports consist of a set of AutomationML interfaces that belong together. They can be understood similar to plugs or sockets.

AutomationML Facet Concept

AutomationML facets allow the storage of a subset of attributes and interfaces of an AutomationML object. They can be considered as a view on engineering data.


information and PLCopen XML serves for the storage of sequences and behavior descriptions. This architecture results in an inherent distributed file structure.

application of CAEX is an important part of AutomationML. AutomationML specifies the concrete application of the CAEX concepts. For this, AutomationML uses the following CAEX means and special attributes, classes, interfaces and object identification rules

Object identification: AutomationML defines how to identify AutomationMLobjects and AutomationML-classes.

Interfaces serves for the description of relations between objects. AutomationML delivers a predefined interface library, whichnumber of abstract interface classes for general automation systems. These

tactically and semantically well defined and allow the modeling of user defined interface instances.

A role library serves for the definition of abstract role classes. A role class explains the general functionality of a CAEX object within its context.

SystemUnitClassLib: A system unit library allows storing user defined AutomationML classes. It is intended as user defined library of modeliAutomationML does not specify a certain SystemUnitClassLib, but it defines rules how to design them.

InstanceHierarchy: Instance hierarchies store concrete project data and are, therefore, the core of AutomationML data. The InstanceHierarchy iof object instances with its own individual properties, interfaces, references and

Additional to the basic concept and the basic architecture AutomationML specifies the



AutomationML Group Concept

Support of Multiple Roles

Resource Concept

These concepts are explained below.


The Port concept allows a high level description of complex interfaces. AutomationML consist of a set of AutomationML interfaces that belong together. They can be

understood similar to plugs or sockets.


AutomationML facets allow the storage of a subset of attributes and interfaces of an can be considered as a view on engineering data.

37

information and PLCopen XML serves for the storage of sequences and behavior descriptions.

application of CAEX is an important part of AutomationML. AutomationML specifies the concrete application of the CAEX concepts. For this, AutomationML uses the following CAEX means and special attributes, classes, interfaces and object identification rules:

AutomationML defines how to identify AutomationML-

Interfaces serves for the description of relations between objects. AutomationML delivers a predefined interface library, which contains a number of abstract interface classes for general automation systems. These

tactically and semantically well defined and allow the modeling of

ion of abstract role classes. A role class explains the general functionality of a CAEX object within its context.

A system unit library allows storing user defined AutomationML classes. It is intended as user defined library of modeling objects. AutomationML does not specify a certain SystemUnitClassLib, but it defines rules

Instance hierarchies store concrete project data and are, therefore, the core of AutomationML data. The InstanceHierarchy is a hierarchy of object instances with its own individual properties, interfaces, references and

Additional to the basic concept and the basic architecture AutomationML specifies the

The Port concept allows a high level description of complex interfaces. AutomationML consist of a set of AutomationML interfaces that belong together. They can be

AutomationML facets allow the storage of a subset of attributes and interfaces of an can be considered as a view on engineering data.



AutomationML Groups allow the storage of separate views on a subset of AutomationML objects. They can be used to filter objects of the plant tree for different engineering tools.

Support of Multiple Roles

In addition to CAEX, AutomationML defines how to specify multiple role support for an object instance. Multiple roles are of interest, if an object can have multiple functionalities. An example is an all-in-one printer that is a sctime.

Process-Product-Resource Concept

The Process-Product-Resource concept allows high level structuring of engineering data based on a process-centric, productbetween them.


Additionally to the introduced concepts above AutomationML provides means for the application of MUs. Therefore, a defined structure has been defined, see




In addition to CAEX, AutomationML defines how to specify multiple role support for an object instance. Multiple roles are of interest, if an object can have multiple functionalities.

one printer that is a scanner, a printer and a fax device at the same

Resource Concept

Resource concept allows high level structuring of engineering data centric, product-centric or resource-centric view including relat

Mechatronical concepts

Additionally to the introduced concepts above AutomationML provides means for the application of MUs. Therefore, a defined structure has been defined, see Figure

38


In addition to CAEX, AutomationML defines how to specify multiple role support for an object instance. Multiple roles are of interest, if an object can have multiple functionalities.

anner, a printer and a fax device at the same

Resource concept allows high level structuring of engineering data centric view including relations

Additionally to the introduced concepts above AutomationML provides means for the Figure 8.


Figure 8: Possible modeling of mechatronical units by AutomationML

With this structure the same information sets related to MUs as presented in 4.2 can be applied. Thus, each information part is mapped to a soElement of AutomationML with appropriate substructures as expressed in contrast to the SIMATIC AD were the control system bAD object hierarchy as SIMATIC AD objects AutomationML references PLCopen XML documents that contain the corresponding bgeometry in kinematics information which is modeled within COLLADA documents. Again the capital letters show how the different information sets of an mechatronical unit, compare Figure 17 und Figure

In contrast to the concept of the SIMATIC AD the AutomationML MU concepts maps basic semantically and structure information with the help of the role concept.


: Possible modeling of mechatronical units by AutomationML

With this structure the same information sets related to MUs as presented in can be applied. Thus, each information part is mapped to a so-called CAEX Internal

Element of AutomationML with appropriate substructures as expressed in contrast to the SIMATIC AD were the control system behavior is stored within the SIMATIC AD object hierarchy as SIMATIC AD objects AutomationML references PLCopen XML

ments that contain the corresponding behavior information. The same holds for geometry in kinematics information which is modeled within COLLADA documents. Again the capital letters show how the different information sets of an mechatronical unit,

Figure 18, are integrated in the AutomationML data structure.


39

: Possible modeling of mechatronical units by AutomationML

With this structure the same information sets related to MUs as presented in Deliverable called CAEX Internal

Element of AutomationML with appropriate substructures as expressed in Figure 8. In is stored within the SIMATIC

AD object hierarchy as SIMATIC AD objects AutomationML references PLCopen XML information. The same holds for

geometry in kinematics information which is modeled within COLLADA documents. Again the capital letters show how the different information sets of an mechatronical unit,

e AutomationML data structure.



3.2. Bentley Microstation


Bentley Microstation V8i trial version SELLECT series 2 (in the following only MS) is a CAD based engineering tool initially intended for construction of mechanical and later on also electrical systems. It can be applied to various application domains including manufacturing systems, process industry, architecture and buildings, city planning, and much more.

MS is a tool based tool, i.e. MS works on the basis of several tool internal tools developed for a special modeling purpose. The overall tool use is characterized by the, therefore, necessary switching between different tools and its detailed use.

Figure 9 represents the main window of MS. It contains

· the main menu bar for basic file functions like save and open, basic functions like select anstarting tools, using utilities, window settings, and help;

· the primary tool box with tools for cell library management, model management, etc.;

· the view windows representing the working plain project;

· the menu for main model element parameters;

· the main modeling toolbox; and

· the windows for individual tool settings.


Bentley Microstation

Tool description

trial version SELLECT series 2 (in the following only MS) is a CAD based engineering tool initially intended for construction of mechanical and later on also electrical systems. It can be applied to various application domains including manufacturing

ms, process industry, architecture and buildings, city planning, and much more.


represents the main window of MS. It contains

the main menu bar for basic file functions like save and open, basic functions like select and undo, basic element definitions, basic settings for models, starting tools, using utilities, window settings, and help;

the primary tool box with tools for cell library management, model management,

the view windows representing the working plain for the different models of a

the menu for main model element parameters;

ing toolbox; and

the windows for individual tool settings.

40

trial version SELLECT series 2 (in the following only MS) is a CAD based engineering tool initially intended for construction of mechanical and later on also electrical systems. It can be applied to various application domains including manufacturing

ms, process industry, architecture and buildings, city planning, and much more.


the main menu bar for basic file functions like save and open, basic modeling d undo, basic element definitions, basic settings for models,

the primary tool box with tools for cell library management, model management,

for the different models of a


Figure

Models are seen as basic modeling meancan be defined which are used separately and independently. Each model contains its own working plain, a 1:1 size surface of the system to be modeled.

The models itself consist of different model elements wbe described including graphic parameters like size and position, color and layer number, etc. (see left part of Figure 10 as example). Model elements can be grouped.

Model elements can be manipulated using tools which are organized in different tool boxes. MS provides different tool boxes for the creation of model elements, organization of model elements, manipulation ofThe right part of Figure 10 displays the main tool box with the drawing tools part opened and the opened tools menu with different tools available.

Main

Main menubar

Main elementparameters


Figure 9: Microstation main window

Models are seen as basic modeling means of MS. Within one project file different models can be defined which are used separately and independently. Each model contains its own working plain, a 1:1 size surface of the system to be modeled.

The models itself consist of different model elements which have several parameters to be described including graphic parameters like size and position, color and layer number, etc.

as example). Model elements can be grouped.

Model elements can be manipulated using tools which are organized in different tool boxes. MS provides different tool boxes for the creation of model elements, organization of model elements, manipulation of model elements and for the overall model management.

displays the main tool box with the drawing tools part opened opened tools menu with different tools available.

Main toolbox Tool settingwindow

View windows

Primary toolbox

41

s of MS. Within one project file different models can be defined which are used separately and independently. Each model contains its own

hich have several parameters to be described including graphic parameters like size and position, color and layer number, etc.

Model elements can be manipulated using tools which are organized in different tool boxes. MS provides different tool boxes for the creation of model elements, organization of

model elements and for the overall model management. displays the main tool box with the drawing tools part opened

Working plain


Figure 10: Element parameter example and tool box examples

An essential mean for the management of sets of model elements are cells. Cells are seen as reusable model elements or combination of model elements which are organized in desperate cell files which can be attached to a project or a model (see

Figure


: Element parameter example and tool box examples

An essential mean for the management of sets of model elements are cells. Cells are seen as reusable model elements or combination of model elements which are organized in desperate cell files which can be attached to a project or a model (see Figure

Figure 11: Cell file management and use

42

: Element parameter example and tool box examples

An essential mean for the management of sets of model elements are cells. Cells are seen as reusable model elements or combination of model elements which are organized in

Figure 11).



The application scope of MS is limited to the modeling of geThus it will mainly cover geometry information. In addition it is able to represent wiring information, interface information and, by using different colors of the model elements, device hierarchies and its association to difelectrics and control. This is represented in

Figure

Cells are the main elements for the development of Cells are a combination of model elements grouped and stored for reuse. A cell can be established by a combination of elements and/or cells which arelibrary file of *.cel type.

Each cell is than useable as like each other modeling element.

The hierarchy of cell elements and its association to normal elements is gi13.

topological data Process control data

uncontrolled behavior

controlled behavior

• internal hierarchy• subordinate devices• interface to devices• …

• signal information• PLC function blocks• …



The application scope of MS is limited to the modeling of geometric systems, i.e. to CAD. Thus it will mainly cover geometry information. In addition it is able to represent wiring information, interface information and, by using different colors of the model elements, device hierarchies and its association to different engineering disciplines like mechanics, electrics and control. This is represented in Figure 12.

Figure 12: Information sets covered by MS

Cells are the main elements for the development of ENGINEERING ARTIFACTCells are a combination of model elements grouped and stored for reuse. A cell can be established by a combination of elements and/or cells which are grouped and placed in a cell

Each cell is than useable as modeling element which can be placed, moved, adjusted, etc. ing element.

The hierarchy of cell elements and its association to normal elements is gi

Mechatronic unit data

mechanical data electrical / pneu. / hydraulic data

Function decribing data

organizational data technical data economic data

• 3D-CAD data• kinematics• …

• connections• wiring diagrams• pneumatic schemes• …

• functional models• functional

parameters• technological

descriptions• …

• article code• manufacturer• …

• material / weight• power supply• …

• expenses• space needed• …

43

ometric systems, i.e. to CAD. Thus it will mainly cover geometry information. In addition it is able to represent wiring information, interface information and, by using different colors of the model elements,

ferent engineering disciplines like mechanics,

ENGINEERING ARTIFACTs within MS. Cells are a combination of model elements grouped and stored for reuse. A cell can be

grouped and placed in a cell

ing element which can be placed, moved, adjusted, etc.

The hierarchy of cell elements and its association to normal elements is given in Figure

decribing data generic data

economic data other data

functional models

• Instruction manual• Maintenance manual• Maintenance data• …


Figure

A cell itself is initially seen as a set of elements. Each element wparameters. To make a cell to a signalize the engineering discipline a cell element belongs to. For example the colours can be used to identify whether an element geomeelectrical or the control engineering discipline. version. Here a complex cell is represented. Within this cell red coloured elements belong to the control engineering discipline (sensors and actuators) and white and orange coloured elements are or mechanical engineering discipline.


Figure 13: Cell definition structure

A cell itself is initially seen as a set of elements. Each element within a cell has its own parameters. To make a cell to a engineering artifact it is essential to use these parameter to signalize the engineering discipline a cell element belongs to. For example the colours can be used to identify whether an element geometry belongs to the mechanical discipline or the electrical or the control engineering discipline. Figure 14 represents an example for this

e a complex cell is represented. Within this cell red coloured elements belong to the control engineering discipline (sensors and actuators) and white and orange coloured elements are or mechanical engineering discipline.

Geometric object

Cell

1

1..*

1

1..*

Parameter

1

1..*

MIO

1

1..*

Group

44

ithin a cell has its own it is essential to use these parameter to

signalize the engineering discipline a cell element belongs to. For example the colours can be try belongs to the mechanical discipline or the

represents an example for this e a complex cell is represented. Within this cell red coloured elements belong to

the control engineering discipline (sensors and actuators) and white and orange coloured


3.3. Comos / Automation Designer


The SIMATIC AD is an engineering tool for digital engineering of Siemens AG. It is based on the software system COMOS. Within this work the Version 9.0 Vega with service pack 198 is used.

For a general description we refer to the SIMATIC AD handbooks and its antecedent versions like (COMOS Industry Solutions 2008)

Within (Barth 2009) and application description of the SIMATIC AD is given.

This section will concentrate on tool concepts of the SIMATIC AD relevant for the implementation the modular concepts

Generally, SIMATIC AD is based on the following set of tool concepts:

· Base objects and planning objects

· Base object project

· Planning project

· Inheritance

· Data views

· Queries


Figure 14: Cell example

Comos / Automation Designer

Tool description

The SIMATIC AD is an engineering tool for digital engineering of Siemens AG. It is based on the software system COMOS. Within this work the Version 9.0 Vega with service pack 198

general description we refer to the SIMATIC AD handbooks and its antecedent (COMOS Industry Solutions 2008).

and (Foehr 2010) a mechatronical engineering process centric application description of the SIMATIC AD is given.

This section will concentrate on tool concepts of the SIMATIC AD relevant for the modular conceptss and general engineering activities

Generally, SIMATIC AD is based on the following set of tool concepts:

d planning objects

Base object project

45

The SIMATIC AD is an engineering tool for digital engineering of Siemens AG. It is based on the software system COMOS. Within this work the Version 9.0 Vega with service pack 198

general description we refer to the SIMATIC AD handbooks and its antecedent

a mechatronical engineering process centric

This section will concentrate on tool concepts of the SIMATIC AD relevant for the activities described above.


· Mass data processing

· Reports

· E-blocks

· Scripts

Base object and planning object

The SIMATIC AD follows an object oriented modeling philosophy. Therefore, basic objects are used as the fundamental information object were each other object is derived from. Each base object consists of attributes, symbols, interfaces and scripts as basicdividable information objects as well as possible further base objects. This is depicted in Figure 15.

Attributes are used to represent specparameters, names, etc.

Symbols are used as graphical representation of a base object within a specific information view. For example, a base object describing a drive has a special representation within a wiring plan.

Interfaces describe the possible connection places to other base objects independent of the connection nature. They can represent electrical, mechanical, logical or further connection possibilities.

Finally, scripts are programmable engineering arinformation covered by a base object. They will be described in detail later on.

Base objects describe classes of engineering artifacts ranging from physical objects like inductive sensors, stepping motors, or complete gantriprograms, wiring plans, or Gantt based sequences usually. Thus base objects can be the result of the product business.

The structure of a base object is depicted in

Figure 15: Base object structure with project structures

0..*

Attribute

Script

Symbol

Interface

0..*

0..*

0..*


Mass data processing

Base object and planning object

The SIMATIC AD follows an object oriented modeling philosophy. Therefore, basic objects are used as the fundamental information object were each other object is derived from. Each base object consists of attributes, symbols, interfaces and scripts as basicdividable information objects as well as possible further base objects. This is depicted in

Attributes are used to represent special information about the base object like

Symbols are used as graphical representation of a base object within a specific information view. For example, a base object describing a drive has a special representation

Interfaces describe the possible connection places to other base objects independent of the connection nature. They can represent electrical, mechanical, logical or further

Finally, scripts are programmable engineering artifacts useable to manipulate information covered by a base object. They will be described in detail later on.

Base objects describe classes of engineering artifacts ranging from physical objects like inductive sensors, stepping motors, or complete gantries, to logical objects like PLC programs, wiring plans, or Gantt based sequences usually. Thus base objects can be the result of the product business.

The structure of a base object is depicted in Figure 15.

: Base object structure with project structures

Planning objectBase object

1

0..*

0..*

0..*

0..*

Planning project

1

1..*

Base object project

0..*

46

The SIMATIC AD follows an object oriented modeling philosophy. Therefore, basic objects are used as the fundamental information object were each other object is derived from. Each base object consists of attributes, symbols, interfaces and scripts as basic and not dividable information objects as well as possible further base objects. This is depicted in

ial information about the base object like

Symbols are used as graphical representation of a base object within a specific information view. For example, a base object describing a drive has a special representation

Interfaces describe the possible connection places to other base objects independent of the connection nature. They can represent electrical, mechanical, logical or further

tifacts useable to manipulate information covered by a base object. They will be described in detail later on.

Base objects describe classes of engineering artifacts ranging from physical objects like es, to logical objects like PLC

programs, wiring plans, or Gantt based sequences usually. Thus base objects can be the

: Base object structure with project structures

Planning object

1

1..*

Planning project


A planning object is an instantiation of a base object. It is used to describe an individual engineering artifact. Thus it is used within the solution business and part of solution projects.

Base object project and planning project

The base object project is the library of engineering artifacts useable within engineering processes. It is the basis for the further workwhich is stored in the base object library. The base object library is the source of the base object project. It is completed by the results of the product business as well as by evaluation of the results of the solution business regarding re

Figure 16: Relation between base object and planning object

Within the solution business the planning project contains all instantiated planning objects. The planning objects can be created by instantiation from a base object, completed with information, integrated in the project topology and finally used within further engineering activities in the planning project. This is depicted in

Following the VDI recommendation 3695 cyclic process can be followed.

1. In a product business project

· the base object project ca

· the resulting base objects can be written to the base object library.

2. In a solution business project

· the base object project is an instantiation of the base object library,

· the base objects can be adaptedby enrichment or new creation, and

· the planning project is created by instantiation and enriching of base objects to planning objects

Planning project

Planning object

a,b,c


A planning object is an instantiation of a base object. It is used to describe an individual Thus it is used within the solution business and part of solution projects.

Base object project and planning project

The base object project is the library of engineering artifacts useable within engineering processes. It is the basis for the further work of an engineer within an engineering project which is stored in the base object library. The base object library is the source of the base object project. It is completed by the results of the product business as well as by evaluation

e solution business regarding re-useable mechatronical units.

: Relation between base object and planning object

Within the solution business the planning project contains all instantiated planning objects can be created by instantiation from a base object, completed

with information, integrated in the project topology and finally used within further engineering activities in the planning project. This is depicted in Figure 16.

Following the VDI recommendation 3695 (VDI 3695) it is intended that the following cyclic process can be followed.

In a product business project

the base object project can be extended by creation of new base objects and

the resulting base objects can be written to the base object library.

In a solution business project

the base object project is an instantiation of the base object library,

the base objects can be adapted to the needs of the solutions business project by enrichment or new creation, and

the planning project is created by instantiation and enriching of base objects to planning objects while the base object library is unchanged.

Base object project

Base object

a,b,c,d

1

2

a – integration of information b – interconnection of objectsc – object hierarchy generationd – creation of library objects1 – instantiation of objects2 – creation of classes of objects3 – instantiation of base object project4 – integration of classes of objects

Base object 3

4

47

A planning object is an instantiation of a base object. It is used to describe an individual Thus it is used within the solution business and part of solution projects.

The base object project is the library of engineering artifacts useable within engineering of an engineer within an engineering project

which is stored in the base object library. The base object library is the source of the base object project. It is completed by the results of the product business as well as by evaluation

useable mechatronical units.

: Relation between base object and planning object

Within the solution business the planning project contains all instantiated planning objects can be created by instantiation from a base object, completed

with information, integrated in the project topology and finally used within further .

it is intended that the following

n be extended by creation of new base objects and

the resulting base objects can be written to the base object library.

the base object project is an instantiation of the base object library,

to the needs of the solutions business project

the planning project is created by instantiation and enriching of base objects while the base object library is unchanged.

Base object library

Base object


3. In a project evaluating the r

· the base object project can be changed and extended by creation and or enrichment of base objects and

· the resulting base objects can be written back to the base object library.

Each object is located within two objehierarchy within a planning project. The location hierarchy defines the position of an object while the equipment hierarchy defines the hierarchy of mechatronical units.

Inheritance

The inheritance concept objects within the base object project. Here, the derived child base object will have all information/structures from its parent object a can get additional information/structures. Inheritance is not usable within the planning project.

Data views

Data views are views on information within base objects or planning objects. They provide a segmentation of information of an object. Thereby, information belonging to different engineering disciplines canregister cards associated to objects (both planning objects and base objects) containing attributes.

Working layer

Working layers are a segmentation of project data access beyond the use of planning projects and base object projects. Working layers are usually specified by a project administrator defining the data access rules for the different persons involved in an engineering project. These working layers can be defined for planning projects as welbase object projects.

Changes within a working layer of a project will be valid only within this working layer. Thereby, the engineering activities of different persons can be decoupled without the problem of interferences of the engineering activitiewithin the own work caused by other workers.

Working layers can also be condensed to one after finalization of parallel engineering resulting in a common project.

Query

Queries are search and filter functions useable previously selected object within the project all subproperty will be selected within a result list.

Queries can be combined with other tool concepts. Thereby, the quality of thecan be improved or the search results can be further processed. Here, especially scripts can be exploited.

Mass Data Processing


In a project evaluating the results of an solution business project

the base object project can be changed and extended by creation and or enrichment of base objects and

the resulting base objects can be written back to the base object library.

Each object is located within two object hierarchies, location hierarchy and equipment hierarchy within a planning project. The location hierarchy defines the position of an object while the equipment hierarchy defines the hierarchy of mechatronical units.

The inheritance concept enables to inherit more detailed objects from existing base objects within the base object project. Here, the derived child base object will have all information/structures from its parent object a can get additional information/structures.

not usable within the planning project.

Data views are views on information within base objects or planning objects. They provide a segmentation of information of an object. Thereby, information belonging to different engineering disciplines can be modeled separately. Examples for data views are register cards associated to objects (both planning objects and base objects) containing

Working layers are a segmentation of project data access beyond the use of planning projects and base object projects. Working layers are usually specified by a project administrator defining the data access rules for the different persons involved in an engineering project. These working layers can be defined for planning projects as wel

Changes within a working layer of a project will be valid only within this working layer. Thereby, the engineering activities of different persons can be decoupled without the problem of interferences of the engineering activities and the possible problem of changes within the own work caused by other workers.

Working layers can also be condensed to one after finalization of parallel engineering resulting in a common project.

Queries are search and filter functions useable to search within projects. Starting from a previously selected object within the project all sub-objects with a previously defined property will be selected within a result list.

Queries can be combined with other tool concepts. Thereby, the quality of thecan be improved or the search results can be further processed. Here, especially scripts can

48

esults of an solution business project

the base object project can be changed and extended by creation and or

the resulting base objects can be written back to the base object library.

ct hierarchies, location hierarchy and equipment hierarchy within a planning project. The location hierarchy defines the position of an object while the equipment hierarchy defines the hierarchy of mechatronical units.

enables to inherit more detailed objects from existing base objects within the base object project. Here, the derived child base object will have all information/structures from its parent object a can get additional information/structures.

Data views are views on information within base objects or planning objects. They provide a segmentation of information of an object. Thereby, information belonging to

be modeled separately. Examples for data views are register cards associated to objects (both planning objects and base objects) containing

Working layers are a segmentation of project data access beyond the use of planning projects and base object projects. Working layers are usually specified by a project administrator defining the data access rules for the different persons involved in an engineering project. These working layers can be defined for planning projects as well as

Changes within a working layer of a project will be valid only within this working layer. Thereby, the engineering activities of different persons can be decoupled without the

s and the possible problem of changes

Working layers can also be condensed to one after finalization of parallel engineering

to search within projects. Starting from a objects with a previously defined

Queries can be combined with other tool concepts. Thereby, the quality of the search can be improved or the search results can be further processed. Here, especially scripts can


Mass data processing is a tool function useable to integrate or change the same engineering information within a set of within mass data processing objects are selected based on a previously defined property starting from an object of the project. All selected objects will then be extended / changed / … in the same way.

As queries, mass data processing can be combined with other tool concepts to improve the processing quality and efficiency. Therefore, the most important role plays the script concept.

Report

Reports are a tool concept enabling the presentation of information following special presentation rules. They enable an engineering discipline conform presentation. Reports can be distinguished with respect to its ability to change objects presented within.

The first type of reports is the analyzing repowithin a project with respect to special properties and present them in a predefined layout. But they are not able to change or add information within the project. Examples of these reports are signal lists or data s

The second type of reports is the interactive report. This type of report extends the presentation capabilities of analyzing reports by the capability to change information. Thus, using this type of report information within the project including thchanged. Examples of such reports are function plans or wiring plans.

Interactive reports are the main instrument for the engineering activities oriented towards one engineering discipline like control programming, which is made function plans or the wiring planning using wiring plans.

E-block

E-blocks are a tool concept useable to implement the execution of special but multiple occurring engineering activities. They are based on user interaction. Based on user information special engineering activities are executed over a complete project or objects within the project, respectively.

Within the analyzed version of SIMATIC AD a set of basic especial e-blocks were available. The available

· Merge of objects

· Move of objects

· Definition of object position within equipment hierarchy

· Definition of object position within location hierarchy

· Definition of implementation relation between objects

· Definition of sub-objects

· Execution of decision table


Mass data processing is a tool function useable to integrate or change the same engineering information within a set of previously selected objects. Similarly to queries within mass data processing objects are selected based on a previously defined property starting from an object of the project. All selected objects will then be extended / changed

ueries, mass data processing can be combined with other tool concepts to improve the processing quality and efficiency. Therefore, the most important role plays the script

Reports are a tool concept enabling the presentation of information following special presentation rules. They enable an engineering discipline conform presentation. Reports can be distinguished with respect to its ability to change objects

The first type of reports is the analyzing report. They analyze the information stored within a project with respect to special properties and present them in a predefined layout. But they are not able to change or add information within the project. Examples of these reports are signal lists or data sheets.

The second type of reports is the interactive report. This type of report extends the presentation capabilities of analyzing reports by the capability to change information. Thus, using this type of report information within the project including the object structure can be changed. Examples of such reports are function plans or wiring plans.

Interactive reports are the main instrument for the engineering activities oriented towards one engineering discipline like control programming, which is made function plans or the wiring planning using wiring plans.

blocks are a tool concept useable to implement the execution of special but multiple occurring engineering activities. They are based on user interaction. Based on user information special engineering activities are executed over a complete project or objects within the project, respectively.

Within the analyzed version of SIMATIC AD a set of basic e-blocks as well as several blocks were available. The available basic e-blocks are:

Definition of object position within equipment hierarchy

Definition of object position within location hierarchy

Definition of implementation relation between objects

objects

n of decision table

49

Mass data processing is a tool function useable to integrate or change the same previously selected objects. Similarly to queries

within mass data processing objects are selected based on a previously defined property starting from an object of the project. All selected objects will then be extended / changed

ueries, mass data processing can be combined with other tool concepts to improve the processing quality and efficiency. Therefore, the most important role plays the script

Reports are a tool concept enabling the presentation of information within a project following special presentation rules. They enable an engineering discipline conform presentation. Reports can be distinguished with respect to its ability to change objects

rt. They analyze the information stored within a project with respect to special properties and present them in a predefined layout. But they are not able to change or add information within the project. Examples of these

The second type of reports is the interactive report. This type of report extends the presentation capabilities of analyzing reports by the capability to change information. Thus,

e object structure can be

Interactive reports are the main instrument for the engineering activities oriented towards one engineering discipline like control programming, which is made by using

blocks are a tool concept useable to implement the execution of special but multiple occurring engineering activities. They are based on user interaction. Based on user information special engineering activities are executed over a complete project or objects

blocks as well as several


· Report execution

· Definition of terminal implementation relation

· Definition of channel implementation relation

· Definition of bridge relation between objects

· Connection of interfaces

· Change of base object

There is also an e-block version

Generally existing e-blocks can be extended by using scripts to include additional functionality. Thereby, user defined engineering activities can be implemented manipulating planning objects in a special way by

Thus, scripts are the basement of the functionality of eown script and extends this script by a user interface useable to provide user information to the script prior to script execution. For the standard ethree parameters for source object target object and naming of standard eFor self-defined e-blocks this user interface can be changed.

Script

In contrast to the tool concdefined objects. Usually they are embedded within the object structure by associating them to objects like reports or e-lifecycle of the object, they are attached to. Examples of embedding scripts to objects are scripts within reports or scripts which are embedded in escript is the script for generation of a unique object name called in the moment of object generation.

Scripts are programmed in the VBscript programming language. They can be changed within the base objects in the base object project. The complete script system of the SIMATIC AD can be changed following user needs including the integration of adscripts for special purposes.


The realization and application of mechatronical concepts based on SIMATIC AD is based on the definition of mechatronical structures and information involved in ARTIFACTs describing mechatronical objects as given in the literature (see1996, Thramboulidis 2008, Wagner et al. 2010

The information set covered by the engineering discipline related related (Schorn und Große). have to be combined. The resulting structure is depicted in


Definition of terminal implementation relation

Definition of channel implementation relation

Definition of bridge relation between objects

Connection of interfaces

Change of base object

block version available useable as self-defined e-block.

blocks can be extended by using scripts to include additional functionality. Thereby, user defined engineering activities can be implemented manipulating planning objects in a special way by including, merging, or processing information.

Thus, scripts are the basement of the functionality of e-blocks. Each eown script and extends this script by a user interface useable to provide user information to

pt execution. For the standard e-blocks the user interface contains three parameters for source object target object and naming of standard e

blocks this user interface can be changed.

In contrast to the tool concepts named above scripts can’t be used independently from defined objects. Usually they are embedded within the object structure by associating them

-blocks. They are executed on a predefined point within the ject, they are attached to. Examples of embedding scripts to objects are

scripts within reports or scripts which are embedded in e-blocks. One example of a special script is the script for generation of a unique object name called in the moment of object

Scripts are programmed in the VBscript programming language. They can be changed within the base objects in the base object project. The complete script system of the SIMATIC AD can be changed following user needs including the integration of ad


The realization and application of mechatronical concepts based on SIMATIC AD is based on the definition of mechatronical structures and information involved in

mechatronical objects as given in the literature (seeWagner et al. 2010) and within standards (see

The information set covered by the engineering artifact can be classified following pline related (Kiefer 2007), plant structure related (Drath 2010)

structures. But all of these approaches are not complete and have to be combined. The resulting structure is depicted in Figure 17.

50

block.

blocks can be extended by using scripts to include additional functionality. Thereby, user defined engineering activities can be implemented manipulating

including, merging, or processing information.

blocks. Each e-block contains its own script and extends this script by a user interface useable to provide user information to

blocks the user interface contains three parameters for source object target object and naming of standard e-block function.

epts named above scripts can’t be used independently from defined objects. Usually they are embedded within the object structure by associating them

blocks. They are executed on a predefined point within the ject, they are attached to. Examples of embedding scripts to objects are

blocks. One example of a special script is the script for generation of a unique object name called in the moment of object

Scripts are programmed in the VBscript programming language. They can be changed within the base objects in the base object project. The complete script system of the SIMATIC AD can be changed following user needs including the integration of additional

The realization and application of mechatronical concepts based on SIMATIC AD is based on the definition of mechatronical structures and information involved in ENGINEERING

mechatronical objects as given in the literature (see Harashima et al. VDI 2206).

can be classified following (Drath 2010), or data

structures. But all of these approaches are not complete and


Figure 17: Information sets covered by

The named information sets consists of:

· The process control data consists of all control code and control code specifications of any kind and signal information like signal list and variable definitions.

· The mechanical data cover all information about the mechanical construction including geometry

· The electrical, pneumatic, and hydraulic data describe the electrical, pneumatic, and hydraulic construction of the MU including the connections and wiring of the different types and its plugs.

· The topological data cover the hierarchoverview about the structuring and the interfaces within the hierarchy.

· The function describing data will give a functional description of the MU. This contains relevant functional parameters, and technological descriptioguidelines, and functional models of the uncontrolled and controlled behavior of the MU.

· Finally, the generic data summarize further organizational, technical, economical and other data. They cover for example article codes and manufacturer identifications and addresses, weight and size of the MU, supply information for electrical and other power, costs for acquisition and maintenance, and user manuals.



controlled behavior




: Information sets covered by ENGINEERING ARTIFACT

The named information sets consists of:

The process control data consists of all control relevant information including control code and control code specifications of any kind and signal information like signal list and variable definitions.

The mechanical data cover all information about the mechanical construction including geometry and kinematics data.

The electrical, pneumatic, and hydraulic data describe the electrical, pneumatic, and hydraulic construction of the MU including the connections and wiring of the different types and its plugs.

The topological data cover the hierarchy of MUs and devices. They give an overview about the structuring and the interfaces within the hierarchy.

The function describing data will give a functional description of the MU. This contains relevant functional parameters, and technological descriptioguidelines, and functional models of the uncontrolled and controlled behavior of

Finally, the generic data summarize further organizational, technical, economical and other data. They cover for example article codes and manufacturer

cations and addresses, weight and size of the MU, supply information for electrical and other power, costs for acquisition and maintenance, and user









descriptions• …




51

ENGINEERING ARTIFACT

control relevant information including control code and control code specifications of any kind and signal information

The mechanical data cover all information about the mechanical construction

The electrical, pneumatic, and hydraulic data describe the electrical, pneumatic, and hydraulic construction of the MU including the connections and wiring of the

y of MUs and devices. They give an overview about the structuring and the interfaces within the hierarchy.

The function describing data will give a functional description of the MU. This contains relevant functional parameters, and technological descriptions and guidelines, and functional models of the uncontrolled and controlled behavior of

Finally, the generic data summarize further organizational, technical, economical and other data. They cover for example article codes and manufacturer

cations and addresses, weight and size of the MU, supply information for electrical and other power, costs for acquisition and maintenance, and user



functional models



For more information see

The modeling of these information sets within SIMATIwill provide functions to the overall system. These functions can be primary functions directly used within the manufacturing process like transportation functions in the case of conveyers, manufacturing functions in the functions in the case of clam sets. In addition to the primary functions there can be secondary functions required for correct behavior of the MU. Such functions can be maintenance functions or preparation

Within the suggested information structuring within a MU the internal structuring of the functions as well as the structuring of the overall engineering artifact and its MU representatively should be standardized.

Each function is controlled by appropriate control code. This code implements a behavior specification given by a program organization unit (POU). To connect the functions to the underlying MUs and devices and parameters are defined. Hence, the structures for these control information.

To provide the functions the MU consists of lower level MUs and devices which arwithin the devices part. To be used from the higher level MUs each unit has an execution interface with appropriate parameters for the overall MU. Hence, the representing the MU contains structures for these interface informati

The behavior of the MU will be described within the sequences part of the information structure. Here models of controlled as well as uncontrolled behavior can be integrated for analysis purposes like virtual commissioning. Hence, the the MU contains structures for these b

Finally there is a separate subinformation.

The described structure is given in


For more information see (Lüder et al. 2010).

The modeling of these information sets within SIMATIC AD is based on the idea that MUs will provide functions to the overall system. These functions can be primary functions directly used within the manufacturing process like transportation functions in the case of conveyers, manufacturing functions in the case of machines, cells, or robots, or supporting functions in the case of clam sets. In addition to the primary functions there can be secondary functions required for correct behavior of the MU. Such functions can be maintenance functions or preparation functions like manufacturing parameter adjustment.

Within the suggested information structuring within a engineering artifactMU the internal structuring of the functions as well as the structuring of the overall

MU representatively should be standardized.

Each function is controlled by appropriate control code. This code implements a behavior specification given by a program organization unit (POU). To connect the functions to the underlying MUs and devices and to parameterize them, appropriate interfaces and parameters are defined. Hence, the engineering artifact representing the MU contains structures for these control information.

To provide the functions the MU consists of lower level MUs and devices which arwithin the devices part. To be used from the higher level MUs each unit has an execution interface with appropriate parameters for the overall MU. Hence, the engineering artifactrepresenting the MU contains structures for these interface information.

The behavior of the MU will be described within the sequences part of the information structure. Here models of controlled as well as uncontrolled behavior can be integrated for analysis purposes like virtual commissioning. Hence, the engineering artifthe MU contains structures for these behavior information.

Finally there is a separate sub-information set for the geometry and kinematics

The described structure is given in Figure 18.

52

C AD is based on the idea that MUs will provide functions to the overall system. These functions can be primary functions directly used within the manufacturing process like transportation functions in the case of

case of machines, cells, or robots, or supporting functions in the case of clam sets. In addition to the primary functions there can be secondary functions required for correct behavior of the MU. Such functions can be

functions like manufacturing parameter adjustment.

engineering artifact representing a MU the internal structuring of the functions as well as the structuring of the overall

Each function is controlled by appropriate control code. This code implements a behavior specification given by a program organization unit (POU). To connect the functions to the

to parameterize them, appropriate interfaces and representing the MU contains

To provide the functions the MU consists of lower level MUs and devices which are given within the devices part. To be used from the higher level MUs each unit has an execution

engineering artifact

The behavior of the MU will be described within the sequences part of the information structure. Here models of controlled as well as uncontrolled behavior can be integrated for

engineering artifact representing

information set for the geometry and kinematics


Figure 18: Implementation of

The capital letters within Figure sets relevant for the engineerinThereby, it can be seen, that:

· the engineering artifactdescriptions (G) , and generic data (J),

· the functions (primary as well as secondary) ddescriptions (G),

· the function sub-structure POU gives the controlled behavior (I),

· the function substructure Code gives control code (B)

· the function substructure device interface + parameters gives parts of the signal information (A), electrical, hydraulic, and pneumatic data (D), and functional parameters (F),

· CAD data / kinematics gives geometry and kinematics information (C),

· the devices gives the topology information (E),

· the sequences give the controlled (I) and

· the execution interface and parameters gives further parts of signal information (A), electrical, hydraulic, pneumatic data (D), and functional parameters (F).

3 TheuncontrolledbehaviorofanMUistheoverallbehaviorreachedbyreactionoftheMUonallarbitrarysequencesofexternalinputs.ItsubsumesallbehaviorpossibilitiestheMUcontains.reactionoftheMUonaspecialsequenceofexternalinputscontrollers,e.g.robotcontroller,PLCetc..


: Implementation of engineering artifact within SIMATIC AD

Figure 17 and Figure 18 give the mapping of the different data engineering artifact to the suggested representation in SIMATIC AD.

Thereby, it can be seen, that:

engineering artifact itself contains functional parameters (F), functional descriptions (G) , and generic data (J),

the functions (primary as well as secondary) directly covers the technological

structure POU gives the controlled behavior (I),

the function substructure Code gives control code (B)

the function substructure device interface + parameters gives parts of the signal ormation (A), electrical, hydraulic, and pneumatic data (D), and functional

CAD data / kinematics gives geometry and kinematics information (C),

the devices gives the topology information (E),

the sequences give the controlled (I) and uncontrolled (H) behavior models

the execution interface and parameters gives further parts of signal information (A), electrical, hydraulic, pneumatic data (D), and functional parameters (F).

TheuncontrolledbehaviorofanMUistheoverallbehaviorreachedbyreactionoftheMUonallarbitrarysequencesofexternalinputs.ItsubsumesallbehaviorpossibilitiestheMUcontains.ThecontrolledbehaviorofaMU

aspecialsequenceofexternalinputsrepresentedbyacontrolprogramexecutedinoneormorecontrollers,e.g.robotcontroller,PLCetc..

53

within SIMATIC AD

give the mapping of the different data to the suggested representation in SIMATIC AD.

itself contains functional parameters (F), functional

irectly covers the technological

structure POU gives the controlled behavior (I),

the function substructure device interface + parameters gives parts of the signal ormation (A), electrical, hydraulic, and pneumatic data (D), and functional

CAD data / kinematics gives geometry and kinematics information (C),

uncontrolled (H) behavior models3, and

the execution interface and parameters gives further parts of signal information (A), electrical, hydraulic, pneumatic data (D), and functional parameters (F).

TheuncontrolledbehaviorofanMUistheoverallbehaviorreachedbyreactionoftheMUonallarbitrarysequencesThecontrolledbehaviorofaMUreachedby

representedbyacontrolprogramexecutedinoneormore


This described implementation of following consideration of implementation strategies for the engineering activities within SIMATIC AD.

3.4. JADE


Multi-agent systems can be adequately developed using usual objectsuch as Java and C++. However, the development of multithe implementation of features not supported by usual programming languages, such as message transport, encoding and parsing, white and yellow pages servicescommon understanding and agent lifeprogramming effort. The use agent development platforms, that provide the previously referred features and services, makes easier the development of agentand reduces the programming effort (and also providing a higher level of abstraction of some technical details).

A significant set of platforms environments for agent development is available on commercial and scientific domain, providingdifferences reflex of the philosophy and the target problems envisioned by the platform developers. Among the broad number of available agent development platforms, the following platforms were analysed (theseFIPA compliance): ZEUS, FIPA-JACK and April. Jade is probably the wellagent-based systems.

JADE is a Java-based architecture that uses the Java Remote Method Invocation (RMI) to support the creation of distributed Java technologysimplify the development of multicompliance with the FIPA specifications, e.g. naming service and yellowmessage transport and parsing service, and a library of FIPA interaction protocols ready to be used (Bellifemine et al. 1999)JADE platform are Java Threads, which makes the debugging of multiconsequently, some tools have been developed to simplify the development of agentsolutions, being every single tool provided by JADE packa

JADE provides the mandatory components defined by FIPA to manage the agent platform, which are the:

· Agent Communication Channel (ACC), which is responsible for the conversation channel, supporting the communications among the agentsinteroperability of the components.

· Agent Management System (AMS), which provides white pages and agent life cycle management services (controlling the access to the platform, authentication, and registration), maintaining a directory of agen


This described implementation of engineering artifact is used as basement for the following consideration of implementation strategies for the modular concepts

within SIMATIC AD.

Tool description

agent systems can be adequately developed using usual object-oriented such as Java and C++. However, the development of multi-agent system solutions requires the implementation of features not supported by usual programming languages, such as message transport, encoding and parsing, white and yellow pages servicescommon understanding and agent life-cycle management services, which increases the programming effort. The use agent development platforms, that provide the previously referred features and services, makes easier the development of agent-and reduces the programming effort (and also providing a higher level of abstraction of

A significant set of platforms environments for agent development is available on commercial and scientific domain, providing a variety of services and agent models, which differences reflex of the philosophy and the target problems envisioned by the platform developers. Among the broad number of available agent development platforms, the following platforms were analysed (these platforms share between them the fact of being

-OS, Java Agent Development Framework (JADE), Grasshopper, JACK and April. Jade is probably the well-known and the most used framework to develop

based architecture that uses the Java Remote Method Invocation (RMI) to support the creation of distributed Java technology-based to Java applications. JADE aims to simplify the development of multi-agent systems by providing a set of services and agentscompliance with the FIPA specifications, e.g. naming service and yellowmessage transport and parsing service, and a library of FIPA interaction protocols ready to

(Bellifemine et al. 1999). Note that in the essence, the agents deJADE platform are Java Threads, which makes the debugging of multi-threading very difficult; consequently, some tools have been developed to simplify the development of agentsolutions, being every single tool provided by JADE packaged as an agent itself.

JADE provides the mandatory components defined by FIPA to manage the agent platform,

Agent Communication Channel (ACC), which is responsible for the conversation channel, supporting the communications among the agentsinteroperability of the components.

Agent Management System (AMS), which provides white pages and agent life cycle management services (controlling the access to the platform, authentication, and registration), maintaining a directory of agent identifiers and states.

54

used as basement for the modular concepts and general

oriented languages, agent system solutions requires

the implementation of features not supported by usual programming languages, such as message transport, encoding and parsing, white and yellow pages services, ontologies for

cycle management services, which increases the programming effort. The use agent development platforms, that provide the previously

-based applications and reduces the programming effort (and also providing a higher level of abstraction of

A significant set of platforms environments for agent development is available on a variety of services and agent models, which

differences reflex of the philosophy and the target problems envisioned by the platform developers. Among the broad number of available agent development platforms, the

platforms share between them the fact of being OS, Java Agent Development Framework (JADE), Grasshopper,

known and the most used framework to develop

based architecture that uses the Java Remote Method Invocation (RMI) to based to Java applications. JADE aims to

agent systems by providing a set of services and agents in compliance with the FIPA specifications, e.g. naming service and yellow-page service, message transport and parsing service, and a library of FIPA interaction protocols ready to

. Note that in the essence, the agents developed using the threading very difficult;

consequently, some tools have been developed to simplify the development of agent-based ged as an agent itself.

JADE provides the mandatory components defined by FIPA to manage the agent platform,

Agent Communication Channel (ACC), which is responsible for the conversation channel, supporting the communications among the agents and offering

Agent Management System (AMS), which provides white pages and agent life cycle management services (controlling the access to the platform, authentication,

t identifiers and states.


· Directory Facilitator (DF), which provides a piece of shared memory offering the yellow pages services as defined in the FIPA specifications, and the capability of federation within other DFs on other existing platforms. Using thipossible to register services and search for agents offering specific services.

In this way, the main container of a JADE multithe ACC, AMS and DF agents, and by an RMI registry (that is used by the JAplatform communication), as illustrated in

Figure

JADE uses the concept of behav(Bellifemine et al. 1999).

The communication among the agents is performed through message passing, where FIPA-ACL (Agent Communication Language) is the agent communication language to represent messages. JADE provides the FIPA SL (Semantic Language) content language and the agent management ontology, as well as the support for userand ontologies that can be implemented, registered with agents, and automatically used by the framework.

The Remote Management Agent (RMA) provides a Graphical User Interface (GUI) for the remote management of the platform, allowing monitoring and controlling the status of agents, for example to stop and rean agent life cycle from a remote host. When the Jade platform is started, a default container is created, which holds the RMA itself, the DF, and AMS.


Directory Facilitator (DF), which provides a piece of shared memory offering the yellow pages services as defined in the FIPA specifications, and the capability of federation within other DFs on other existing platforms. Using thipossible to register services and search for agents offering specific services.

In this way, the main container of a JADE multi-agent system application is composed of the ACC, AMS and DF agents, and by an RMI registry (that is used by the JAplatform communication), as illustrated in Figure 19.

Figure 19: Containers in the JADE Platform

JADE uses the concept of behaviours to model concurrent tasks in agent programming

The communication among the agents is performed through message passing, where ACL (Agent Communication Language) is the agent communication language to

. JADE provides the FIPA SL (Semantic Language) content language and the agent management ontology, as well as the support for user-defined content languages and ontologies that can be implemented, registered with agents, and automatically used by

The Remote Management Agent (RMA) provides a Graphical User Interface (GUI) for the remote management of the platform, allowing monitoring and controlling the status of agents, for example to stop and re-start agents, Figure 20. The RMA allow a fully control of an agent life cycle from a remote host. When the Jade platform is started, a default container is created, which holds the RMA itself, the DF, and AMS.

55

Directory Facilitator (DF), which provides a piece of shared memory offering the yellow pages services as defined in the FIPA specifications, and the capability of federation within other DFs on other existing platforms. Using this tool, it is possible to register services and search for agents offering specific services.

agent system application is composed of the ACC, AMS and DF agents, and by an RMI registry (that is used by the JADE for intra-

iours to model concurrent tasks in agent programming

The communication among the agents is performed through message passing, where ACL (Agent Communication Language) is the agent communication language to

. JADE provides the FIPA SL (Semantic Language) content language and defined content languages

and ontologies that can be implemented, registered with agents, and automatically used by

The Remote Management Agent (RMA) provides a Graphical User Interface (GUI) for the remote management of the platform, allowing monitoring and controlling the status of

. The RMA allow a fully control of an agent life cycle from a remote host. When the Jade platform is started, a default


Figure 20: Graphical User Interface of the Remote Monitoring Agent

The RMA agent provides a set of graphical tools (packaged as agents) to monitor the state of the agents and to support the debugging phase, usually quite complex systems, such as the Dummy, Sniffer and Introspector agents.

The Dummy Agent is a monitoring and debugging tool that allows to edit, compose and send ACL messages to agents, and to receive and view messages from agents. When the complexity of the multi-agent system increases, it is very useful to use a tool to check the exchanged messages between the agents. The Sniffer Agent, illustrated in debugging tool that allows tracking messages exchanged in a JADE agent platform using a notation similar to Unified Modelling Language (UML) sequence diagrams. It can be analyzed the type of message, the FIPA protocol, the ontology language and its co

Figure 21: Graphical User Interface of the Sniffer Agent


: Graphical User Interface of the Remote Monitoring Agent

The RMA agent provides a set of graphical tools (packaged as agents) to monitor the state of the agents and to support the debugging phase, usually quite complex systems, such as the Dummy, Sniffer and Introspector agents.

The Dummy Agent is a monitoring and debugging tool that allows to edit, compose and send ACL messages to agents, and to receive and view messages from agents. When the

agent system increases, it is very useful to use a tool to check the exchanged messages between the agents. The Sniffer Agent, illustrated in debugging tool that allows tracking messages exchanged in a JADE agent platform using a notation similar to Unified Modelling Language (UML) sequence diagrams. It can be analyzed the type of message, the FIPA protocol, the ontology language and its contents.

: Graphical User Interface of the Sniffer Agent

56

: Graphical User Interface of the Remote Monitoring Agent

The RMA agent provides a set of graphical tools (packaged as agents) to monitor the state of the agents and to support the debugging phase, usually quite complex in distributed

The Dummy Agent is a monitoring and debugging tool that allows to edit, compose and send ACL messages to agents, and to receive and view messages from agents. When the

agent system increases, it is very useful to use a tool to check the exchanged messages between the agents. The Sniffer Agent, illustrated in Figure 21, is a debugging tool that allows tracking messages exchanged in a JADE agent platform using a notation similar to Unified Modelling Language (UML) sequence diagrams. It can be analyzed

ntents.

: Graphical User Interface of the Sniffer Agent


The Introspector Agent, illustrated in life-cycle of a running agent, its exchanged ACL messages (incoming and the outgoing messages) and the behaviours in execution (allowing to execute them

Figure 22: Graphical User Interface of the Introspector Agent

In distributed systems it is important to have a service of yellow pages, where agents register their services and skills to be found by other agents. concept is named as Direct Facilitator (DF) following the FIPA specifications. This yellow pages services allow to see the details of agents registration, deregister the agents, modify some descriptions, or as the greatest utilitperformed by another agent.

Figure 23: Gra

JADE also provides other features such as good documentation and an active mailing list to support technical problems.


The Introspector Agent, illustrated in Figure 22, allows monitoring and controlling the cycle of a running agent, its exchanged ACL messages (incoming and the outgoing

messages) and the behaviours in execution (allowing to execute them step

: Graphical User Interface of the Introspector Agent

In distributed systems it is important to have a service of yellow pages, where agents register their services and skills to be found by other agents. In the JADE platform, this concept is named as Direct Facilitator (DF) following the FIPA specifications. This yellow pages services allow to see the details of agents registration, deregister the agents, modify some descriptions, or as the greatest utility of the yellow pages, look for a service that is performed by another agent. Figure 23 illustrates the screenshot of the DF.

: Graphical User Interface of the Director Facilitator

JADE also provides other features such as good documentation and an active mailing list to support technical problems.

57

, allows monitoring and controlling the cycle of a running agent, its exchanged ACL messages (incoming and the outgoing

step-by-step).

: Graphical User Interface of the Introspector Agent

In distributed systems it is important to have a service of yellow pages, where agents In the JADE platform, this

concept is named as Direct Facilitator (DF) following the FIPA specifications. This yellow pages services allow to see the details of agents registration, deregister the agents, modify

y of the yellow pages, look for a service that is illustrates the screenshot of the DF.

phical User Interface of the Director Facilitator

JADE also provides other features such as good documentation and an active mailing list


3.5. NetBeans IDE


NetBeans is an integrated development environment (IDE), implemented in Java and can run on any operating system where it was installed a Java virtual machine (JVM). It is a tool to support the development of software which provides the programmer with a wide range of resources, such as well as a large set of libraries and application programming interfaces (API). It also has an advanced multi-language editor with support for multiple languages, such as Java, C, C++, PHP, JavaScript, among others.programming process supporting the development of several applications, such as websites, mobile applications, stand-alone applications, distributed applications, among other.

In NetBeans the basic building classes and interfaces descriptions with other internal modules. In fact, keyword is modularity. The “NetBeans runtime container” is the core of the platform and is the collective name of the modules prerun on it and also the programmers' applications.


A brief overview of each of these six modules is provided in following:

· Startup (org-netbeansprogrammer’s application, a

· Bootstrap (org-netbeansunderstand what a module is and how to load and compose them into one application.


NetBeans IDE

Tool description

NetBeans is an integrated development environment (IDE), free and openimplemented in Java and can run on any operating system where it was installed a Java virtual machine (JVM). It is a tool to support the development of software which provides the programmer with a wide range of resources, such as compilers, interpreters, debuggers, as well as a large set of libraries and application programming interfaces (API). It also has an

language editor with support for multiple languages, such as Java, C, C++, PHP, JavaScript, among others. The meeting of these tools allow streamline the programming process supporting the development of several applications, such as websites,

alone applications, distributed applications, among other.

In NetBeans the basic building block is modules. Modules are collections of related classes and interfaces descriptions with other internal modules. In fact, keyword is modularity. The “NetBeans runtime container” is the core of the platform and is the collective name of the modules presented in Figure 24. The constitutive modules of the IDE run on it and also the programmers' applications.

runtime container (see http://platform.netbeans.org/tutorials/nbm

runtime-container.html)

A brief overview of each of these six modules is provided in following:

netbeans-core-startup) – Provides the main method of programmer’s application, as well as all the code needed for starting it up.

netbeans-bootstratp) – Enables the runtime container to understand what a module is and how to load and compose them into one

58

free and open-source. It is implemented in Java and can run on any operating system where it was installed a Java virtual machine (JVM). It is a tool to support the development of software which provides

as compilers, interpreters, debuggers, as well as a large set of libraries and application programming interfaces (API). It also has an

language editor with support for multiple languages, such as Java, C, C++, The meeting of these tools allow streamline the

programming process supporting the development of several applications, such as websites, alone applications, distributed applications, among other.

block is modules. Modules are collections of related classes and interfaces descriptions with other internal modules. In fact, keyword is modularity. The “NetBeans runtime container” is the core of the platform and is the

. The constitutive modules of the IDE

runtime container (see http://platform.netbeans.org/tutorials/nbm-

Provides the main method of s well as all the code needed for starting it up.

Enables the runtime container to understand what a module is and how to load and compose them into one


· Filesystem API (orgvirtual filesystem.

· Module System API (orgmodules in programmer’s application.

· Lookup API (org-mechanism for inter

· Utilities API (org-openidethe other modules in the runtime container.

The user interface of NetBeans is composed by several regions as depicted in

Figure

The central element is the editor that permits insert code. In the left top of the possible to see the project tree. In the left bottom of the figure is possible to see a navigator that permits to explore the elements of a specific class (like the attributes and methods).

Swing is a standard UI toolkit on the Java desktop that GUI components can be dragged and positioned from a palette, onto a canvas. Clicking into GUI elements is possible to edit their properties directly in place. of the Swing GUI Builder, exhibiting the pallet of Swing components on the right.

Project tree

Members


Filesystem API (org-openide-filesystems) – Gives programmer’s application a

Module System API (org-openide-modules) – Gives access to the lifecycle of the modules in programmer’s application.

-openide-util-lookup) – Provides a generic communication mechanism for inter-modular interaction.

openide-util) – Includes several utility classes shared between the other modules in the runtime container.

The user interface of NetBeans is composed by several regions as depicted in

Figure 25: NetBeans user interface

The central element is the editor that permits insert code. In the left top of the possible to see the project tree. In the left bottom of the figure is possible to see a navigator that permits to explore the elements of a specific class (like the attributes and methods).

Swing is a standard UI toolkit on the Java desktop that can be used throughout NetBeans. GUI components can be dragged and positioned from a palette, onto a canvas. Clicking into GUI elements is possible to edit their properties directly in place. Figure of the Swing GUI Builder, exhibiting the pallet of Swing components on the right.

Editor

Members

59

grammer’s application a

Gives access to the lifecycle of the

Provides a generic communication

Includes several utility classes shared between

The user interface of NetBeans is composed by several regions as depicted in Figure 25.

The central element is the editor that permits insert code. In the left top of the figure is possible to see the project tree. In the left bottom of the figure is possible to see a navigator that permits to explore the elements of a specific class (like the attributes and methods).

can be used throughout NetBeans. GUI components can be dragged and positioned from a palette, onto a canvas. Clicking into

Figure 26 presents a view of the Swing GUI Builder, exhibiting the pallet of Swing components on the right.

Editor


Figure

In the center is possible to see the constructiothe Grace system. The GUI Snapshot permits to debug a Swing GUI application without looking into the source code.

In NetBeans all the work happens inside a project. The concept of project could be understood like a set of code files plus associated information, permitting to compile, execute and debug applications. From the point of view of visible organization is possible to distinguish two main sets of files. The first one is related to the internal organization of project and is managed by NetBeans in an automated way based on user configurations. As shown in Figure 27, those files are stored in the nbproject folder.


Figure 26: NetBeans Swing GUI Builder

In the center is possible to see the construction of the GUI of Product Type Agent from the Grace system. The GUI Snapshot permits to debug a Swing GUI application without

In NetBeans all the work happens inside a project. The concept of project could be et of code files plus associated information, permitting to compile,

execute and debug applications. From the point of view of visible organization is possible to distinguish two main sets of files. The first one is related to the internal organization of project and is managed by NetBeans in an automated way based on user configurations. As

, those files are stored in the nbproject folder.

60

n of the GUI of Product Type Agent from the Grace system. The GUI Snapshot permits to debug a Swing GUI application without

In NetBeans all the work happens inside a project. The concept of project could be et of code files plus associated information, permitting to compile,

execute and debug applications. From the point of view of visible organization is possible to distinguish two main sets of files. The first one is related to the internal organization of the project and is managed by NetBeans in an automated way based on user configurations. As

Pallet


Figure

The second part corresponds to the files created by the programmer, namely classes and interfaces. The src folder contains a tree of packages (just folders for the system) with the logic structure of project and containing the programmer’s files.

3.6. Protégé


The development of ontologies is a complex task that requires the support of proper frameworks which assist the creation or manipulation of ontologies and are able to express ontologies in one of many ontology languages.

Examples of relevant criteria for choosing an ontology editor are:

· The degree to which the editor abstracts from the actuallanguage used for persistence.

Con


Figure 27: NetBeans project structure

The second part corresponds to the files created by the programmer, namely classes and folder contains a tree of packages (just folders for the system) with the

logic structure of project and containing the programmer’s files.

Tool description

The development of ontologies is a complex task that requires the support of proper orks which assist the creation or manipulation of ontologies and are able to express

ontologies in one of many ontology languages.

Examples of relevant criteria for choosing an ontology editor are:

The degree to which the editor abstracts from the actual ontology representation language used for persistence.

Source

Configuration

61

The second part corresponds to the files created by the programmer, namely classes and folder contains a tree of packages (just folders for the system) with the

The development of ontologies is a complex task that requires the support of proper orks which assist the creation or manipulation of ontologies and are able to express

ontology representation


· The visual navigation possibilities within the knowledge model.

· The incorporation of methodologies and languages, in an easy way.

· The ability to import and export foreign knowledge representation langontology matching.

· The licensing costs of the ontology editor.

The use of these tools may lead to an easier ontological learning and also a more productive task in the design of ontologies, supporting the concurrent work of the ontology engineers and the domain experts.

Several frameworks are currently available, namely OntoEdit, WebODE, Protégé and Hozo. Protégé is probably the most used tool for the development of ontologies, either the development from the scratch, and the merging, importing, qontologies. It is a free, opendomain models and knowledgeto create ontologies based on different types of exprthere are many plugins to be used with Protégé, e.g. to support the validation phase and to export the ontology in different formats.

Protégé can be used to edit and verify the ontology correctness, since it is a frand it provides all necessary characteristics to support a suitable abstraction and technical implementation of the GRACE ontology in a graphical manner.

Figure 28 illustrates a screenshot of the Protégé tool.

Figure

In next figure, it is illustrated the Protégé editor in a more detailed way, highlighting the different tools provided by the


The visual navigation possibilities within the knowledge model.

The incorporation of methodologies and languages, in an easy way.

The ability to import and export foreign knowledge representation langontology matching.

The licensing costs of the ontology editor.

The use of these tools may lead to an easier ontological learning and also a more productive task in the design of ontologies, supporting the concurrent work of the ontology

and the domain experts.

Several frameworks are currently available, namely OntoEdit, WebODE, Protégé and Hozo. Protégé is probably the most used tool for the development of ontologies, either the development from the scratch, and the merging, importing, querying and export of ontologies. It is a free, open-source platform that provides a suite of tools to construct domain models and knowledge-based applications with ontologies. In Protégé it is possible to create ontologies based on different types of expressiveness and languages; additionally, there are many plugins to be used with Protégé, e.g. to support the validation phase and to export the ontology in different formats.

Protégé can be used to edit and verify the ontology correctness, since it is a frand it provides all necessary characteristics to support a suitable abstraction and technical implementation of the GRACE ontology in a graphical manner.

illustrates a screenshot of the Protégé tool.

Figure 28: Screenshot of the Protégé editor

In next figure, it is illustrated the Protégé editor in a more detailed way, highlighting the different tools provided by the editor.

62

The visual navigation possibilities within the knowledge model.

The incorporation of methodologies and languages, in an easy way.

The ability to import and export foreign knowledge representation languages for

The use of these tools may lead to an easier ontological learning and also a more productive task in the design of ontologies, supporting the concurrent work of the ontology

Several frameworks are currently available, namely OntoEdit, WebODE, Protégé and Hozo. Protégé is probably the most used tool for the development of ontologies, either the

uerying and export of source platform that provides a suite of tools to construct

based applications with ontologies. In Protégé it is possible essiveness and languages; additionally,

there are many plugins to be used with Protégé, e.g. to support the validation phase and to

Protégé can be used to edit and verify the ontology correctness, since it is a free platform and it provides all necessary characteristics to support a suitable abstraction and technical

In next figure, it is illustrated the Protégé editor in a more detailed way, highlighting the


Figure

The Class tab is responsible to give to the user the opportunity to create/edit the ontological classes. In the Properties tab the editor allow to create the properties and connect to a specific class. It is possible to express the type of property (object, String, Integer, etc). The SPARQL, is the responsible to query the ontological model, is created a query very similar with (SQL) and then executed, the result can analysed on thethe Query sector. The Instance tab permit the creation of values, the classes can be instantiated to create not a Schema but data with some properties of the schema model. The user has the opportunity to install or create himsections (Class tab, Instances tab, etc.) are very mouldable and we can change the position.

Protégé architecture was developed under Jena Framework. Jena is one of the most widely used Java APIs for RDF and OWL, providing services for model representation, parsing, database persistence, querying and some visualization tools. Protégéclose relationship with Jena, just like it is illustrated in


Figure 29: Details of the Protégé editor

The Class tab is responsible to give to the user the opportunity to create/edit the ontological classes. In the Properties tab the editor allow to create the properties and

to a specific class. It is possible to express the type of property (object, String, Integer, etc). The SPARQL, is the responsible to query the ontological model, is created a query very similar with (SQL) and then executed, the result can analysed on thethe Query sector. The Instance tab permit the creation of values, the classes can be instantiated to create not a Schema but data with some properties of the schema model. The user has the opportunity to install or create him-self more plug-in for the editor. These sections (Class tab, Instances tab, etc.) are very mouldable and we can change the position.

Protégé architecture was developed under Jena Framework. Jena is one of the most widely used Java APIs for RDF and OWL, providing services for model representation, parsing, database persistence, querying and some visualization tools. Protégé-OWL has alwayclose relationship with Jena, just like it is illustrated in Figure 30.

63

The Class tab is responsible to give to the user the opportunity to create/edit the ontological classes. In the Properties tab the editor allow to create the properties and

to a specific class. It is possible to express the type of property (object, String, Integer, etc). The SPARQL, is the responsible to query the ontological model, is created a query very similar with (SQL) and then executed, the result can analysed on the right side of the Query sector. The Instance tab permit the creation of values, the classes can be instantiated to create not a Schema but data with some properties of the schema model.

in for the editor. These sections (Class tab, Instances tab, etc.) are very mouldable and we can change the position.

Protégé architecture was developed under Jena Framework. Jena is one of the most widely used Java APIs for RDF and OWL, providing services for model representation, parsing,

OWL has always had a


Figure 30: Protégé architecture diagram related to the 3.x

3.7. Tecnomatix Plant Simulate


Tecnomatix Plant Simulation (TPS)modeling, simulation, and analysis of digital models of manufacturing and logistic systems. Based on this simulation tool

· the functional structure of a manufacturing system,

· the material flow within a manufacturing system,

· the temporal conditions of the use of manufacturing resources,

· the control strategy of the manufacturing execution system layer of a manufacturing system

can be modeled, analysed and optimized.

TSP enables the structured design of manufacturing system models based on system components and its connection and concretization. After development of the manufacturing system models these systems be applied for

· Validation of developed structures and control strategies,

· Comparison of existing and planned systems variants, and

· Optimization of existing and planned systems,

4Seehttp://www.plm.automation.siemens.com/de_de/products/tecnomatix/plant_design/plant_simulation.shtml


: Protégé architecture diagram related to the 3.x series of Protégé

Tecnomatix Plant Simulate

Tool description

Tecnomatix Plant Simulation (TPS)4 is an discrete event system based simulation tool for modeling, simulation, and analysis of digital models of manufacturing and logistic systems.

the functional structure of a manufacturing system,

the material flow within a manufacturing system,

the temporal conditions of the use of manufacturing resources,

the control strategy of the manufacturing execution system layer of a facturing system

can be modeled, analysed and optimized.

TSP enables the structured design of manufacturing system models based on system components and its connection and concretization. After development of the manufacturing system models these systems can be evaluated by simulation experiments. Thereby, TSP can

Validation of developed structures and control strategies,

Comparison of existing and planned systems variants, and

Optimization of existing and planned systems,

Seehttp://www.plm.automation.siemens.com/de_de/products/tecnomatix/plant_design/plant_simulation.shtml

64

series of Protégé

is an discrete event system based simulation tool for modeling, simulation, and analysis of digital models of manufacturing and logistic systems.

the temporal conditions of the use of manufacturing resources,

the control strategy of the manufacturing execution system layer of a

TSP enables the structured design of manufacturing system models based on system components and its connection and concretization. After development of the manufacturing

can be evaluated by simulation experiments. Thereby, TSP can

Seehttp://www.plm.automation.siemens.com/de_de/products/tecnomatix/plant_design/plant_simulation.shtml


All related to global manufacturing system down to local manufacturing seats or parts of them.

TSP contains capabilities for the automatic generation of statistics and result visualization supporting the use of the simulation experiment results.

For that purpose this tool provides means to model manufacturing systems by

· defining the manufacturing system resources and its interconnection by material flow systems and

· defining the major control rules for the processing and the flow of work pieces inclusing its timing conditi

Facing this functionality range of the tool can be exploited within the phases Raw Planning and Detailed Planning as well as Use and Maintenance of the Solution Business as depicted in Figure 31.

Figure 31: Use of Tecnomatix Plant Simulate in Engineering Phases

The tool can provide 2D and 3D views of system models and works in amanner. The basic elements of the modeling capabilities are the classes of material flow objects, resource objects, moveable objects, and information flow objects, as well as the programming capabilities for methods behind based on SimTalkmodeling of manufacturing systems, are contained in the class library of the tool.

Classes and objects

Objects are the basic elements of the modeling capability of TPS. These objects are instantiated from the classes given or

Each object has attributes (acting like variables) and methods, defined in the basic library, related to it. They are usable to control the object behavior from the simulation point of view and from the visualitation point obased on predeveloped dialog as depicted in

Raw planning

Detailed planning

Market analysis

Raw planning

Solution Business

Product Business


lobal manufacturing system down to local manufacturing seats or parts of

TSP contains capabilities for the automatic generation of statistics and result visualization supporting the use of the simulation experiment results.

provides means to model manufacturing systems by

defining the manufacturing system resources and its interconnection by material

defining the major control rules for the processing and the flow of work pieces inclusing its timing conditions.

Facing this functionality range of the tool can be exploited within the phases Raw Planning and Detailed Planning as well as Use and Maintenance of the Solution Business as

: Use of Tecnomatix Plant Simulate in Engineering Phases

The tool can provide 2D and 3D views of system models and works in amanner. The basic elements of the modeling capabilities are the classes of material flow objects, resource objects, moveable objects, and information flow objects, as well as the programming capabilities for methods behind based on SimTalk. All objects, useable for the modeling of manufacturing systems, are contained in the class library of the tool.

Objects are the basic elements of the modeling capability of TPS. These objects are instantiated from the classes given or modeled in the class library.

s (acting like variables) and methods, defined in the basic library, related to it. They are usable to control the object behavior from the simulation point of view and from the visualitation point of view. They can be set / changed / implemented based on predeveloped dialog as depicted in Figure 32.

Implem-entation

Installa-tion

Commis-sioning Use

Detailed planning

Implem-entation SalesCustomi-

zing

65

lobal manufacturing system down to local manufacturing seats or parts of

TSP contains capabilities for the automatic generation of statistics and result visualization

provides means to model manufacturing systems by

defining the manufacturing system resources and its interconnection by material

defining the major control rules for the processing and the flow of work pieces

Facing this functionality range of the tool can be exploited within the phases Raw Planning and Detailed Planning as well as Use and Maintenance of the Solution Business as

: Use of Tecnomatix Plant Simulate in Engineering Phases

The tool can provide 2D and 3D views of system models and works in a object oriented manner. The basic elements of the modeling capabilities are the classes of material flow objects, resource objects, moveable objects, and information flow objects, as well as the

. All objects, useable for the modeling of manufacturing systems, are contained in the class library of the tool.

Objects are the basic elements of the modeling capability of TPS. These objects are

s (acting like variables) and methods, defined in the basic library, related to it. They are usable to control the object behavior from the simulation point of

f view. They can be set / changed / implemented

Mainte-nance

Support


Figure 32:Windows fo

All objects have a common set of basic methods and basic attributes. Examplpredefined methods are

· derive implementing the inheritance of classes within the class library,

· updateDialog implementing the writinattributes after user intervention,

· duplicate implementing the duplication of a class within the class library,

· createObject implementing the insta

· openDialog implementing the start of a user interaction with a object,

· sendMessage implementing the interaction among objects, and

· deleteObject implementing the end of life of an object in a network.

Further methods and attributby users depending on the modeling intentions of the user.

Classes can be developed within the class library. Here classes can be derived from other classes and detailed as it is usually possible in object oriented approaches. For dclass user defined attributes and user defined methods can be developed (see a larger explanation on library structure and use below).

Moveable objects

Moveable objects are objects used to transported and processed within a manufacturing system. The predefined basic moveable objects are vehicle, transport unit, and transport assistance unit.

Moveable objects will “flow” during the simulation process over the material flow objects and the resource objexploiting the methods of all related objects.


:Windows for variables and methods of objects

All objects have a common set of basic methods and basic attributes. Exampl

derive implementing the inheritance of classes within the class library,

updateDialog implementing the writing of changed attributattributes after user intervention,

duplicate implementing the duplication of a class within the class library,

createObject implementing the instantiation of a class within a network,

implementing the start of a user interaction with a object,

sendMessage implementing the interaction among objects, and

deleteObject implementing the end of life of an object in a network.

Further methods and attributes are usually object specific predefined or can be defined by users depending on the modeling intentions of the user.

Classes can be developed within the class library. Here classes can be derived from other classes and detailed as it is usually possible in object oriented approaches. For dclass user defined attributes and user defined methods can be developed (see a larger explanation on library structure and use below).

Moveable objects are objects used to model work pieces, transportation units, etc. d and processed within a manufacturing system. The predefined basic moveable

objects are vehicle, transport unit, and transport assistance unit.

Moveable objects will “flow” during the simulation process over the material flow objects and the resource objects. Within this flow they will be controlled by these objects exploiting the methods of all related objects.

66

r variables and methods of objects

All objects have a common set of basic methods and basic attributes. Examples of these

derive implementing the inheritance of classes within the class library,

g of changed attribute values in the

duplicate implementing the duplication of a class within the class library,

tiation of a class within a network,

implementing the start of a user interaction with a object,

sendMessage implementing the interaction among objects, and

deleteObject implementing the end of life of an object in a network.

fined or can be defined

Classes can be developed within the class library. Here classes can be derived from other classes and detailed as it is usually possible in object oriented approaches. For detailing a class user defined attributes and user defined methods can be developed (see a larger

work pieces, transportation units, etc. d and processed within a manufacturing system. The predefined basic moveable

Moveable objects will “flow” during the simulation process over the material flow ects. Within this flow they will be controlled by these objects


Moveable objects have a basic set of predefined attributsize information and statistics information. Additional moveable objects in the dialog depicted in

Figure 33: Attribut

Material flow objects

Material flow objects are used to model the logistics components of the manufacturing system. Example of material flow objects are turntables, transport lines, flow control stations, storages, buffers, sinks and sources, which are direct material flow relaas mounting stations and unmointing stations, which are processing stations.

All material flow objects have a common basic set of attributmaterial flow control information, timing information and statistics information. user defined attributes can be attached to them using the dialog depicted in

For control purposes user defined methods can be

Material flow objects can be distinguished according to its activity level. Active material flow objects will take up moveable objects, process, store, etc. them for a time span controllable by various timing modes, control decisions. Examples of active material flow objects are buffers and transfer lines. In contrast to that passive material flow objects will take up moveable objects but not transfer them to further objects automatically. To pass moveable objects to successor objects passive material flow objects have to be explicitely triggered by calling an appropriate method.


Moveable objects have a basic set of predefined attributes including for example a name, size information and statistics information. Additional attributes can be defined for moveable objects in the dialog depicted in Figure 33.

: Attribute configuration of moveable objects

Material flow objects are used to model the logistics components of the manufacturing system. Example of material flow objects are turntables, transport lines, flow control stations, storages, buffers, sinks and sources, which are direct material flow relaas mounting stations and unmointing stations, which are processing stations.

All material flow objects have a common basic set of attributes containing a name, material flow control information, timing information and statistics information.

s can be attached to them using the dialog depicted in

For control purposes user defined methods can be implemented for material flow objects.

Material flow objects can be distinguished according to its activity level. Active material flow objects will take up moveable objects, process, store, etc. them for a time span controllable by various timing modes, and transmit them to successor objects depending on control decisions. Examples of active material flow objects are buffers and transfer lines. In contrast to that passive material flow objects will take up moveable objects but not transfer

objects automatically. To pass moveable objects to successor objects passive material flow objects have to be explicitely triggered by calling an appropriate method.

67

s including for example a name, s can be defined for

oveable objects

Material flow objects are used to model the logistics components of the manufacturing system. Example of material flow objects are turntables, transport lines, flow control stations, storages, buffers, sinks and sources, which are direct material flow related, as well as mounting stations and unmointing stations, which are processing stations.

s containing a name, material flow control information, timing information and statistics information. Additionally,

s can be attached to them using the dialog depicted in Figure 34.

implemented for material flow objects.

Material flow objects can be distinguished according to its activity level. Active material flow objects will take up moveable objects, process, store, etc. them for a time span

and transmit them to successor objects depending on control decisions. Examples of active material flow objects are buffers and transfer lines. In contrast to that passive material flow objects will take up moveable objects but not transfer

objects automatically. To pass moveable objects to successor objects passive material flow objects have to be explicitely triggered by calling an appropriate method.


Figure 34: Attribut

Resource objects

Resource objects represent human centered objects within the manufacturing system. Thus working places, foot pathes, workers belong to the resources. In addition, brookers and exporters will model services provided and consumed by humans wit

Usually, resources are associated to the material flow objects single station, parallel station, mounting station, and unmounting station.

Information flow objects

Information flow objects are used to model the flow and processing of informparallel to the material flow. They are also used to control the material flow.

The main information flow objects are the following:

· Methods and variables are used to implement the control of the modeled manufacturing system. Variables are global information transfer within the simulation run. Methods are user implemented methods controlling the material flow based on object attributMethods are implemented in the script language SimTalk

· Lists and tables like cards, tabs or queues are used to provide arrays of information in a structured and easy

· Triggers and generators are used to control the creation of objects.

· The attribute explorer is used to manage the attributes of tsimulation run.

5 Attributs cover values of s special semantics modeling the current state and the bahaviuor of an object. They are completely dependent on this object. In contrast to this, variables are independent objects covering an value with a user defined semantics of a specific data type.6 S. Bangsow: Fertigungssimulation mit Plant Simulation und SimTalk, Hanser Fachbuchverlag, 2008, ISBN 3446-41490-8


: Attribute configuration of material flow objects

Resource objects represent human centered objects within the manufacturing system. Thus working places, foot pathes, workers belong to the resources. In addition, brookers and exporters will model services provided and consumed by humans within the system.

Usually, resources are associated to the material flow objects single station, parallel station, mounting station, and unmounting station.

Information flow objects are used to model the flow and processing of informparallel to the material flow. They are also used to control the material flow.

The main information flow objects are the following:

Methods and variables are used to implement the control of the modeled manufacturing system. Variables are global accessible objects exploited for information transfer within the simulation run. Methods are user implemented methods controlling the material flow based on object attributMethods are implemented in the script language SimTalk6.

Lists and tables like cards, tabs or queues are used to provide arrays of information in a structured and easy accessible way.

Triggers and generators are used to control the creation of objects.

The attribute explorer is used to manage the attributes of the objects during the

Attributs cover values of s special semantics modeling the current state and the bahaviuor of an object. They are completely dependent on this object. In contrast to this, variables are independent objects covering an value

a specific data type. S. Bangsow: Fertigungssimulation mit Plant Simulation und SimTalk, Hanser Fachbuchverlag, 2008, ISBN 3

68

configuration of material flow objects

Resource objects represent human centered objects within the manufacturing system. Thus working places, foot pathes, workers belong to the resources. In addition, brookers and

hin the system.

Usually, resources are associated to the material flow objects single station, parallel

Information flow objects are used to model the flow and processing of information in parallel to the material flow. They are also used to control the material flow.

Methods and variables are used to implement the control of the modeled objects exploited for

information transfer within the simulation run. Methods are user implemented methods controlling the material flow based on object attributes and variables5.

Lists and tables like cards, tabs or queues are used to provide arrays of

Triggers and generators are used to control the creation of objects.

he objects during the

Attributs cover values of s special semantics modeling the current state and the bahaviuor of an object. They are completely dependent on this object. In contrast to this, variables are independent objects covering an value

S. Bangsow: Fertigungssimulation mit Plant Simulation und SimTalk, Hanser Fachbuchverlag, 2008, ISBN 3-


· Date interfaces are used to exchange information with further applications and tools.

Further objects

In addition exist objects related to a complete simulation project. One of the most important of these objects is thcontrol (start, stop, parameterize) the simulation run of a complete simulation project. Within each simulation project there shall be only one event manager.

Class library

The class library is the central repository for all predefined and user defined classes useable within a modeling and simulation project. It contains the basic libararies material flow, resources, information flow, surface, moveable objects, and tools which are predefined within the TPS.

The class library can be extended by developing user defined class libraries exploiting inheritance, enrichment and network definition (see below) and by importing existing library parts developed by different sources.

Within the class library the different classes are organized within folders which can be hierarchically structured. But this structure does not provide a syntactical or brelation among classes of the same folder or classes in the folder hierarchy. It is only for semantical user assistance. The inheritance relation defining syntactically end bdependencies among classes is completely independent from the folder structure.

Nevertheless, the folder structure of the class library is used to enable export, import, and management of classes and class library parts and provides the user with an organization and search structure for objects to be used within modeling activities.

Networks

Networks are special objects used to model manufacturing system structures within. They are organized within the class library and can be structured in the same way as all other objects.


Date interfaces are used to exchange information with further applications and

In addition exist objects related to a complete simulation project. One of the most important of these objects is the event manager (Ereignisverwalter). This object is used to control (start, stop, parameterize) the simulation run of a complete simulation project. Within each simulation project there shall be only one event manager.

e central repository for all predefined and user defined classes useable within a modeling and simulation project. It contains the basic libararies material flow, resources, information flow, surface, moveable objects, and tools which are predefined

The class library can be extended by developing user defined class libraries exploiting inheritance, enrichment and network definition (see below) and by importing existing library parts developed by different sources.

he different classes are organized within folders which can be hierarchically structured. But this structure does not provide a syntactical or brelation among classes of the same folder or classes in the folder hierarchy. It is only for

l user assistance. The inheritance relation defining syntactically end bdependencies among classes is completely independent from the folder structure.

Nevertheless, the folder structure of the class library is used to enable export, import, management of classes and class library parts and provides the user with an

organization and search structure for objects to be used within modeling activities.

Networks are special objects used to model manufacturing system structures within. They are organized within the class library and can be structured in the same way as all other

69

Date interfaces are used to exchange information with further applications and

In addition exist objects related to a complete simulation project. One of the most e event manager (Ereignisverwalter). This object is used to

control (start, stop, parameterize) the simulation run of a complete simulation project.

e central repository for all predefined and user defined classes useable within a modeling and simulation project. It contains the basic libararies material flow, resources, information flow, surface, moveable objects, and tools which are predefined

The class library can be extended by developing user defined class libraries exploiting inheritance, enrichment and network definition (see below) and by importing existing library

he different classes are organized within folders which can be hierarchically structured. But this structure does not provide a syntactical or behavioral relation among classes of the same folder or classes in the folder hierarchy. It is only for

l user assistance. The inheritance relation defining syntactically end behavioral dependencies among classes is completely independent from the folder structure.

Nevertheless, the folder structure of the class library is used to enable export, import, management of classes and class library parts and provides the user with an

organization and search structure for objects to be used within modeling activities.

Networks are special objects used to model manufacturing system structures within. They are organized within the class library and can be structured in the same way as all other



Figure 35: Class library example

70


Network objects provide a modeling surface to position objects and networks within a visual observable area and connect them to a network. As networks can be embedded in networks exploiting special interface objects of networks a hierarchical structure of networks can be established following the hierarchical structure of a manufacturing system.

SimTalk

Simtalk is a script based programming language used to implement user defined methods. These methods are executed on an interpreter based mode during the srun of the modeled manufacturing system.

SimTalk provides basic programming structures for implementing decisions based on IF .. THEN .. ELSE and implementing cyclic processing. In addition it provides possibilities to access and use attribute and variable values.


The representation of the complete data set relevant for the mechatronical concept as defined in deliverable 4.2 is restricted within TPS. This is based on the specialized focus and information modeling range reflinformation sets

· Hierarchy of manufacturing cells and resources,

· High level 3D CAD data of the manufacturing system,

· Functional models and functional parameters of the resources and products, and

· Signal information of the resources and products

compared to the information sets given in deliverable 4.2.


Figure 36: Network example


Simtalk is a script based programming language used to implement user defined methods. These methods are executed on an interpreter based mode during the srun of the modeled manufacturing system.

SimTalk provides basic programming structures for implementing decisions based on IF .. THEN .. ELSE and implementing cyclic processing. In addition it provides possibilities to

d variable values.


The representation of the complete data set relevant for the mechatronical concept as defined in deliverable 4.2 is restricted within TPS. This is based on the specialized focus and information modeling range reflected within TPS. TPS enables the

Hierarchy of manufacturing cells and resources,

High level 3D CAD data of the manufacturing system,

Functional models and functional parameters of the resources and products, and

nformation of the resources and products

compared to the information sets given in deliverable 4.2.

71


Simtalk is a script based programming language used to implement user defined methods. These methods are executed on an interpreter based mode during the simulation

SimTalk provides basic programming structures for implementing decisions based on IF .. THEN .. ELSE and implementing cyclic processing. In addition it provides possibilities to

The representation of the complete data set relevant for the mechatronical concept as defined in deliverable 4.2 is restricted within TPS. This is based on the specialized focus and

ected within TPS. TPS enables the modeling of the

Functional models and functional parameters of the resources and products, and


In general all these information are related to the manufacturing execution control (MES) layer of the manufacturing system. All other information of the expressible in TPS as indicated in the TPS to express ENGINEERIN

Figure 37: Information sets reflected by Tecnomatix Plant Simulate

Nevertheless, TPS enables the application of mechatronic concepts within the engineering of manufacturing systems in a basic way. A basic mechatronic information object can be established using a network object and embedding within the network object

· the underlying resources of the mechatronical units (independent of either they are objects or they are networks)

· the control for the underlying resources as methods

· the necessary control information to the underlying resources as tables, variables, queues, etc., and

· the material flow interfaces as input and output objects derived from the interface object within the mat

This structure is exemplarily modeled in



controlled behavior




In general all these information are related to the manufacturing execution control (MES) layer of the manufacturing system. All other information of the plant component

in TPS as indicated in Figure 37. This figure depicts the focus of the capabilities of ENGINEERING ARTIFACTs with respect to its specific focus of use.

: Information sets reflected by Tecnomatix Plant Simulate


underlying resources of the mechatronical units (independent of either they are objects or they are networks)

the control for the underlying resources as methods

the necessary control information to the underlying resources as tables, variables,

the material flow interfaces as input and output objects derived from the interface object within the material form object library.

This structure is exemplarily modeled in Figure 38.









descriptions• …




72

In general all these information are related to the manufacturing execution control (MES) ant component are not

. This figure depicts the focus of the capabilities of s with respect to its specific focus of use.

: Information sets reflected by Tecnomatix Plant Simulate


underlying resources of the mechatronical units (independent of either they

the necessary control information to the underlying resources as tables, variables,

the material flow interfaces as input and output objects derived from the



functional models



Figure 38: Basic Implementation for Mechatronical Units in TPS

This approach enables the hierarchical structuring of the manufacturing system combining material flow with control decisiflow hierarchy but an implicit based on global variables if required.

Independent of the made statements of this section it has to be mentioned, that TSP is focused on only one special engineering activity wmanufacturing systems, the simulation of plant structures and controls. This is reflected by the portion of the information set of the

3.8. Tecnomatix Process Designer


The Tecnomatix Process Designer (PD) is a database based software system for the high level planning of manufacturing lines, workflows, and manufacturing processes for complete manufacturing system. It is intended to be used for:

· Overall process planning

· Comparison of alternatives

· Optimization of manufacturing line throughput

· Design of different variants of manufacturing lines and cells

· Evaluation of change impacts

· Cost calculation

· Cycle time calculation

and further activities.

The PD is based on a three tire established by an Oracle server containing a set of databases. Each data base can contain


: Basic Implementation for Mechatronical Units in TPS

This approach enables the hierarchical structuring of the manufacturing system combining material flow with control decisions. It will not provide an explicit information flow hierarchy but an implicit based on global variables if required.

Independent of the made statements of this section it has to be mentioned, that TSP is focused on only one special engineering activity within the engineering process of manufacturing systems, the simulation of plant structures and controls. This is reflected by the portion of the information set of the plant component expressible within TSP.

Tecnomatix Process Designer

Tool description

Tecnomatix Process Designer (PD) is a database based software system for the high level planning of manufacturing lines, workflows, and manufacturing processes for complete manufacturing system. It is intended to be used for:

Overall process planning

arison of alternatives

Optimization of manufacturing line throughput

Design of different variants of manufacturing lines and cells

Evaluation of change impacts

Cycle time calculation

The PD is based on a three tire architecture as given in Figure 39. The lowest layer is established by an Oracle server containing a set of databases. Each data base can contain

73

: Basic Implementation for Mechatronical Units in TPS

This approach enables the hierarchical structuring of the manufacturing system ons. It will not provide an explicit information

Independent of the made statements of this section it has to be mentioned, that TSP is ithin the engineering process of

manufacturing systems, the simulation of plant structures and controls. This is reflected by within TSP.

Tecnomatix Process Designer (PD) is a database based software system for the high level planning of manufacturing lines, workflows, and manufacturing processes for complete

. The lowest layer is established by an Oracle server containing a set of databases. Each data base can contain


sets of projects all represented in similar schemata. Within each project tables for resources, operations, and product are distinguished.

The second layer is represented by a sointerface between PD clients and management capabilities of the PD. In addition it provides access to the soroot, a file path storing additional files outside of the Oracle database. This system root is used for example to store 3D information files. Each eMused within the Oracle databases. Hence, for each used schemata for project data structuring one EM-Server has to be exploited.

The upper layer of the architecture is provided by the PD cinterface of the PD.

This architecture will enable different users to use the system concurrently exploiting the same database. In addition this architecture enables an easy extension by additional clients as well as databases.

Figure

7 Thisnaminghashistoricalreasons.ThePDhasbeenemergedfromthetooleMTecnomatix.IthasbeenextendedandrenamedaftertheacquisitionofTecnomatixbySiemens.


of projects all represented in similar schemata. Within each project tables for resources, operations, and product are distinguished.

The second layer is represented by a so-called eM-Server7. It represents an intelligent interface between PD clients and Oracle database providing the data access and user management capabilities of the PD. In addition it provides access to the soroot, a file path storing additional files outside of the Oracle database. This system root is

store 3D information files. Each eM-Server is bound to one schemata used within the Oracle databases. Hence, for each used schemata for project data

Server has to be exploited.

The upper layer of the architecture is provided by the PD client establishing the user

This architecture will enable different users to use the system concurrently exploiting the same database. In addition this architecture enables an easy extension by additional clients

Figure 39: Software architecture of PD

Thisnaminghashistoricalreasons.ThePDhasbeenemergedfromthetooleM-PlannerofthecompanyhasbeenextendedandrenamedaftertheacquisitionofTecnomatixbySiemens.

74

of projects all represented in similar schemata. Within each project tables for resources,

. It represents an intelligent Oracle database providing the data access and user

management capabilities of the PD. In addition it provides access to the so-.called system root, a file path storing additional files outside of the Oracle database. This system root is

Server is bound to one schemata used within the Oracle databases. Hence, for each used schemata for project data

lient establishing the user

This architecture will enable different users to use the system concurrently exploiting the same database. In addition this architecture enables an easy extension by additional clients

PlannerofthecompanyhasbeenextendedandrenamedaftertheacquisitionofTecnomatixbySiemens.


The user interface of the PD is based on the internal data structure of the PD covering three types of general information: resources, products, and operations. These three categories follow the Product-

Thus, the main window of the user interfaces consists of parts for the product tree, the operations tree, and the resource tree and additionally of parts for the navigation tree, tgraphical representation of objects and finally sets of menus for different purposes. This is depicted in Figure 40.

The navigation tree structuredatabase. It represents the content of an opened project and the libraries exploited within. Here, all relevant data can be accessed. From this tree structure all relevant information can be extracted by users to add them to the other three tree structures for resources, products, and operations (by drag&drop).

The product tree provides the partrepresentation of the Bill of Material of the product. product structures of all products provided by the planned manufacturing system and its structuring in product groups.

The operation tree is a representation of all manufacturing steps executed by the planned manufacturing system it represents the Bill of Operations relevant for the product set of the manufacturing system. Thereby, it provides a hierarchical structure of the operations set with an operation

The resource tree provides a hierarthe manufacturing system exploiting a resource complete manufacturing system as highest level the resource tree the resource tree enumerates all assets used withinhierarchy of system – cell – function units all manufacturing tools, relevant human resources, etc.

The content of the three trees for resources, operatThus, there are relations defining which part of a product is manufactured by which operation using which resource.

The graphical representation provides a 3D view on selected objects. It is based on the object selected within the navigation structure which contains the three trees named above. The graphic representation is synchronized with the three trees and highlights the object selected in a tree.


The user interface of the PD is based on the internal data structure of the PD covering three types of general information: resources, products, and operations. These three

-Process-Resource categorization with operations for processes.

Thus, the main window of the user interfaces consists of parts for the product tree, the operations tree, and the resource tree and additionally of parts for the navigation tree, tgraphical representation of objects and finally sets of menus for different purposes. This is

The navigation tree structure is the starting point for the navigation within the process database. It represents the content of an opened project and the libraries exploited within. Here, all relevant data can be accessed. From this tree structure all relevant information can

acted by users to add them to the other three tree structures for resources, products, and operations (by drag&drop).

The product tree provides the part-subpart hierarchy of a product. It is a special representation of the Bill of Material of the product. It is mainly exploited to represent the product structures of all products provided by the planned manufacturing system and its structuring in product groups.

The operation tree is a representation of all manufacturing steps executed by the turing system it represents the Bill of Operations relevant for the product

set of the manufacturing system. Thereby, it provides a hierarchical structure of the operations set with an operation – suboperation hierarchy.

The resource tree provides a hierarchical structuring of the manufacturing resources of the manufacturing system exploiting a resource – subresource relation. Starting with a complete manufacturing system as highest level the resource tree the resource tree enumerates all assets used within the manufacturing system following the mechatronical

function units – subunits – component – device. It also includes all manufacturing tools, relevant human resources, etc.

The content of the three trees for resources, operations, and products are interlinked. Thus, there are relations defining which part of a product is manufactured by which operation using which resource.

The graphical representation provides a 3D view on selected objects. It is based on the within the navigation structure which contains the three trees named above.

The graphic representation is synchronized with the three trees and highlights the object

75

The user interface of the PD is based on the internal data structure of the PD covering three types of general information: resources, products, and operations. These three

Resource categorization with operations for processes.

Thus, the main window of the user interfaces consists of parts for the product tree, the operations tree, and the resource tree and additionally of parts for the navigation tree, the graphical representation of objects and finally sets of menus for different purposes. This is

is the starting point for the navigation within the process database. It represents the content of an opened project and the libraries exploited within. Here, all relevant data can be accessed. From this tree structure all relevant information can

acted by users to add them to the other three tree structures for resources, products,

subpart hierarchy of a product. It is a special It is mainly exploited to represent the

product structures of all products provided by the planned manufacturing system and its

The operation tree is a representation of all manufacturing steps executed by the turing system it represents the Bill of Operations relevant for the product

set of the manufacturing system. Thereby, it provides a hierarchical structure of the

chical structuring of the manufacturing resources of subresource relation. Starting with a

complete manufacturing system as highest level the resource tree the resource tree the manufacturing system following the mechatronical

device. It also includes

ions, and products are interlinked. Thus, there are relations defining which part of a product is manufactured by which

The graphical representation provides a 3D view on selected objects. It is based on the within the navigation structure which contains the three trees named above.

The graphic representation is synchronized with the three trees and highlights the object


The PD provides a library concept for resources and operations as well as for complete manufacturing systems with products. Within this concept libraries are intended as mean for information transfer between different projects as well as for reuse Thereforusually resources are stored accompanied by operations usually executed within these operations.

For the development of libraries a special user role is defined. This role is responsible for the creation, update and deletion of objects wiopen for each normal user (only rendered by library visibility rules). Normal users can import a library at project start (or at any other moment of project execution) and use the content in the planning process. In this case it is intended that the user will create an asset hierarchy in the project and complete this hierarchy by using prototype objects from the library.

In addition to the named elements PD can contain 3D visualization of resources and operations in the system root. These objects will be accesses in the case a planned system is visualized in the graphic representation.

The structure of system root and library is usually synchronized as given in

Navigation tree

Operation tree


Figure 40: PD user interface

The PD provides a library concept for resources and operations as well as for complete manufacturing systems with products. Within this concept libraries are intended as mean for information transfer between different projects as well as for reuse Thereforusually resources are stored accompanied by operations usually executed within these

For the development of libraries a special user role is defined. This role is responsible for the creation, update and deletion of objects within a library. The use of the library content is open for each normal user (only rendered by library visibility rules). Normal users can import a library at project start (or at any other moment of project execution) and use the content

ocess. In this case it is intended that the user will create an asset hierarchy in the project and complete this hierarchy by using prototype objects from the library.

In addition to the named elements PD can contain 3D modeling objects for the on of resources and operations in the system root. These objects will be accesses

in the case a planned system is visualized in the graphic representation.

The structure of system root and library is usually synchronized as given in

Navigation tree

Operation tree

Resource tree

Product tree

Grafic representation

76

The PD provides a library concept for resources and operations as well as for complete manufacturing systems with products. Within this concept libraries are intended as mean for information transfer between different projects as well as for reuse Therefore, in a library usually resources are stored accompanied by operations usually executed within these

For the development of libraries a special user role is defined. This role is responsible for thin a library. The use of the library content is

open for each normal user (only rendered by library visibility rules). Normal users can import a library at project start (or at any other moment of project execution) and use the content

ocess. In this case it is intended that the user will create an asset hierarchy in the project and complete this hierarchy by using prototype objects from the library.

ing objects for the on of resources and operations in the system root. These objects will be accesses

The structure of system root and library is usually synchronized as given in Figure 41.



Within PD different concepts are strongly distinguished, directories, administratstructures and model elements. The model elements can be either resources with 3D geometries, operations, or products with 3D geometries.

The product elements consist of a hierarchy of product parts representing the structural properties of the part – subpart relation. Each product part may be related to a 3D visualization object enabling the visual representation of the product in the different creation stages in the graphic representation field of the user interface.

Resources are seen as assets of anhumans, etc. Like products they establish a hierarchy based on resource relations and are related to 3D objects enabling a visual representation.

Both, resources and products, are interlinked usmanufacturing activities executed by resources to create product stages (mounting, processing, etc.). Operations will have a hierarchical structure as well as a time and logic based sequencing possibly represented by PE

In any case the three types of objects will render the capability of PD to represent components.


Figure 41: PD library example


Within PD different concepts are strongly distinguished, directories, administratstructures and model elements. The model elements can be either resources with 3D geometries, operations, or products with 3D geometries.

The product elements consist of a hierarchy of product parts representing the structural subpart relation. Each product part may be related to a 3D

visualization object enabling the visual representation of the product in the different creation stages in the graphic representation field of the user interface.

Resources are seen as assets of any type including manufacturing resources, tool, humans, etc. Like products they establish a hierarchy based on resource relations and are related to 3D objects enabling a visual representation.

Both, resources and products, are interlinked using operations. Operations represent manufacturing activities executed by resources to create product stages (mounting, processing, etc.). Operations will have a hierarchical structure as well as a time and logic based sequencing possibly represented by PERT or Gantt Charts.

In any case the three types of objects will render the capability of PD to represent

77

Within PD different concepts are strongly distinguished, directories, administrative structures and model elements. The model elements can be either resources with 3D

The product elements consist of a hierarchy of product parts representing the structural subpart relation. Each product part may be related to a 3D

visualization object enabling the visual representation of the product in the different

y type including manufacturing resources, tool, humans, etc. Like products they establish a hierarchy based on resource – subresource

ing operations. Operations represent manufacturing activities executed by resources to create product stages (mounting, processing, etc.). Operations will have a hierarchical structure as well as a time and logic

In any case the three types of objects will render the capability of PD to represent plant


Following the information sets the storing of the information given in

Figure 42: Information sets of

The first information set belongs to the topologystore device and component hierarchies within the resource hierarchy.

The second set belongs to the mechanical information. It enables the storing of geometry and partially kinematics information.

As part of the function describing information technology descriptions, functional parameters, controlled behavior and uncontrolled behavior can be stored.

Finally the PD can cover generic data mostly belonging to organizational data, technical data and economical data like device IDs, vendor IDs, material descriptions, weights, costs, handbooks, etc.

All other information possibly belonging to a PD. Nevertheless it is possible to exploit mechatronical concepts within PD. The basement for this is the basic representation of a given in PD by a combination of resource objThis structure is either directly contained in a planning data object of the navigation tree, a planning data object of a library, or distributed over the resource, operation and product tree. The first version is given by the Sation_630 object in is represented by the equally named station objects of resource, product, and trees given in Figure 40.



controlled behavior




Following the information sets the plant component can contain the PD enables the storing of the information given in Figure 42.

: Information sets of engineering artifact covered by PD

The first information set belongs to the topology information. It gives the possibility to store device and component hierarchies within the resource hierarchy.

The second set belongs to the mechanical information. It enables the storing of geometry and partially kinematics information.

nction describing information technology descriptions, functional parameters, controlled behavior and uncontrolled behavior can be stored.

Finally the PD can cover generic data mostly belonging to organizational data, technical e device IDs, vendor IDs, material descriptions, weights, costs,

All other information possibly belonging to a engineering artifact cannot be expressed in PD. Nevertheless it is possible to exploit mechatronical concepts within PD. The basement for this is the basic representation of a engineering artifact in PD. This basic representation is given in PD by a combination of resource objects, operation objects, and product objects. This structure is either directly contained in a planning data object of the navigation tree, a planning data object of a library, or distributed over the resource, operation and product

is given by the Sation_630 object in Figure 43 while the second version is represented by the equally named station objects of resource, product, and









descriptions• …




78

can contain the PD enables the

covered by PD

information. It gives the possibility to

The second set belongs to the mechanical information. It enables the storing of geometry

nction describing information technology descriptions, functional parameters, controlled behavior and uncontrolled behavior can be stored.

Finally the PD can cover generic data mostly belonging to organizational data, technical e device IDs, vendor IDs, material descriptions, weights, costs,

cannot be expressed in PD. Nevertheless it is possible to exploit mechatronical concepts within PD. The basement

in PD. This basic representation is ects, operation objects, and product objects.

This structure is either directly contained in a planning data object of the navigation tree, a planning data object of a library, or distributed over the resource, operation and product

while the second version is represented by the equally named station objects of resource, product, and operation



functional models



Figure 43

The inherent possible distribution of for the use of mechatronical concepts in PD limiting its effectiveness.

3.9. Tecnomatix Process Simulate


Tecnomatix Process Simulate (PS) is a database basintended to be used for manufacturing system design and validation. Based on a three tire software structure with a database and a file server as backbone a Server provides clients with the capability to work on engineered pldifferent components related to manufacturing resources, manufacturing processes, and manufactured products implementing the PPR concept. Thus, PS is based on the same structure as PD using the same file formats an

Figure 44: Tecnomatix Process Designer software structure


43: Example of a engineering artifactin PD

The inherent possible distribution of engineering artifact within PD is a strong problem for the use of mechatronical concepts in PD limiting its effectiveness.

Tecnomatix Process Simulate

Tool description

Tecnomatix Process Simulate (PS) is a database based engineering software system intended to be used for manufacturing system design and validation. Based on a three tire software structure with a database and a file server as backbone a Server provides clients with the capability to work on engineered plant models. These plant models consist of different components related to manufacturing resources, manufacturing processes, and manufactured products implementing the PPR concept. Thus, PS is based on the same structure as PD using the same file formats and databases (see section 3.8

: Tecnomatix Process Designer software structure

79

within PD is a strong problem

ed engineering software system intended to be used for manufacturing system design and validation. Based on a three tire software structure with a database and a file server as backbone a Server provides clients

ant models. These plant models consist of different components related to manufacturing resources, manufacturing processes, and manufactured products implementing the PPR concept. Thus, PS is based on the same

3.8).

: Tecnomatix Process Designer software structure


PS is intended to be used for e.G.

· 3D based system development and validation,

· path planning, reachability tests, and placing of robots,

· 3D resource planning including control strategies, and

· Manufacturing system simulation.


As PS is already based on the same data stimplementation of the engineering artifactproducts, resources, and processes these three types of objects have to be combined to a plant component. Nevertheless, following thePS the information modeling capabilities of PS are limited with respect to PD.

PS enables the application of the following information sets:

· Topological data representing the internal hierarchy of a manufacturresource structure.

· Function describing data are part of the process structure. They represent the behavior of a manufacturing process including operation sequences and its detailed parameters.

· Mechanical data are part of the 3d CAD data of the represent the mechanical construction of the resources representing its geometry and kinematics. They have to be available in JT data format.

· Generic data representing additional technical information of the resources like weights or energy consumption.


PS is intended to be used for e.G.

3D based system development and validation,

path planning, reachability tests, and placing of robots,

3D resource planning including control strategies, and

Manufacturing system simulation.


As PS is already based on the same data structure as PD it enables a similar engineering artifact structure. Following the distinction between

products, resources, and processes these three types of objects have to be combined to a . Nevertheless, following the strong focus of the intended functionality of

PS the information modeling capabilities of PS are limited with respect to PD.

PS enables the application of the following information sets:

Topological data representing the internal hierarchy of a manufacturresource structure.

Function describing data are part of the process structure. They represent the behavior of a manufacturing process including operation sequences and its detailed parameters.

Mechanical data are part of the 3d CAD data of the different resources. They represent the mechanical construction of the resources representing its geometry and kinematics. They have to be available in JT data format.

Generic data representing additional technical information of the resources like or energy consumption.

80

ructure as PD it enables a similar structure. Following the distinction between

products, resources, and processes these three types of objects have to be combined to a strong focus of the intended functionality of

PS the information modeling capabilities of PS are limited with respect to PD.

Topological data representing the internal hierarchy of a manufacturing system

Function describing data are part of the process structure. They represent the behavior of a manufacturing process including operation sequences and its

different resources. They represent the mechanical construction of the resources representing its geometry

Generic data representing additional technical information of the resources like


Figure

These information sets are integrated within one planning alternative (Planungsalternative). Thus, such planning alternative will be regarded as ARTIFACT.

Figure 46:



controlled behavior




Figure 45: information sets covered by PS

These information sets are integrated within one planning alternative (Planungsalternative). Thus, such planning alternative will be regarded as

: engineering artifact implementation in PS









descriptions• …




alternative

Process

Resource

Product

81

These information sets are integrated within one planning alternative (Planungsalternative). Thus, such planning alternative will be regarded as ENGINEERING



functional models


Planningalternative

Process structure

Resource structure

Product structure


3.10. Tecnomatix RobCAD


Tecnomatix RobCAD is a CAD/CAM based tool for modeling, simulation, and analysis of industrial robots and other controlled automatic characteristic is the modeling of geometric and kinematic structures and behavior.

Thus, within this tool

· the functional structure of a robot based manufacturing cell,

· the topological structure of such manufactu

· 3D geometry data and kinematic structure of the robots and further agile objects of the manufacturing cell,

· the process structure and control structure of the robot and further agile objects, and

· additional data

can be modeled and analyzed

RobCAD enables the creation and/or import of 3D CAD models and the combination of them with kinematic models and process models (defining the control structure of the robot) to execute a manufacturing cell simulation.

Thus, the modeling capabilities of RobCAD are based on modeling objects for geometry and kinematics information which in parallel enable the modeling of process control data, functional data, and topological data related to them. Exploitwithin the simulation run of the robot cell the controlled movements and behavior of the robots in the cell is visualizedobjects (including robots), to avoid information about the timing of

Beside simulation and analysis, RobCAD enables offline programming of industrial robot systems from various vendors to reduce or in some cases avoidimplementing new manufacturing programs in the real robot cell. Therefore, RobCAD enables the use of a set of interfaces to automatically generate vendor specific robot control programs for different types of robots.

RobCAD enables the description and sequencing of all processes and tasks, which are implemented with manufacturing resources (as for example robots, machines, manual activities). This ability makes visualization and optimization possible of the entire manufacturing cell.

Thereby RobCAD can be applied for

· Planning and simulation of new manufacturing cell projects

· Simulation and optimization of existing manufacturing robot projects


Tecnomatix RobCAD

Tool description

Tecnomatix RobCAD is a CAD/CAM based tool for modeling, simulation, and analysis of industrial robots and other controlled automatic devices in manufacturing systems. Its main characteristic is the modeling of geometric and kinematic structures and behavior.

the functional structure of a robot based manufacturing cell,

the topological structure of such manufacturing cells,

3D geometry data and kinematic structure of the robots and further agile objects of the manufacturing cell,

the process structure and control structure of the robot and further agile objects,

analyzed. The main analysis capabilities are based on simulation.

RobCAD enables the creation and/or import of 3D CAD models and the combination of them with kinematic models and process models (defining the control structure of the robot)

cell simulation.

Thus, the modeling capabilities of RobCAD are based on modeling objects for geometry and kinematics information which in parallel enable the modeling of process control data, functional data, and topological data related to them. Exploiting these information objects within the simulation run of the robot cell the controlled movements and behavior of the

visualized. Thereby, it is possible to simulate the reachability of the agile objects (including robots), to avoid collisions with obstacles in the cell, and to generate information about the timing of behaviors precisely.

Beside simulation and analysis, RobCAD enables offline programming of industrial robot systems from various vendors to reduce or in some cases avoid implementing new manufacturing programs in the real robot cell. Therefore, RobCAD enables the use of a set of interfaces to automatically generate vendor specific robot control programs for different types of robots.

description and sequencing of all processes and tasks, which are implemented with manufacturing resources (as for example robots, machines, manual activities). This ability makes visualization and optimization possible of the entire

ereby RobCAD can be applied for

Planning and simulation of new manufacturing cell projects

Simulation and optimization of existing manufacturing robot projects

82

Tecnomatix RobCAD is a CAD/CAM based tool for modeling, simulation, and analysis of devices in manufacturing systems. Its main

characteristic is the modeling of geometric and kinematic structures and behavior.

3D geometry data and kinematic structure of the robots and further agile objects

the process structure and control structure of the robot and further agile objects,

The main analysis capabilities are based on simulation.

RobCAD enables the creation and/or import of 3D CAD models and the combination of them with kinematic models and process models (defining the control structure of the robot)

Thus, the modeling capabilities of RobCAD are based on modeling objects for geometry and kinematics information which in parallel enable the modeling of process control data,

ing these information objects within the simulation run of the robot cell the controlled movements and behavior of the

. Thereby, it is possible to simulate the reachability of the agile collisions with obstacles in the cell, and to generate

Beside simulation and analysis, RobCAD enables offline programming of industrial robot the complexity of

implementing new manufacturing programs in the real robot cell. Therefore, RobCAD enables the use of a set of interfaces to automatically generate vendor specific robot control

description and sequencing of all processes and tasks, which are implemented with manufacturing resources (as for example robots, machines, manual activities). This ability makes visualization and optimization possible of the entire

Simulation and optimization of existing manufacturing robot projects


The tool can provide 3D views of robot system models and works in an object and function oriented manner. The basic elements of the modeling capabilities are CAD data, kinematic objects like links and joints, and controllers, as well as the programming capabilities based on robot languages.

All these objects are not contained in a defined library. Rof tools to create a project based library manually.

Tool components

RobCAD contains a adaptable set of integrated tool components each developed for a special modeling and simulation purpose. Thus there is a one to one mapping of the information structure for a RobCAD model and the tool component structure itself. The set of tool components can be adapted / extended depending on the available licenses and application case requirements.

Geometry models

For enabling 2D and 3D modeling RobCAD implements a number of CAD tools to realize the full range of creating CAD elements and integrate theSketcher allows the creation of 2D structures. These structures can be used for further 3D operations. The Surface tool can be used to create surfaces for previously defined 2D structures . The 3D Sketcher is able to creatspheres. These objects can be combined using Boolean operations to create more complex 3D objects. With the placement editor the previously created objects can be arranged in the right direction. These tools are

Figure

Kinematics and behavior model

RobCAD also implements a the kinematic and functional behaviors of the robot.

With the kinematics tab it is possible to launch different operations to create a kinematic structure, to combine 3D elements to links, compose add a controller and define a robot based on them. It is depicted in


The tool can provide 3D views of robot system models and works in an object and d manner. The basic elements of the modeling capabilities are CAD data,

kinematic objects like links and joints, and controllers, as well as the programming capabilities based on robot languages.

All these objects are not contained in a defined library. RobCAD rather offers a selection of tools to create a project based library manually.

adaptable set of integrated tool components each developed for a special modeling and simulation purpose. Thus there is a one to one mapping of the information structure for a RobCAD model and the tool component structure itself. The set

s can be adapted / extended depending on the available licenses and application case requirements.

For enabling 2D and 3D modeling RobCAD implements a number of CAD tools to realize the full range of creating CAD elements and integrate them in the project library. The 2D Sketcher allows the creation of 2D structures. These structures can be used for further 3D operations. The Surface tool can be used to create surfaces for previously defined 2D structures . The 3D Sketcher is able to create simple 3D objects like boxes, pyramids and spheres. These objects can be combined using Boolean operations to create more complex 3D objects. With the placement editor the previously created objects can be arranged in the right direction. These tools are depicted in Figure 47.

Figure 47: Geometry modeling in RobCAD

modeling

RobCAD also implements a number of tool components to create, simulate and optimize the kinematic and functional behaviors of the robot.

With the kinematics tab it is possible to launch different operations to create a kinematic structure, to combine 3D elements to links, compose them with joints along defined axis, add a controller and define a robot based on them. It is depicted in Figure

83

The tool can provide 3D views of robot system models and works in an object and d manner. The basic elements of the modeling capabilities are CAD data,

kinematic objects like links and joints, and controllers, as well as the programming

obCAD rather offers a selection

adaptable set of integrated tool components each developed for a special modeling and simulation purpose. Thus there is a one to one mapping of the information structure for a RobCAD model and the tool component structure itself. The set

s can be adapted / extended depending on the available licenses and

For enabling 2D and 3D modeling RobCAD implements a number of CAD tools to realize m in the project library. The 2D

Sketcher allows the creation of 2D structures. These structures can be used for further 3D operations. The Surface tool can be used to create surfaces for previously defined 2D

e simple 3D objects like boxes, pyramids and spheres. These objects can be combined using Boolean operations to create more complex 3D objects. With the placement editor the previously created objects can be arranged in the

number of tool components to create, simulate and optimize

With the kinematics tab it is possible to launch different operations to create a kinematic them with joints along defined axis,

Figure 48.


By adding the created robot to a cell it is possible to test and program the robot or respectively the robot system. Therefore, the motion and the path editor components can be used (see Figure 49).

The motion editor offers the possibility to drive the robot, single joints of the robot, or the tool center point (TCP) to special poses (positions), to mark these poses, and to save them within the project library. The TCP can be driven to every direction and coordinate as possible based on the modeled kinematic system. The complete kinematic structure will automatically calculate the necessary movements of the single joints/axis.

The saved positions of the TCP are available as locations, which can be used to combine them to paths with the path editor. Here also they can be transformed to programs. These can be executed in the motion editor, to execute a collision


Figure 48: Kinematics editor

By adding the created robot to a cell it is possible to test and program the robot or respectively the robot system. Therefore, the motion and the path editor components can

The motion editor offers the possibility to drive the robot, single joints of the robot, or the tool center point (TCP) to special poses (positions), to mark these poses, and to save

em within the project library. The TCP can be driven to every direction and coordinate as possible based on the modeled kinematic system. The complete kinematic structure will automatically calculate the necessary movements of the single joints/axis.

aved positions of the TCP are available as locations, which can be used to combine them to paths with the path editor. Here also they can be transformed to programs. These can be executed in the motion editor, to execute a collision- , joint-limit- or reac

84

By adding the created robot to a cell it is possible to test and program the robot or respectively the robot system. Therefore, the motion and the path editor components can

The motion editor offers the possibility to drive the robot, single joints of the robot, or the tool center point (TCP) to special poses (positions), to mark these poses, and to save

em within the project library. The TCP can be driven to every direction and coordinate as possible based on the modeled kinematic system. The complete kinematic structure will automatically calculate the necessary movements of the single joints/axis.

aved positions of the TCP are available as locations, which can be used to combine them to paths with the path editor. Here also they can be transformed to programs. These

or reachability- test.


Locations can also be created by pick or value in the path editor directly. This enables the creation of exact positions. These positions can be mirrored, copied and deleted. Additionally paths can be reversed and interpolated. Thus the motion and path editors enable the modeling of complex motion paths of robots and its axis and to execute them.

Modelling objects

The main modeling objects of RobCAD are the objects named in the class diFigure 50. It also depicts the internal topological structure in the workcell of RobCAD and the main objects robots and components.

The main modeling objects of RobCAD are

· Work cell

· CAD element

· Frame

· Link

· Joint

· Axis

· Controller

· Component

· Robot.


Figure 49: Behavior modeling

Locations can also be created by pick or value in the path editor directly. This enables the creation of exact positions. These positions can be mirrored, copied and deleted.

lly paths can be reversed and interpolated. Thus the motion and path editors enable the modeling of complex motion paths of robots and its axis and to execute them.

The main modeling objects of RobCAD are the objects named in the class di. It also depicts the internal topological structure in the workcell of RobCAD and the

main objects robots and components.

ing objects of RobCAD are

85

Locations can also be created by pick or value in the path editor directly. This enables the creation of exact positions. These positions can be mirrored, copied and deleted.

lly paths can be reversed and interpolated. Thus the motion and path editors enable the modeling of complex motion paths of robots and its axis and to execute them.

The main modeling objects of RobCAD are the objects named in the class diagram in . It also depicts the internal topological structure in the workcell of RobCAD and the


Figure

The Work cell is the starting point of each modeling activity. It is one representative of a mechatronical system in the manufacturing system, modeled in RobCAD.

A work cell is based on a modeling floor with a defined floor size and a floor grid with a base frame representing the centre of the cell. This is visualized in to execute more than one workcell in one session.

Within a work cell CAD elements and links as geometry objects and all further objects up to components and robots can be integrated successively.

CAD elements are the basic element for visualization of 3D geometries. Tthy physical appearance of a robot and can be defined in a hierarchical way by Boolean combination of different partially basic 3D geometries.

Workcell

Robot

Controller

1

1

1

1..*

1

1 1

1


Figure 50: Main modeling objects of RobCAD

is the starting point of each modeling activity. It is one representative of a mechatronical system in the manufacturing system, modeled in RobCAD.

A work cell is based on a modeling floor with a defined floor size and a floor grid with a esenting the centre of the cell. This is visualized in Figure 51

to execute more than one workcell in one session.

Figure 51: Basic work cell

Within a work cell CAD elements and links as geometry objects and all further objects up to components and robots can be integrated successively.

CAD elements are the basic element for visualization of 3D geometries. Tthy physical appearance of a robot and can be defined in a hierarchical way by Boolean

partially basic 3D geometries.

CAD ElementComponent

Link

Frame

1 1..*

1..*1

1..*

1..*1

2

1

1

1

2

1 1

86

is the starting point of each modeling activity. It is one representative of a

A work cell is based on a modeling floor with a defined floor size and a floor grid with a 51. It is not allowed

Within a work cell CAD elements and links as geometry objects and all further objects up

CAD elements are the basic element for visualization of 3D geometries. The constitute thy physical appearance of a robot and can be defined in a hierarchical way by Boolean

CAD Element

Joint

Axis


A frame is a cartesian coordinate system which can be defined within the work cell on an arbitrary position.

A link consists of at least one CAD element and a frame. It established the basic element for creating components. Created links can be saved in the project library by defining them as components. Links are created in the modeling menu in RobCA

In addition links can contain axis and joints to be used for kinematical connection of links as well as controllers to model the motion behavior of links.

A component is the combination of one or more composed links. It enables tuse of the same links within one work cell. It is possible to compose components by component aggregation.

A special type of component are robots as well as obstacles in the cell, pallets.

A robot is a component setted of linkskinetic structure consists of the joints between the links, two links are chained with exactly one joint, the axis of the joints, the frames and the controller.

The robot can consist of a discretionary amountjoint. For example Figure 52 depicts a 6

This figure also shows the possibility of components to be used to model special tools attached to the robot for manufacturing process execution. RobCAD enables to model the different types of tools like grippers, welding guns, etc..

As seen in the picture the robot has two frames: the base frame on the base and the tool centre point frame (TCPF) on the mounting point at the last end. To make the robot usable it is needed to attach a sub component, for example a tool, on the robot, specially

The controller of the robot can be selected from a robot library implemented in RobCAD. For different cases different controllers are available, for example a controller for a nachi paint tool, as shown in Figure


A frame is a cartesian coordinate system which can be defined within the work cell on an

A link consists of at least one CAD element and a frame. It established the basic element for creating components. Created links can be saved in the project library by defining them as components. Links are created in the modeling menu in RobCAD with the kinematics tab.

In addition links can contain axis and joints to be used for kinematical connection of links as well as controllers to model the motion behavior of links.

A component is the combination of one or more composed links. It enables tuse of the same links within one work cell. It is possible to compose components by

A special type of component are robots as well as obstacles in the cell,

A robot is a component setted of links and a kinetic structure between the links. The kinetic structure consists of the joints between the links, two links are chained with exactly one joint, the axis of the joints, the frames and the controller.

The robot can consist of a discretionary amount of joints, but it has to be at least one depicts a 6-axis-buckling arm robot

Figure 52: Robot examples

This figure also shows the possibility of components to be used to model special tools attached to the robot for manufacturing process execution. RobCAD enables to model the different types of tools like grippers, welding guns, etc..

in the picture the robot has two frames: the base frame on the base and the tool centre point frame (TCPF) on the mounting point at the last end. To make the robot usable it is needed to attach a sub component, for example a tool, on the robot, specially

The controller of the robot can be selected from a robot library implemented in RobCAD. For different cases different controllers are available, for example a controller for a nachi

Figure 53.

87

A frame is a cartesian coordinate system which can be defined within the work cell on an

A link consists of at least one CAD element and a frame. It established the basic element for creating components. Created links can be saved in the project library by defining them

D with the kinematics tab.

In addition links can contain axis and joints to be used for kinematical connection of links

A component is the combination of one or more composed links. It enables the multiple use of the same links within one work cell. It is possible to compose components by

A special type of component are robots as well as obstacles in the cell, work pieces or

and a kinetic structure between the links. The kinetic structure consists of the joints between the links, two links are chained with exactly

of joints, but it has to be at least one

This figure also shows the possibility of components to be used to model special tools attached to the robot for manufacturing process execution. RobCAD enables to model the

in the picture the robot has two frames: the base frame on the base and the tool centre point frame (TCPF) on the mounting point at the last end. To make the robot usable it is needed to attach a sub component, for example a tool, on the robot, specially on the TCP.

The controller of the robot can be selected from a robot library implemented in RobCAD. For different cases different controllers are available, for example a controller for a nachi


Figure

For simple executions it is also possible to use the default controller, it can control standard kinematics based on the well known Denavidcoordinate systems. The standard kinematics controller is not able to execute special tasks. For special purposes the control capabilities of RobCAD can be extended by adding additional user developed controllers. These controllers will implement the required kinematic calculations of coordinate systems.


The representation of the complete data set relevant for the mechatronical concept as defined in Deliverable 4.2 is restricted within RobCAD. This is based on the specialized focus and information modeling range reflected within RobCAD. RobCAD enables the the information sets

· Hierarchy of robot workcells

· High level 3D CAD data of the robot workcell in

· Topological data such as the internal hierarchy of the subordinate devices and interfaces to external devices

· Kinematic data of the robot systems

· Signal information and SPS function blocks

· Generic data as colors, weight, surface area…

compared to the information sets given in

In general all these information are related to the manufacturing execution control (MES) layer of the manufacturing system. All other information of the covered by RobCAD as indicated in of the RobCAD to express ENGINEERING ARTIFAC


Figure 53: Controller example in RobCAD

For simple executions it is also possible to use the default controller, it can control ased on the well known Denavid-Hardenberg

coordinate systems. The standard kinematics controller is not able to execute special tasks. For special purposes the control capabilities of RobCAD can be extended by adding

ped controllers. These controllers will implement the required kinematic calculations of coordinate systems.


The representation of the complete data set relevant for the mechatronical concept as is restricted within RobCAD. This is based on the specialized focus

and information modeling range reflected within RobCAD. RobCAD enables the

Hierarchy of robot workcells

High level 3D CAD data of the robot workcell in the manufacturing system,

Topological data such as the internal hierarchy of the ENGINEERING ARTIFACTsubordinate devices and interfaces to external devices

Kinematic data of the robot systems

Signal information and SPS function blocks

colors, weight, surface area…

compared to the information sets given in Deliverable 4.2.

In general all these information are related to the manufacturing execution control (MES) layer of the manufacturing system. All other information of the plant componecovered by RobCAD as indicated in Figure 54. This figure depicts the focus of the capabilities

ENGINEERING ARTIFACTs with respect to its specific focus of use.

88

For simple executions it is also possible to use the default controller, it can control Hardenberg-Tranformation of

coordinate systems. The standard kinematics controller is not able to execute special tasks. For special purposes the control capabilities of RobCAD can be extended by adding

ped controllers. These controllers will implement the required

The representation of the complete data set relevant for the mechatronical concept as is restricted within RobCAD. This is based on the specialized focus

and information modeling range reflected within RobCAD. RobCAD enables the modeling of

the manufacturing system,

ENGINEERING ARTIFACT,

In general all these information are related to the manufacturing execution control (MES) plant component are not

. This figure depicts the focus of the capabilities s with respect to its specific focus of use.


Figure 54: engineering artifact

Nevertheless, RobCAD enables the application of mechatronic concepts within the engineering of manufacturing syste

RobCAD is focused on only two engineering activities within the engineering process of manufacturing systems, the simulation of robot structures and controls and the offline programming of existing robot cells. This is reflected by ththe plant component expressi

A basic mechatronic information object can be established in Rdifferent object component, robot and work cell. All of thekinematics information as well as control information. In addition they constitute a hierarchical structuring as depicted by the aggregation relation in the class diagram given in Figure 50.

3.11. TIA Portal


The Totally Integrated Automation Portal (TIA Portal) is an engineering software system intended to be used for the engineering of complete control system projecengineering of the hardware system, the control application implementation, the communication system configuration, the control device configuration, and the HMI system implementation. Thus, it covers all engineering disciplines necessary commission a complete control system for a production system.



controlled behavior




engineering artifact information representation in RobCAD

Nevertheless, RobCAD enables the application of mechatronic concepts within the engineering of manufacturing systems in a focused way.

RobCAD is focused on only two engineering activities within the engineering process of manufacturing systems, the simulation of robot structures and controls and the offline programming of existing robot cells. This is reflected by the portion of the information set of

ible within RobCAD.

A basic mechatronic information object can be established in Robdifferent object component, robot and work cell. All of the combine to geometry and kinematics information as well as control information. In addition they constitute a hierarchical structuring as depicted by the aggregation relation in the class diagram given in

Tool description

The Totally Integrated Automation Portal (TIA Portal) is an engineering software system intended to be used for the engineering of complete control system projecengineering of the hardware system, the control application implementation, the communication system configuration, the control device configuration, and the HMI system implementation. Thus, it covers all engineering disciplines necessary commission a complete control system for a production system.






• connections• wiring diagrams• pneumatic schemes• … • only electrical



descriptions• …




89

information representation in RobCAD

Nevertheless, RobCAD enables the application of mechatronic concepts within the

RobCAD is focused on only two engineering activities within the engineering process of manufacturing systems, the simulation of robot structures and controls and the offline

e portion of the information set of

obCAD by the three combine to geometry and

kinematics information as well as control information. In addition they constitute a hierarchical structuring as depicted by the aggregation relation in the class diagram given in

The Totally Integrated Automation Portal (TIA Portal) is an engineering software system intended to be used for the engineering of complete control system projects including the engineering of the hardware system, the control application implementation, the communication system configuration, the control device configuration, and the HMI system implementation. Thus, it covers all engineering disciplines necessary to engineer and



functional models



The first release of TIA Portal brings together STEP 7 tools for programming and configuring SIMATIC controllers. Integrated into this environment is WinCC, the configuration tool for setting up Siemens’ extensive family of operator panels. Finally, drives can set-up and parameterized in the same framework with StartDrive, a configuration tool for SINAMIC AC drives.

The main aim of the TIA Portal is the concentration on a set of workflows enabling the user to engineering control systems step by step. Therefore, the TIA Portal provides different views and work flows.

Basic background of the TIA Portal is a common data base for all project related information of all engineering disciplines. This data base will be incrementally completed starting with the hardware configuration followed by control programming and HMI programming (see Figure 55).

Figure

In addition the TIA portal will provide a common look and feel over the different engineering disciplines and enable the free of breakage transfer of disciplines exploiting the common data base.

The common data base will enable the use of common data tags over the different engineering disciplines. Thus, for example, creating a new variable in the control application and attaching it to a PLC input will enable to use this data tag within HMIs and within communication structures.


The first release of TIA Portal brings together STEP 7 tools for programming and configuring SIMATIC controllers. Integrated into this environment is WinCC, the

ol for setting up Siemens’ extensive family of operator panels. Finally, drives up and parameterized in the same framework with StartDrive, a configuration tool

The main aim of the TIA Portal is the concentration on a set of possible engineering workflows enabling the user to engineering control systems step by step. Therefore, the TIA Portal provides different views and work flows.

Basic background of the TIA Portal is a common data base for all project related all engineering disciplines. This data base will be incrementally completed

starting with the hardware configuration followed by control programming and HMI

Figure 55: Start window of TIA Portal

In addition the TIA portal will provide a common look and feel over the different engineering disciplines and enable the free of breakage transfer of information between the disciplines exploiting the common data base.

The common data base will enable the use of common data tags over the different engineering disciplines. Thus, for example, creating a new variable in the control application

g it to a PLC input will enable to use this data tag within HMIs and within

90

The first release of TIA Portal brings together STEP 7 tools for programming and configuring SIMATIC controllers. Integrated into this environment is WinCC, the

ol for setting up Siemens’ extensive family of operator panels. Finally, drives up and parameterized in the same framework with StartDrive, a configuration tool

possible engineering workflows enabling the user to engineering control systems step by step. Therefore, the TIA

Basic background of the TIA Portal is a common data base for all project related all engineering disciplines. This data base will be incrementally completed

starting with the hardware configuration followed by control programming and HMI

In addition the TIA portal will provide a common look and feel over the different information between the

The common data base will enable the use of common data tags over the different engineering disciplines. Thus, for example, creating a new variable in the control application

g it to a PLC input will enable to use this data tag within HMIs and within


In addition TIA portal will support the development of distributed control applications by integrating different control hardware entities within one projapplications to them.


The TIA Portal is intended for control system engineering. Thus it covers all information which are relevant for control system. This will include

· Control related data like control applvariables, device configurations, etc.

· Electrical data like wiring lists, communication device configurations, and energy supply,

· Function describing data for controlled

· Topological data related to the device

· Generic data like order numbers, interface descriptions, etc.

The portion of the overall information set of mechatronical units/systems covered by TIA Portal is depicted in Figure 56

Figure 56

The named information sets are integrated in device objects of a device and group of devices hierarchy which is used for project navigation. Hence, the device object and the group of devices object have been chosen as



controlled behavior




In addition TIA portal will support the development of distributed control applications by integrating different control hardware entities within one project an attaching control


The TIA Portal is intended for control system engineering. Thus it covers all information which are relevant for control system. This will include

Control related data like control applications, program organizationvariables, device configurations, etc.

Electrical data like wiring lists, communication device configurations, and energy

Function describing data for controlled behavior,

Topological data related to the device hierarchy of the control system, and

Generic data like order numbers, interface descriptions, etc.

The portion of the overall information set of mechatronical units/systems covered by TIA 56.

56: Information sets covered by TIA Portal

The named information sets are integrated in device objects of a device and group of h is used for project navigation. Hence, the device object and the

group of devices object have been chosen as engineering artifact representation.









descriptions• …




91

In addition TIA portal will support the development of distributed control applications by ect an attaching control

The TIA Portal is intended for control system engineering. Thus it covers all information

organization units,

Electrical data like wiring lists, communication device configurations, and energy

hierarchy of the control system, and

The portion of the overall information set of mechatronical units/systems covered by TIA

The named information sets are integrated in device objects of a device and group of h is used for project navigation. Hence, the device object and the

representation.



functional models



Within each device information and object sets are integrated as named in

Figure 57:

Device

Group

1

1..*

Device configurationinformation set

1

PLC data type

PLC data type

1

1..*


Within each device information and object sets are integrated as named in

: engineering artifact structure in TIA Portal

1..*

1

1..*

Online and diagnosisinformation set

Technology objectset PLC variable set

Technology object

1

1..*

PLC variable

1

1..*

type set

type

1..*

Observartion table Local component set

Local component

1

1..*

Remote

Remote

92

Within each device information and object sets are integrated as named in Figure 57.

set

PLC variable

1..*

Remote componentset

Remote component

1

1..*


4. Engineering Tool chain based on general engineering workflowWithin this chapter the

workflow presented in Deliverable 4.2 will be shown. This tool chain will contain the tools presented within this deliverable. For sure this is only one exemplary tool chain, as in real application cases a multitude of tools is used within the engineering. Never the less it will be possible to show the basic context.

Figure 58 depicts the tool chain derived from tActivity layer shows the engineering activities proceeded within the general engineering workflow. The middle part shows the artifacts created within these activities. From left to right a qualitative time axis is gitranslatable into a "consumed time". It is only a hint that the activities or artifacts are carried out / used during longer time periods.

The lower part of the figure shows the tools used to create the bars is an indication for the impact a tool has on the engineering results. E.g. the impact of AutomationML as a data formatwithin. Never the less there is a certain exchange.

Comparing the different tools to the tool scenarios given in chapter can be categorized as best of bread tools. Only Comos / SIMATIC Automation Designer and AutomationML are different. Comos is a typical all in one tool which can be easily sis used without restrictions throughout the engineering process. AutomationML is also used in parallel, but as it is an data exchange format, it is not an all in one tool, but the basis for an integrated tool chain. Thus, assuming that all tools (which most of them don't do in reality up to now) the beast of bread tools may be used within an integrated tool chain scenario.

Looking at the best of bread tools some of them are dashed in the early or later phases. This means that these tools may be used for creating these artifacts but it may not be their focus of work. Additionally it becomes obvious that the tools are kind of accumulating in the instantiation, implementation and first testing activities. This is these activities the whole bandwidth of engineering disciplines is used (mechanics, electrics, pneumatics, hydraulics, control, automation, ...). Thus different specialized tools may be used for different disciplines. Due to thDesigner is only highlighted with medium importance during the whole engineering process. Although it is used for different disciplines there are always specialized disciplines not embedded into the tool. Thus,will thus cover 90% of the engineering. But a 100% coverage will never be possible due to the high diversity within engineering business. Other tools like the TIA portal are again focused on one discipline (e.g. automation engineering) and provide all necessary subwithin this discipline. Thus, they have a big importance for these engineering artifacts.


Engineering Tool chain based on general engineering workflowWithin this chapter the engineering tool chain based on the general engineering

workflow presented in Deliverable 4.2 will be shown. This tool chain will contain the tools presented within this deliverable. For sure this is only one exemplary tool chain, as in real

ses a multitude of tools is used within the engineering. Never the less it will be possible to show the basic context.

depicts the tool chain derived from the tool analysis. In the upper part the Activity layer shows the engineering activities proceeded within the general engineering workflow. The middle part shows the artifacts created within these activities. From left to right a qualitative time axis is given. Note that the length of each bar is not one to one translatable into a "consumed time". It is only a hint that the activities or artifacts are carried out / used during longer time periods.

The lower part of the figure shows the tools used to create artifacts. the bars is an indication for the impact a tool has on the engineering results. E.g. the impact

data format is quite low as data is only stored, but not generated within. Never the less there is a certain importance regarding the seamless information

Comparing the different tools to the tool scenarios given in chapter 2.4can be categorized as best of bread tools. Only Comos / SIMATIC Automation Designer and AutomationML are different. Comos is a typical all in one tool which can be easily sis used without restrictions throughout the engineering process. AutomationML is also used in parallel, but as it is an data exchange format, it is not an all in one tool, but the basis for an integrated tool chain. Thus, assuming that all tools provide an interface to AutomationML (which most of them don't do in reality up to now) the beast of bread tools may be used within an integrated tool chain scenario.

Looking at the best of bread tools some of them are dashed in the early or later phases. This means that these tools may be used for creating these artifacts but it may not be their

Additionally it becomes obvious that the tools are kind of accumulating in the instantiation, implementation and first testing activities. This is owed to the fact that within these activities the whole bandwidth of engineering disciplines is used (mechanics, electrics, pneumatics, hydraulics, control, automation, ...). Thus different specialized tools may be used for different disciplines. Due to this reason also the Comos / SIMATIC Automation Designer is only highlighted with medium importance during the whole engineering process. Although it is used for different disciplines there are always specialized disciplines not embedded into the tool. Thus, it can be used for the "standard engineering activities" and will thus cover 90% of the engineering. But a 100% coverage will never be possible due to the high diversity within engineering business. Other tools like the TIA portal are again

discipline (e.g. automation engineering) and provide all necessary subwithin this discipline. Thus, they have a big importance for these engineering artifacts.

93

Engineering Tool chain based on general engineering workflow engineering tool chain based on the general engineering

workflow presented in Deliverable 4.2 will be shown. This tool chain will contain the tools presented within this deliverable. For sure this is only one exemplary tool chain, as in real

ses a multitude of tools is used within the engineering. Never the less it will be

he tool analysis. In the upper part the Activity layer shows the engineering activities proceeded within the general engineering workflow. The middle part shows the artifacts created within these activities. From left to

ven. Note that the length of each bar is not one to one translatable into a "consumed time". It is only a hint that the activities or artifacts are carried

artifacts. Here the height of the bars is an indication for the impact a tool has on the engineering results. E.g. the impact

is quite low as data is only stored, but not generated importance regarding the seamless information

2.4, most of the tools can be categorized as best of bread tools. Only Comos / SIMATIC Automation Designer and AutomationML are different. Comos is a typical all in one tool which can be easily seen as it is used without restrictions throughout the engineering process. AutomationML is also used in parallel, but as it is an data exchange format, it is not an all in one tool, but the basis for an

provide an interface to AutomationML (which most of them don't do in reality up to now) the beast of bread tools may be used

Looking at the best of bread tools some of them are dashed in the early or later phases. This means that these tools may be used for creating these artifacts but it may not be their

Additionally it becomes obvious that the tools are kind of accumulating in the owed to the fact that within

these activities the whole bandwidth of engineering disciplines is used (mechanics, electrics, pneumatics, hydraulics, control, automation, ...). Thus different specialized tools may be

is reason also the Comos / SIMATIC Automation Designer is only highlighted with medium importance during the whole engineering process. Although it is used for different disciplines there are always specialized disciplines not

it can be used for the "standard engineering activities" and will thus cover 90% of the engineering. But a 100% coverage will never be possible due to the high diversity within engineering business. Other tools like the TIA portal are again

discipline (e.g. automation engineering) and provide all necessary sub-tools within this discipline. Thus, they have a big importance for these engineering artifacts.


One thing that has to be mentioned is, that none of the industrial CAE tools provide capabilities for MAS engineering. Thus, tools liused here.

Figure 58: Engineering tool chain based on general engineering workflow

Note: Due to the size of the picture, attached to this file.


One thing that has to be mentioned is, that none of the industrial CAE tools provide abilities for MAS engineering. Thus, tools like JADE, NetBeans IDE and Protégé have to be

: Engineering tool chain based on general engineering workflow

Note: Due to the size of the picture, Figure 58 will be available as separate .png file

94

One thing that has to be mentioned is, that none of the industrial CAE tools provide e JADE, NetBeans IDE and Protégé have to be

: Engineering tool chain based on general engineering workflow

will be available as separate .png file


5. Additional tool requirements for industrial engineering tools supporting GRACE MASFor the evaluation of additional tool requirements for industrial CAE tools supporting a

modular Grace based MAS-architecture, analysis were made for different industrial CAE tools. Additionally some Case studies were carried out. A short wrapbe done within section 5.1. Additional information is given in (AMENIA 2012).

Within the second section of this chapter the results of the case evaluations will be used to identify further tool requirements.

5.1. Case studies Within four case studies from different industries the usability and benefits of

thinking have been investigated exploiting the

The first case was related to a Natural Hydraulic Lime (NHL) production system EP executed by Fels-Werke GmbH Germany. Within the considered how the use of newly available TIA portal of Siemens and influence the engineering processrelated to mechatronic components have a high potentials mechatronic structure will improve information exchange by providing a common semantics of information, and that a component library can improve reuse of engineering within control and HMI programming within TIA butin the early stages of the engineering process

The second case study was related to the engineering of railway control systems. The main question of the investigation was which impact mechatronic thinking and a mechatronic component library in a discipline spanning tool like the SIMATIC Automation Designer based on COMOS will have on the common engineering tool for all disciplines with a mechatronic engineering data modelensure a lossless information exchange along the engineering disciplines. It will ensure engineering discipline integration based on component information semantics and makes reuse of engineering Additionally, it will reduce engineering processmanagement of the project states.

The third case study was related to the engineering of a robot cell with a focus on virtual commissioning based on RobCAD. robot cell it could be shown that the main risk for information loss will be between special engineering activities were both tools and will be the cell planner. Thus this role has to have extensive skills covering all involved engineering disciplines. In addition it gets visible, that the considered tool will cover most of the engineering activities except electrical engineering and early phases. Thus automatically ensure a wide range of the process data consistency, lossless information exchange and the integration of engineering disciplines.


Additional tool requirements for industrial engineering tools supporting GRACE MAS-architecture For the evaluation of additional tool requirements for industrial CAE tools supporting a

architecture, analysis were made for different industrial CAE tools. Additionally some Case studies were carried out. A short wrap-up of thes

. Additional information is given in (AMENIA 2012).

Within the second section of this chapter the results of the case evaluations will be used to identify further tool requirements.

Within four case studies from different industries the usability and benefits of

been investigated exploiting the analysis concept given in chapter

The first case was related to a Natural Hydraulic Lime (NHL) production system EP Werke GmbH Germany. Within the engineering organizat

considered how the use of newly available TIA portal of Siemens and modular engineering process. It could be shown that a set of engineering

related to mechatronic components have a high potentials for reuse, the use of a common mechatronic structure will improve information exchange by providing a common semantics of information, and that a component library can improve reuse of engineering within control and HMI programming within TIA but also supports the component selection

engineering process.

The second case study was related to the engineering of railway control systems. The main question of the investigation was which impact mechatronic thinking and a

atronic component library in a discipline spanning tool like the SIMATIC Automation Designer based on COMOS will have on the engineering process. It could be shown that a common engineering tool for all disciplines with a mechatronic engineering data modelensure a lossless information exchange along the engineering processengineering disciplines. It will ensure engineering discipline integration based on component information semantics and makes reuse of engineering artifact

engineering process risks by ensuring a much better version management of the project states.

The third case study was related to the engineering of a robot cell with a focus on virtual commissioning based on RobCAD. Within the procedure model for the engineering of a

that the main risk for information loss will be between special engineering activities were both tools and artifacts will change. The only glue at this position

ll planner. Thus this role has to have extensive skills covering all involved engineering disciplines. In addition it gets visible, that the considered tool will cover most of the engineering activities except electrical engineering and early phases. Thus automatically ensure a wide range of the process data consistency, lossless information exchange and the integration of engineering disciplines.

95

Additional tool requirements for industrial engineering tools

For the evaluation of additional tool requirements for industrial CAE tools supporting a architecture, analysis were made for different industrial CAE

up of these studies will . Additional information is given in (AMENIA 2012).

Within the second section of this chapter the results of the case studies and tool

Within four case studies from different industries the usability and benefits of modular chapter 2.

The first case was related to a Natural Hydraulic Lime (NHL) production system EP engineering organization analysis it was

modular thinking will . It could be shown that a set of engineering artifacts

for reuse, the use of a common mechatronic structure will improve information exchange by providing a common semantics of information, and that a component library can improve reuse of engineering artifacts

also supports the component selection

The second case study was related to the engineering of railway control systems. The main question of the investigation was which impact mechatronic thinking and a

atronic component library in a discipline spanning tool like the SIMATIC Automation . It could be shown that a

common engineering tool for all disciplines with a mechatronic engineering data model will engineering process crossing the

engineering disciplines. It will ensure engineering discipline integration based on common artifacts much easier:

risks by ensuring a much better version

The third case study was related to the engineering of a robot cell with a focus on virtual Within the procedure model for the engineering of a

that the main risk for information loss will be between special s will change. The only glue at this position

ll planner. Thus this role has to have extensive skills covering all involved engineering disciplines. In addition it gets visible, that the considered tool will cover most of the engineering activities except electrical engineering and early phases. Thus it will automatically ensure a wide range of the process data consistency, lossless information


The last case study was related to the process engineering within machine tool industry. The process engineering in this case follows a strict sequence which mechatronic thinking. But there are major improvement capabilities by of engineering artifacts for material and immaterial ones. To ensure a proper reuse of artifacts it is necessary to know which activity. The procedure model is used to identify potentially reused programs, fixture CAD, and physical fixtures, as well as CAD of products. Thesinterrelated. Exploiting the Productand mechatronic concept the lossless information exchange can be ensured between difengineering processes related to them.

5.2. Additional tool requirementsBased on the different tool scenarios, case studies and tool evaluations, several

requirements to industrial CAE tools have been identified in order to be engineering challenges involved in the engineering of modular production systems and especially for GRACE MAS based systems. These requirements should be regarded as a set of additional requirements which have not yet been fully implementtools. Never the less, tools are very different at their maturity level regarding modular design paradigms. This does not automatically mean that these tools are "bad" tools, as this is highly depending on the focus and application

Generally the integration and handling of data has to be improved. This is mainly focusing on data exchange aspects within an engineering process. As show in the three tool chain scenarios, tool landscapes might be characterized by scabread). These islands nowadays are mostly independent or only loosely connected to each other. But following a modular design approach like MAS, engineering artifacts cannot be regarded independently. In fact several artifacton the same engineering object. Thus changes in one perspective have to be shared with the others. This assurance of data actuality and consistency can only be obtained by enforcing the data integration. On step in a direction of an integrated tool chain. This can be achieved by providing a common data backbone like AutomationML. Another way might be the development and/or improvement of new/existing all-in-one tools.

As information about objects and data correlation between different perspectives might get very complex a clear data structuring is needed. This will also help avoiding information redundancies, thus improving engineering efficiency in pa

Another point regarding data integration becomes obvious looking at the field of collaborative engineering and supplier collaborationholders of later life-cycle phases (e.g. plant operator, maintenance, …)integration itself is important but also the possibility to have consistent simultaneous data access including multi-site engineering and handling and change management are typical requirements be better realized and integrated into manufacturing CAE systems.


The last case study was related to the process engineering within machine tool industry. ngineering in this case follows a strict sequence which cannot

mechatronic thinking. But there are major improvement capabilities by organizings for material and immaterial ones. To ensure a proper reuse of

s it is necessary to know which artifact is used and created in which engineering activity. The procedure model is used to identify potentially reused programs, fixture CAD, and physical fixtures, as well as CAD of products. Thesinterrelated. Exploiting the Product-Process-Resource concept (Cutting-Decelleand mechatronic concept the artifacts can be organized in an artifact lossless information exchange can be ensured between different production orders and the

related to them.

Additional tool requirements Based on the different tool scenarios, case studies and tool evaluations, several

requirements to industrial CAE tools have been identified in order to be engineering challenges involved in the engineering of modular production systems and especially for GRACE MAS based systems. These requirements should be regarded as a set of additional requirements which have not yet been fully implemented within industrial CAE tools. Never the less, tools are very different at their maturity level regarding modular design paradigms. This does not automatically mean that these tools are "bad" tools, as this is highly depending on the focus and application case of such tools.

Generally the integration and handling of data has to be improved. This is mainly focusing on data exchange aspects within an engineering process. As show in the three tool chain scenarios, tool landscapes might be characterized by scattered "tool islands" (best of bread). These islands nowadays are mostly independent or only loosely connected to each other. But following a modular design approach like MAS, engineering artifacts cannot be regarded independently. In fact several artifacts constitute different views or perspectives on the same engineering object. Thus changes in one perspective have to be shared with the others. This assurance of data actuality and consistency can only be obtained by enforcing

might be to drive development of different best of bread tools in a direction of an integrated tool chain. This can be achieved by providing a common data backbone like AutomationML. Another way might be the development and/or improvement

one tools.

As information about objects and data correlation between different perspectives might get very complex a clear data structuring is needed. This will also help avoiding information redundancies, thus improving engineering efficiency in parallel.

Another point regarding data integration becomes obvious looking at the field of collaborative engineering and supplier collaboration but also collaboration with stake

cycle phases (e.g. plant operator, maintenance, …). Here integration itself is important but also the possibility to have consistent simultaneous data

site engineering and specified user rights. Also versioning, variants handling and change management are typical requirements which are not new, but have to be better realized and integrated into manufacturing CAE systems.

96

The last case study was related to the process engineering within machine tool industry. cannot be improved by

organizing the reuse s for material and immaterial ones. To ensure a proper reuse of

is used and created in which engineering activity. The procedure model is used to identify potentially reused artifacts like CNC programs, fixture CAD, and physical fixtures, as well as CAD of products. These artifacts are

Decelle et al., 2007) library. In addition

ferent production orders and the

Based on the different tool scenarios, case studies and tool evaluations, several requirements to industrial CAE tools have been identified in order to be able to cope with engineering challenges involved in the engineering of modular production systems and especially for GRACE MAS based systems. These requirements should be regarded as a set of

ed within industrial CAE tools. Never the less, tools are very different at their maturity level regarding modular design paradigms. This does not automatically mean that these tools are "bad" tools, as this is

Generally the integration and handling of data has to be improved. This is mainly focusing on data exchange aspects within an engineering process. As show in the three tool

ttered "tool islands" (best of bread). These islands nowadays are mostly independent or only loosely connected to each other. But following a modular design approach like MAS, engineering artifacts cannot be

constitute different views or perspectives on the same engineering object. Thus changes in one perspective have to be shared with the others. This assurance of data actuality and consistency can only be obtained by enforcing

might be to drive development of different best of bread tools in a direction of an integrated tool chain. This can be achieved by providing a common data backbone like AutomationML. Another way might be the development and/or improvement

As information about objects and data correlation between different perspectives might get very complex a clear data structuring is needed. This will also help avoiding information

Another point regarding data integration becomes obvious looking at the field of but also collaboration with stake-

. Here not only the integration itself is important but also the possibility to have consistent simultaneous data

specified user rights. Also versioning, variants which are not new, but have to


Besides integration of data perspectives it is also important to improve the integration of different disciplines and new models within engineering tools. Scouindustrial CAE tools, no tools for MAS engineering could be identified. This is also due to the fact that multi-agent systems are currently not typical industrial applied control paradigms. Thus, there is no real market need for egg-problems. As long as no industrial tools are available, industrial application is aggravated, as OEMs mostly rely on kind of industrial standard tools (as they also guarantee tool support for the next years). Thus they are not using MAS as free tools like JADE might be able to engineer those systems, but there is no guarantee that if the plant has to be changed in five years, this tool will be available, or even worse, compatibility with new controlis given. This way they are obstructing the development of a MAS tool market.

But also other disciplines have to be better integrated e.g. Quality management (definition and check of Quality gates, milestones, etc.), ERP systems, office applications and so far. In case of GRACE engineering methodology also tools improving the handliMPFQ architecture might be helpful. This requirement, which at the first view seems to be very specific can be abstracted to another level. Within each company different engineers develop tons of models and methods to cope with certain problems. be a way to bring these models, processes and methodologies into tools, thus not only enhancing problem solving based on this new model/process/method, but also connecting them to the "rest of the world". One example for this is the within GRACE to ensure interoperability of JADE, NetBeans IDE and Protégé (each tool solving different problem aspects).

Another requirement, which has already been touched, is the standardization and reuse of modules. A project spanning standardization of modules will help to project spanning reuse of artifacts. This can be done e.g. by standardizing tool interfaces. A first approach for this was given in Deliverable 4.2. Together with a library system support this will ensure consistency of standard modules and also improve quality of the whole engineering process as tested and proven modules can be used. This aspect was also shown in the workflow bisection of the general and OEM specific workflows given in Delivand D4.2 – Appendix A.

At the end there are also several other requirements which should be regarded. One problem, also addressed within GRACE, is the contextualization of information. Within GRACE this was done using ontologies for the MAS. Witmight also be used to contextualize information meaning. A second problem is the user guidance and user interface of engineering tools (e.g. automatic check of results, provision of guidelines / OEM specific workflows; integration of documentation handling, etc.).

Most of these requirements are somehow connected to each other, thus regarding them separately is not possible. This is also a big hurdle when it comes to their reengineering tools. Implementing one after another is not simple or even possible. Thus implementing them as a whole would mean high efforts for tool providers.


Besides integration of data perspectives it is also important to improve the integration of different disciplines and new models within engineering tools. Scouting the current available industrial CAE tools, no tools for MAS engineering could be identified. This is also due to the

agent systems are currently not typical industrial applied control paradigms. Thus, there is no real market need for this tool support. But this also leads to some chicken

problems. As long as no industrial tools are available, industrial application is aggravated, as OEMs mostly rely on kind of industrial standard tools (as they also guarantee tool support

ext years). Thus they are not using MAS as free tools like JADE might be able to engineer those systems, but there is no guarantee that if the plant has to be changed in five years, this tool will be available, or even worse, compatibility with new control

obstructing the development of a MAS tool market.

But also other disciplines have to be better integrated e.g. Quality management (definition and check of Quality gates, milestones, etc.), ERP systems, office applications and so far. In case of GRACE engineering methodology also tools improving the handliMPFQ architecture might be helpful. This requirement, which at the first view seems to be very specific can be abstracted to another level. Within each company different engineers develop tons of models and methods to cope with certain problems. Generally there should be a way to bring these models, processes and methodologies into tools, thus not only enhancing problem solving based on this new model/process/method, but also connecting them to the "rest of the world". One example for this is the Java platform which was used within GRACE to ensure interoperability of JADE, NetBeans IDE and Protégé (each tool

ving different problem aspects).

Another requirement, which has already been touched, is the standardization and reuse t spanning standardization of modules will help to

project spanning reuse of artifacts. This can be done e.g. by standardizing tool interfaces. A first approach for this was given in Deliverable 4.2. Together with a library system support

is will ensure consistency of standard modules and also improve quality of the whole engineering process as tested and proven modules can be used. This aspect was also shown in the workflow bisection of the general and OEM specific workflows given in Deliv

At the end there are also several other requirements which should be regarded. One problem, also addressed within GRACE, is the contextualization of information. Within GRACE this was done using ontologies for the MAS. Within the engineering these ontologies might also be used to contextualize information meaning. A second problem is the user guidance and user interface of engineering tools (e.g. automatic check of results, provision of guidelines / OEM specific workflows; localization, use of different scaleintegration of documentation handling, etc.).

Most of these requirements are somehow connected to each other, thus regarding them separately is not possible. This is also a big hurdle when it comes to their reengineering tools. Implementing one after another is not simple or even possible. Thus implementing them as a whole would mean high efforts for tool providers.

97

Besides integration of data perspectives it is also important to improve the integration of ting the current available

industrial CAE tools, no tools for MAS engineering could be identified. This is also due to the agent systems are currently not typical industrial applied control paradigms.

this tool support. But this also leads to some chicken-problems. As long as no industrial tools are available, industrial application is aggravated,

as OEMs mostly rely on kind of industrial standard tools (as they also guarantee tool support ext years). Thus they are not using MAS as free tools like JADE might be able to

engineer those systems, but there is no guarantee that if the plant has to be changed in five years, this tool will be available, or even worse, compatibility with new control hardware etc.

obstructing the development of a MAS tool market.

But also other disciplines have to be better integrated e.g. Quality management (definition and check of Quality gates, milestones, etc.), ERP systems, office applications and so far. In case of GRACE engineering methodology also tools improving the handling of the MPFQ architecture might be helpful. This requirement, which at the first view seems to be very specific can be abstracted to another level. Within each company different engineers

Generally there should be a way to bring these models, processes and methodologies into tools, thus not only enhancing problem solving based on this new model/process/method, but also connecting

Java platform which was used within GRACE to ensure interoperability of JADE, NetBeans IDE and Protégé (each tool

Another requirement, which has already been touched, is the standardization and reuse t spanning standardization of modules will help to enable an also

project spanning reuse of artifacts. This can be done e.g. by standardizing tool interfaces. A first approach for this was given in Deliverable 4.2. Together with a library system support

is will ensure consistency of standard modules and also improve quality of the whole engineering process as tested and proven modules can be used. This aspect was also shown in the workflow bisection of the general and OEM specific workflows given in Deliverable 4.2

At the end there are also several other requirements which should be regarded. One problem, also addressed within GRACE, is the contextualization of information. Within

hin the engineering these ontologies might also be used to contextualize information meaning. A second problem is the user guidance and user interface of engineering tools (e.g. automatic check of results, provision

localization, use of different scale-systems,

Most of these requirements are somehow connected to each other, thus regarding them separately is not possible. This is also a big hurdle when it comes to their realization within engineering tools. Implementing one after another is not simple or even possible. Thus implementing them as a whole would mean high efforts for tool providers.


References

AMENIA Project Team (2012): Analysis and Evaluation in Fields of Engineering for Industrial Plants AMENIA III

Arnaud, Remi; Barnes, Mark C. (2006): Collada: Sailing the Gulf of 3D Digital Content Creation: Taylor & Francis Inc. bin/work/suche2?titnr=242863269&flag=citavi.

AutomationML e.V. (2007): Vision Document. www.automationml.org.

Barth, Hannes (2009): Anforderung an Engineeringwerkzeugen für das „Mechatronica Engineering“ dezentral automatisierter FGuericke Universität Magdeburg, Magdeburg.

Bellifemine, Fabio; Poggi, Agostino; Rimassa, Giovanni (1999): JADE agent framework. In: Proceedings of the Practical Applications of Intelligent Agentverfügbar unter http://jmvidal.cse.sc.edu/library/jade.pdf.

COMOS Industry Solutions (2008): ET Plus Projektdokumentation. www.comos.com.

Cutting-Decelle, A.F; Young, R.I.M; Michel, J.J; G(2007): ISO 15531 MANDATE: A ProductModularity in Production Management.

Diedrich, Christian; Lüder, Arndt; Hundt, Lorenz bei Entwurf und Nutzung von automatisierten Produktionssystemen. In: Automatisierungstechnik, S. 426

Drath, Rainer (Hg.) (2010): Datenaustausch in der Anlagenplanung mit AutomationML. Integration von CAEX, PLCopen XML und COLLADA. Berlin: Springer (VDI

Drath, Rainer; Fay, Alexander; Barth, Mike (2011): Interoperabilität von EngineeringWerkzeugen. In: at - Automatisierungstechnik 59 (7), S. 451

Encyclopedia Britannica (2011): Engineering. Online verfühttp://www.britannica.com/EBchecked/topic/187549/engineering, zuletzt geprüft am 21.03.2011.

Foehr, Matthias (2010): Mechatronisches Engineering in der Fabrikautomation. Siemens internal Document. Siemens AG CT T DE TC4.


AMENIA Project Team (2012): Analysis and Evaluation in Fields of Applied Mechatronical Engineering for Industrial Plants AMENIA III – Siemens internal document

Arnaud, Remi; Barnes, Mark C. (2006): Collada: Sailing the Gulf of 3D Digital Content Creation: Taylor & Francis Inc. Online verfügbar unter http://www.lob.de/cgbin/work/suche2?titnr=242863269&flag=citavi.

AutomationML e.V. (2007): Vision Document. Online verfügbar unter

Barth, Hannes (2009): Anforderung an Engineeringwerkzeugen für das „Mechatronica Engineering“ dezentral automatisierter Fertigungsanlagen. Diploma Thesis. OttoGuericke Universität Magdeburg, Magdeburg.

Bellifemine, Fabio; Poggi, Agostino; Rimassa, Giovanni (1999): JADE In: Proceedings of the Practical Applications of Intelligent Agent

verfügbar unter http://jmvidal.cse.sc.edu/library/jade.pdf.

COMOS Industry Solutions (2008): ET Plus Projektdokumentation. Online verfügbar unter

Decelle, A.F; Young, R.I.M; Michel, J.J; Grangel, R.; Le Cardinal, J.; Bourey, J.P (2007): ISO 15531 MANDATE: A Product-process-resource based Approach for Managing Modularity in Production Management. In Concurrent Engineering 15 (2), pp. 217

Diedrich, Christian; Lüder, Arndt; Hundt, Lorenz (2011): Bedeutung der Interoperabilität bei Entwurf und Nutzung von automatisierten Produktionssystemen. In: Automatisierungstechnik, S. 426–439.

Drath, Rainer (Hg.) (2010): Datenaustausch in der Anlagenplanung mit AutomationML. en XML und COLLADA. Berlin: Springer (VDI-Buch).

Drath, Rainer; Fay, Alexander; Barth, Mike (2011): Interoperabilität von EngineeringAutomatisierungstechnik 59 (7), S. 451–460.

Encyclopedia Britannica (2011): Engineering. Online verfühttp://www.britannica.com/EBchecked/topic/187549/engineering, zuletzt geprüft am

Foehr, Matthias (2010): Mechatronisches Engineering in der Fabrikautomation. Siemens internal Document. Siemens AG CT T DE TC4.

98

Applied Mechatronical

Arnaud, Remi; Barnes, Mark C. (2006): Collada: Sailing the Gulf of 3D Digital Content Online verfügbar unter http://www.lob.de/cgi-

Online verfügbar unter

Barth, Hannes (2009): Anforderung an Engineeringwerkzeugen für das „Mechatronica Diploma Thesis. Otto-von-

Bellifemine, Fabio; Poggi, Agostino; Rimassa, Giovanni (1999): JADE - A FIPA-compliant In: Proceedings of the Practical Applications of Intelligent Agents. Online

Online verfügbar unter

rangel, R.; Le Cardinal, J.; Bourey, J.P resource based Approach for Managing

In Concurrent Engineering 15 (2), pp. 217–235.

(2011): Bedeutung der Interoperabilität bei Entwurf und Nutzung von automatisierten Produktionssystemen. In:

Drath, Rainer (Hg.) (2010): Datenaustausch in der Anlagenplanung mit AutomationML. Buch).

Drath, Rainer; Fay, Alexander; Barth, Mike (2011): Interoperabilität von Engineering-

Encyclopedia Britannica (2011): Engineering. Online verfügbar unter http://www.britannica.com/EBchecked/topic/187549/engineering, zuletzt geprüft am

Foehr, Matthias (2010): Mechatronisches Engineering in der Fabrikautomation. Siemens

http://www.comos.com/


Grundig, Claus-Gerold (2Anwendungen. 3. Aufl. München: Hanser.

Harashima, F.; Tomizuka, M.; Fukuda, T. (1996): MechatronicsHow?". An Editorial. In: IEEE/ASME Transactions on Mechatronics 1, Bd.

Helmus, Frank P. (2003): Anlagenplanung. Von der anfrage bis zur abnahme. Wiley-VCH.

IEC 62424: Specification for Representation of process control engineering requeats in P&I Diagrams and for data exchange between P&ID tools and PCE

Instituto Politécnico de Bragança (2011): GRACEmulti-agent architecture for lineOnline verfügbar unter http://graceD1-2-v7.pdf, zuletzt aktualisiert am 26.10.2011, zuletzt geprüft am 29.02.2012.

Kiefer, Jens (2007): Mechatronikorientierte Planung automatisierter Fertigungszellen im Bereich Karosserierohbau. Univ, Saarbrücken, Saarbrücken.

Lüder, Arndt; Hundt, Lorenz; Foehr, Matthias; Holm, Timo; Wagner, Thomas; Zaddach, Jorgos-Johannes (2010): Manufacturing system engineering with mechatronical units. 2010 IEEE Conference on Emerging Technologies &Spain, 13 - 16 September 2010. Piscataway, NJ: IEEE, S. 1

Moser, Thomas; Mordinyi, Richard; Winkler, Dietmar; MelikStefan (2011): Efficient automation systems engineering process suppointegration of engineering knowledge. In: ETFA2011: IEEE, S. 1

PLCopen Konsortium (2009): Technical Paper PLCopen Technical Committee 6 XML Formats for IEC 61131http://www.plcopen.org/pages/tc6_x

Schorn, W.; Große, N.: Hierarchien und Symbolik in der Produktionstechnik. Automatisierungstechnische Praxis 2008 (11), S. 66

Thramboulidis, Kleanthis (2008): Challenges in the Development of Mechatronic Systems: The Mechatronic Component. In: 2008 IEEE Conference on Emerging Technologies & Factory Automation. ETFA 2008 ; Hamburg, Germany, 15 S. 624–631.

VDI 2206, 06/2004: Design methodology for mechatronic systems.

VDI 3695: Engineering von Anla


Gerold (2009): Fabrikplanung. Planungssystematik Anwendungen. 3. Aufl. München: Hanser.

Harashima, F.; Tomizuka, M.; Fukuda, T. (1996): Mechatronics-"What Is It, Why, and How?". An Editorial. In: IEEE/ASME Transactions on Mechatronics 1, Bd. 1, S. 1

Helmus, Frank P. (2003): Anlagenplanung. Von der anfrage bis zur abnahme.

IEC 62424: Specification for Representation of process control engineering requeats in P&I Diagrams and for data exchange between P&ID tools and PCE-CAE.

uto Politécnico de Bragança (2011): GRACE Deliverable D1.2. Specification of the agent architecture for line-production system, integrating process and quality control.

http://grace-project.org/wp-content/uploads/2011/11/Deliverablev7.pdf, zuletzt aktualisiert am 26.10.2011, zuletzt geprüft am 29.02.2012.

Kiefer, Jens (2007): Mechatronikorientierte Planung automatisierter Fertigungszellen im . Univ, Saarbrücken, Saarbrücken.

Lüder, Arndt; Hundt, Lorenz; Foehr, Matthias; Holm, Timo; Wagner, Thomas; Zaddach, Johannes (2010): Manufacturing system engineering with mechatronical units.

2010 IEEE Conference on Emerging Technologies & Factory Automation. ETFA 2010 ; Bilbao, 16 September 2010. Piscataway, NJ: IEEE, S. 1–8.

Moser, Thomas; Mordinyi, Richard; Winkler, Dietmar; Melik-Merkumians, Martin; Biffl, Stefan (2011): Efficient automation systems engineering process support based on semantic integration of engineering knowledge. In: ETFA2011: IEEE, S. 1–8.

PLCopen Konsortium (2009): Technical Paper PLCopen Technical Committee 6 XML Formats for IEC 61131-3 Version 2. Online verfügbar unter http://www.plcopen.org/pages/tc6_xml/.

Schorn, W.; Große, N.: Hierarchien und Symbolik in der Produktionstechnik. Automatisierungstechnische Praxis 2008 (11), S. 66–74.

Thramboulidis, Kleanthis (2008): Challenges in the Development of Mechatronic Systems: t. In: 2008 IEEE Conference on Emerging Technologies & Factory

Automation. ETFA 2008 ; Hamburg, Germany, 15 - 18 September 2008. Piscataway, NJ: IEEE,

VDI 2206, 06/2004: Design methodology for mechatronic systems.

VDI 3695: Engineering von Anlagen - Evaluieren und optimieren des Engineerings.

99

009): Fabrikplanung. Planungssystematik - Methoden -

"What Is It, Why, and 1, S. 1–4.

Helmus, Frank P. (2003): Anlagenplanung. Von der anfrage bis zur abnahme. Weinheim:

IEC 62424: Specification for Representation of process control engineering requeats in

Specification of the production system, integrating process and quality control.

content/uploads/2011/11/Deliverable-v7.pdf, zuletzt aktualisiert am 26.10.2011, zuletzt geprüft am 29.02.2012.

Kiefer, Jens (2007): Mechatronikorientierte Planung automatisierter Fertigungszellen im

Lüder, Arndt; Hundt, Lorenz; Foehr, Matthias; Holm, Timo; Wagner, Thomas; Zaddach, Johannes (2010): Manufacturing system engineering with mechatronical units. In:

Factory Automation. ETFA 2010 ; Bilbao,

Merkumians, Martin; Biffl, rt based on semantic

PLCopen Konsortium (2009): Technical Paper PLCopen Technical Committee 6 XML Online verfügbar unter

Schorn, W.; Große, N.: Hierarchien und Symbolik in der Produktionstechnik. In: atp –

Thramboulidis, Kleanthis (2008): Challenges in the Development of Mechatronic Systems: t. In: 2008 IEEE Conference on Emerging Technologies & Factory

18 September 2008. Piscataway, NJ: IEEE,

Evaluieren und optimieren des Engineerings.


Wagner, Thomas; Hausner, Carolin; Elger, Jürgen; Löwen, Ulrich; Lüder, Arndt (2010): Engineering Processes for Decentralized Factory Automation Systems. In: Factory automation. INTECH, S. 1–28, zuletzt gepr


Wagner, Thomas; Hausner, Carolin; Elger, Jürgen; Löwen, Ulrich; Lüder, Arndt (2010): Engineering Processes for Decentralized Factory Automation Systems. In: Factory

28, zuletzt geprüft am 15.03.2011.

100

Wagner, Thomas; Hausner, Carolin; Elger, Jürgen; Löwen, Ulrich; Lüder, Arndt (2010): Engineering Processes for Decentralized Factory Automation Systems. In: Factory

inteGration of pRocess and quAlity Control using multi-agEnt technology

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

Contract n° NMP2-SL-2010-246203

Deliverable D4.2 Document defining the engineering methodology

Appendix A – Engineering tool evaluation

methodology

Engineering tool evaluation

102


Appendix B – Modeling examples for engineering tools

methodology

Modeling examples for engineering tools

103

Modeling examples for engineering tools


Appendix C – Engineering tool chain based on OEM specific engineering workflow

methodology

Engineering tool chain based on OEM specific engineering workflow

104

Engineering tool chain based on OEM specific


Appendix D – Bearing insertion station documentation

methodology

Bearing insertion station – Whirlpool

105


Appendix E – Bearing insertion station

methodology

Bearing insertion station – Comos documentation

106

Comos documentation

Integration of GRACE multi-agent systems with manufacturing

Documents

Transcript of Integration of GRACE multi-agent systems with manufacturing