engineering handbook - grace...

GRACE| June 2013| www.grace-project.org|

Contract n° NMP2-SL-2010-246203

Engineering Handbook


Content

1. Preface 3

2. GRACE Multi Agent System (MAS) for decentralized production systems 4 a. Multi-Agent Systems 5 b. GRACE MAS architecture 10

3. Fischertechnik® plant demonstrator 17

4. Engineering decentralized Production Systems using GRACE Engineering Methodology 26

a. Concept design phase 28 b. Basic design phase 45 c. Detailed design phase 57 d. Realization & Commissioning phase 71 e. Last tip… 94


Preface

This handbook will provide a guideline to engineering complex decentralized production systems based on the GRACE Multi-Agent System approach (MAS).

The engineering methodology this handbook is based on, is applicable for decentralized production systems in general. Thus, the steps presented within this handbook are likely to fit a broad range of application scenarios also behind the scope of GRACE MAS. Nevertheless, examples shown are based on GRACE specific implementations

The Handbook is comprised of three parts. The first part will introduce the GRACE Multi-Agent System (MAS) approach for process and quality control of decentralized production systems.

Afterwards, part 2 will briefly introduce the Fischertechnik® plant demonstrator used as an application example for the engineering methodology.

The third part will highlight how the engineering methodology can be used in order to engineer a decentralized production system. Examples from GRACE project will be shown.


Part 1 -

GRACE Multi-Agent System (MAS) for decentralized production

systems


Multi-Agent Systems


An Agent

• Possible definition of an agent:

• Characteristics of agents: • Autonomy/Cooperation • Reactivity/Proactivity • Intelligence/learning • Social skills

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 skills to reach alone its objectives.


A Multi-agent system

• Definition of a Multi-agent System:

• Need to have communication among agents: • Using a proper Agent Communication Language (ACL). • Ontologies that define the vocabulary used during the

conversation and the knowledge related to the terms used.

Society of agents capable to interact to achieve individual objectives, when they don’t have enough knowledge and/or skills to achieve them alone.


Benefits of MAS

• Distributed thinking: a complex problem can be divided into several small problems.

• Modularity: building the system by pieces like using LEGO. • Robustness: losing one decision node doesn’t implies the system

failure. • Reconfigurability: changes can be performed on the fly (without

the need to stop, re-program all control system and re-initialise the system).

• Reusability: old components can be re-used to develop new components or new systems.

• Smooth migration from old technologies to new ones.


GRACE MAS architecture


• Objective: − Manage the production of one type of appliance.

• Identification of functions − Historical monitoring of product execution. − Adaptation/optimization according to the feedback of previous

executions of product. − Interface to launch product batches. − Traceability.

• Attributes/knowledge: − type of product, name, process plan, …

Product Type Agent (PTA)


• Objective: − Manage the production of one appliance instance.

• Identification of functions − Resource allocation (including re-routing). − Product process management. − Data collection about the product execution. − Optimization/adaptation (selection of production and quality control

programs/components/parameters and on-board controller parameters)

• Attributes/knowledge: − name, type of product, mobyId, process plan, …

Product Agent (PA)


• Objective: − Manages the execution of production/transportation/assembly

operations in the production line.

• Identification of functions − Resource allocation (re-routing). − Dispatching and process control. − Monitoring (current status and historical data). − Optimization/adaptation (adjustment of the production

parameters).

• Attributes/knowledge: − name, type of resource, list of skills, status, list of programs, …

Machine Agent (MA)


• Objective: − Manages the execution of quality control operations in the

production line.

• Identification of functions − Measurement/testing. − Quality control. − Monitoring − Optimization/adaptation (adjustment of the quality control

algorithms and parameters).

• Attributes/knowledge: − name, type of quality control station, list of skills, status, list of

algorithms, …

Quality Control Agent (QCA)


• Objective: − Collects data for global monitoring and provides

optimized/adapted supervisory control.

• Identification of functions − Data collection. − Global monitoring. − Management/decision making. − Optimized supervisory control. − Adaptation advises.

• Attributes/knowledge: − name, list of agents, graph of dependencies, list of optimization /

adaptation algorithms, …

Independent Meta Agent (IMA)


GRACE – Multi-Agent System

GRACE ontology


Part 2 -

Fischertechnik® Plant Demonstrator


Fischertechnik® Demonstrator


Fischertechnik® Demonstrator – Overview

4 turn-tables (8 motors/ 24 signals)

2 gantry-cranes (6 motors / 38 signals)

5 conveyor (1,5 m / 5 motors/ 10 signals)

13 induction-sensors

8 light-sensors


The system can be divided in three logic units. The first unit user is responsible for operating and supervising the system via a PC. The user can take influence on the processes of the second unit control system (represented by PCS7) via a HMI (Human-Machine-Interface). The control system however controls with its basic automation the third unit production. The production can be once more divided

System interfaces

into cylinder head manufacturing plant, in/out transportation of workpieces, intermediate store and production planning system. The systems of the production communicate through MMIs (Machine-Machine-Interface). The following picture displays the described facts.

cylinder head manufacturing plant

in/out transport

PC

production control system user

MMI

intermediate store production planning system

HMI basic automatio

PCS 7


User characteristics

User: Operate and supervise the cylinder head manufacturing plant.

Maintenance and Service: Maintenance and Service of the plant.

General conditions

• The system has to be developed from the scratch – there is no legacy system.

• Dimensions (length 1-2.5m, width 0.5-2m, height 0.5-2m) and weight (70-150kg) of the to-be-produced workpieces (material Aluminium) must be considered in the process.

• The selected plant place in the production hall amounts to 40x25x10m.

• The plant will be constructed in a hall next to a residential area. Therefore authorized limits according to the pollution law must be respected.

• Avoidance of effective ignition sources in sense of explosion safety must be kept in mind for the development.

Plant functionality


Fischertechnik® Demonstrator – material flow

Motor

Motor

Motor

Motor

.

Motor

Motor

Motor

Motor Motor

Motor

„

Motor

Motor

Motor

B 7 _ 0 B 7 _ A 0 1

Motor Motor

A - Milling station B – Honing station C – Measuring station D – Assembly station

A

B

C

D


Fischertechnik® Demonstrator – Positioning and security switches 1

Security switches

X-Position switches

Y-Position switches

Z-Position switches

Other side of the crane

y

x

z


Fischertechnik® Demonstrator – Positioning and security switches 2

Security switches

X-Position switches

Y-Position switches

Z-Position switches


Fischertechnik® Demonstrator – positioning axis’

X1X2

X3X4

X5

X6X7

X8

X1X2

X3

X4X5

X6X7

X8

Y1Y2

Y1

Y2

Y3

Y3 y

x

z


Part 3 -

Engineering decentralized Production Systems using GRACE

Engineering Methodology


Engineering Process

The GRACE engineering process for decentralized manufacturing systems based on MAS architecture has been presented in “D4.2 - Definition of the engineering methodology”.

The following slides will show the specific activities of the engineering process and their outcomes. Additionally some hints will be given in order to overcome some general challenges.

The picture of the engineering workflow will be hardly readable within the document. It is only used to give the placement of the singular engineering activities within the overall engineering process. The complete picture of the engineering process can be found attached to this document.


Concept Design Phase


Definition of Requirements

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

plant components within mechatronic systems • Definition of requirements covers the specification of process, technical,

economical, employee knowledge or further conditions • Definition of requirements is the explicit integration of requirement information to

an plant component into the representing plant components by creating o Independent requirement facets or o Requirement information within facets

like o Integration of functional requirements like maximal speed of motions in the

behavior facets o Integration of non-functional CO2 pollution limitation requirements within an

additional requirement facet Application cases • Specification of manufacturing system capabilities

• Definition of necessary device of module characteristics within the order process


Decomposition of Requirements

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

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

linear acceleration curve • Decomposition of requirements is the process of requirement concretization by

adding more detailed requirements • Examples of requirement decompositions are:

o More detailed description of an intended manufacturing process by decomposition of manufacturing process steps like producing a toothbrush is decomposed in producing the toothbrush handle piece, producing the bristle clusters, gluing the bristle clusters in the toothbrush handle piece, finalization

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

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

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


Requirements specification – 1

Software requirements SWR1. The visualization must be applied through

WinCC of the Siemens AG. SWR2. The software implementation of the system

is supposed to be realized among other things through CFC (Continuous Function Charts) and SFC (Sequential Function Charts).

SWR3. The system must use SIMATIC PCS 7 of the Siemens AG.

Safety requirements SR1. User must be able to switch off the system and

to bring it into a defined safe state at every time point.

SR2. Access to automated areas shall be prevented. SR3. User must log in before working with the

system. SR4. The system must reach a safe state for human,

machine and production (in this sequence) if it is interrupted.

SR5. A distinction between access rights of the following roles must be obtainable: user (operator), maintenance and service, administrator, etc.

Quality/availability/throughput requirements QAT1. Producing 12 cylinder heads is set to a

maximum of one hour. QAT2. The workpieces should be free of machining

traces. QAT3. The availability of the system is set to a

maximum of 12 hours per diem.

Hardware requirements HWR1. The system must use the control system

SIMATIC S7-400 of the Siemens AG. HWR2. The system must include stand-alone

functionality.

Communication requirements CR1. The communication between PC and

automation shall take place through industrial Ethernet.

CR2. The field bus communication shall follow PROFIBUS.


Requirements specification – 2

Nonfunctional requirements NFR1. The system shall be stable:

1. The time to fix a problem/error shall be minimal. MTTR is less than 15 minutes. Three test users check the system for one week - three hours a day.

2. The maximum valid number of stoppages within an agreed period of time must be fixed. MTBF is greater than two months. The system is observed for a half year.

3. “Uncontrollable” situations of the system, caused by unusual events, shall be minimal. Not more than 3% of the unusual events cause system problems. The system behavior is checked by three test uses trying all thinkable errors.

4. “Uncontrollable” situations caused by invalid inputs shall be minimal. Not more than 0.5% of invalid user inputs lead to system errors. Observe system reactions on invalid inputs in all input-fields of the user interface done by three test users.

NFR2. The operability of the system shall be ensured at every time: 1. “Obtaining” the user reactions while operating with the system within a defined time. Complete

utilization of the system by users. Getting feedback via interviews of the users after a trail run,. 2. Checking the user interface concerning the adherence of software-ergonomic rules.

a. Grouping of controls following criteria like: balance, symmetry, regularity, predictability, closeness.

b. Requirements on utilized fonts: only one font type, no serif, not more than two font styles. Every page of the user interface must be free of shortcomings.


Decomposition of the plant / plant components

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

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

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

• Decomposition reflects the creation of substructures of the plant / plant components based on the decomposition guidelines

• Each plant component of the substructures contains external and internal interface definitions and connections and facets

Application cases • Manufacturing system structuring • Device structure definition


Composition of the plant / plant components

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

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

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

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

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

Application cases • Manufacturing system structuring • Device integration


Plant hierarchy


Identification of mechatronic units

Name Identification of mechatronic units Description • Gathering of domain information and identification of

mechatronic units as an aggregation of several requirements belonging to a defined set of system(sub)functionalities

• Structuring of the facility into different layers (e.g. cell, main groups, function groups, …)

• Function-oriented approach to develop a functional model of the production steps

• Differentiation between complex functions, basic functions, help functions

Application cases • Manufacturing system structuring

• Device structure definition

• Hierarchy definition

• Reuse of engineering results

• Specification of manufacturing system capabilities


Identification of integrated agents

Name Identification of integrated agents Description • each mechatronic unit might be controlled by an agent

• Agents can be identified using results of activity “Identification of mechatronic units”

• For each unit an appropriate agent can be identified

• For GRACE MAS these are typically all types of Resource agents (machine agent, quality control agent, transport agent and operator agent) see

o This may vary if other MAS-architectures are used

• The existence of a controlled behavior is a necessary but not sufficient condition for the identification of agents

o If there is a controlled behavior, then there might be an agent

o If the controlled behavior is simple, e.g. function block of a single motor, then no agent might be identified as it is just a “dumb” piece of control code

o Agents can be characterized by an adaptive, (self-) optimizing and/or (self-) organizing behavior

o This condition aims to keep complexity and amount of agents low, as agents are only identified for complex behavior. A mechatronic unit like a motor is one, can, in theory, also be controlled by an agent. That would lead to the fact, that for each actuator/sensor at least one agent is identified (thus leading to exponential growth of the MAS).






Identification of stand-alone agents

Name Identification of stand-alone agents Description • In addition to the integrated agents which are directly connected

to a mechatronic unit there might also be stand-alone agents

• Stand-alone agents are not directly connected to a physical device

• Stand-alone agents cooperate with other agents

• They can be identified using the MAS architecture:

o E.g within GRACE MAS PTAs, PAs and IMAs are not directly connected to physical devices

o No generic way to identify those agents

o Identification can be supported by analyzing MAS requirements






Plant hierarchy

For the following document a plant hierarchy considering five different functional levels is used.

The following slides will show how plant may be modularized using this plant hierarchy approach.

Further information about the different hierarchy levels and the modularization process can be found in Deliverable 4.2 – Appendix A of GRACE project.


Plant hierarchy levels

Fabrication due to execution of several basic functions

Fabrication of complex assemblies

Mechanics / Electrics / Automation for execution of one basic function

Execution of basic function by executing several even sub-functions

Plant

Cells

Sub-function groups

Functional groups

Main groups


Plant modularization approach

The step by step approach on the left hand side shows the basic principles applied in order to differentiate modules of the entire plant. They can be used to identify modules at each of the lower functional levels. The upper level is always the starting point and represents the plant level.

The complete modularization process is described in more detail within D4.2 – Appendix A of GRACE project.

The following slides will present the plant hierarchy and modularization of the Fischertechnik demonstrator plant

• Does the assembly consist ofcomplex individual parts?

• Can the process be disassembledinto non-trivial incremental Steps?

• Production cells for complexindividual parts

• Process cells for complex partialprocesses

Is he production/the process f low the result of the execution of a single basic function, or of multiple basic functions?

Main group for execution of multiple basic functions

Is the basic function executed through one single actuator/sensor, or a control signal, or through the performance of multiple identical sub-functions?

Which mechanical parts, actuators, sensors, control signals, function blocks, etc. participate in the execution of the basic function?

Which mechanical parts, actuators, sensors, control signals, function blocks, etc. participate in the implementation of the sub-function?

Starting from the entire installation

no

yes

View of the production of the individual parts, respectively, of the partial processes

single

multiple

View of the individual basic functions

Functiongroups

single

multiple Sub-functiongroups

Installation subdivided into modules

Main groups

Cells


Plant hierarchy & modularization – overview

The plant modularization is done integrating two approaches: the mechatronic thinking and the multi-agent approach. Both result in functional modularization of the plant.

Besides the modules depicted in the next slides it will also be shown if this module will be controlled by an agent. Therefore the icon of the corresponding agent will be shown next to the module:

Machine Agent Product Agent

Quality Control Agent Product Type Agent

Independent Meta-Agent


Plant hierarchy & modularization – crane system


Plant hierarchy & modularization – manufacturing and transportation system


Basic Design Phase


Selection of plant components based on requirements

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

the complete manufacturing system is designed as aggregation of plant component.

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

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

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


System concept

Check Engineering Database for reusable Modules already engineered.

Standard-Modules (e.g. Motors, Crane Systems) are most likely available

Special Modules (e.g. specific stations might not be existing and should be further analyzed and created if economical appropriate)


Development of reusable modules

The development process for reusable modules uses the same engineering activities as the sub-engineering process of the engineering project itself.

The development of reusable modules will be not especially detailed within this handbook, as all activities needed are described within the engineering project process. Further information on development of reusable modules can be found in GRACE deliverable 4.2 and deliverable 4.2 – Appendix A

The development of reusable modules might also include the development of new measurement techniques and process control and evaluations strategies.


Derivation of a System Architecture

Name Derivation of a System architecture Description • System architecture represents the basic solution for fulfillment of

requirements

• Multiple solutions might be discussed and decision (incl. reasons) why, which solution was chosen is documented

• Defines hierarchical structure of the system

• Modules (mechatronic units) are treated as black boxes and are detailed within following steps

• Defines interfaces between the mechatronic units

• Defines black-box behavior of the system and modules

• System architecture might also define general boundary conditions (e.g. safety levels etc.)

Application cases • Decomposition of manufacturing system

• Tracing of requirements


• Definition of necessary module characteristics

• Parallel and distributed engineering


System architecture

The System architecture can be derived after all modules to be used are identified. Most likely system architecture will use the same modules as have been identified during the plant hierarchization and modularization. Nevertheless in some cases different modules may be used as they are already stored as reusable artifacts in order to reduce engineering efforts.

System modularization, System architecture and instantiation activities may be usually performed in strong conjunction.


Instantiation

Name Instantiation Description • Instantiation is the process of applying templates to get real existing plant

components

• After the instantiation the templates have to be concretized with respect to:

o Setting up all parameters

o Choosing the right variant/version

o Adding additional information to fit the standard template to the current plant design

• The goal of instantiation is to reduce time and simultaneously improve the overall quality of the engineering by reusing tested structures

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

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


System architecture with general modules

Instantiate reusable modules from library

in order to create system architecture

within the engineering tool based on general

modules


Flexible view generation

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

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

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

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

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


P&ID Electrical

Circuit Diagram

Object „Drive“

Electrical Single Line Diagram

3D Model

Logical Diagram

Cabinet Layout

System views


Layer generation

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

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

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

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

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

Application cases • Parallel and distributed engineering


System Layer

Project Base

Layer 1 – Mechanical Design

Layer 2 – Electrical & Automation Design

Create working layers for specific disciplines, working groups and/or suppliers.

• assign users/rights to working layers • each user can only see what he is supposed to see

• suppliers might have only results but no access to the knowledge used to create them

• Engineers might only see „their domain“, thus system complexity can be reduced

P&IDElectrical

Circuit Diagram

Object„Drive“

Electrical SingleLine Diagram

3D Model

Logical Diagram

Cabinet Layout


Detailed Design Phase


Implementation

Name Implementation Description • previously instantiated templates are detailed

• instantiated templates (agents and mechatronic units) will most likely never fit project specific needs to 100 percent

• Adaption, organization and optimization of instantiated agents and mechatronic units are needed

• Interfaces have to be adjusted to ensure right communication among agents and mechatronic units

Application cases • Provision of specific information for engineering disciplines



Refinement of plant components

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

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

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

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

• Refinement ensures the generation of new versions of information Application cases • Hierarchy definition

• Facet definition / refinement • Interface definition • Behaviour generation • Code generation


Detailed module / component specification

P&IDElectrical

Circuit Diagram

Object„Drive“

Electrical SingleLine Diagram

3D Model

Logical Diagram

Cabinet Layout

Detailed design of every general module (customizing standard modules to specific project) and plant components (e.g. 3D designs, technical data, electrical designs, parameterization, etc.)


Module test (virtual)

Name Module tests (virtual) Description • Testing of single agents and mechatronic units if

they are fit for use

• Test is done as a white-box test, so that also the internal behavior could be verified

• Test cases have to be independent from each other

• Test is done by using the predefined interface of agents and mechatronic units to avoid module interaction failures

• Module test is done to improve integration of modules and integration tests

• Different standards for module testing can be used Application cases

• Acceptance tests based on paper/digital information

• Engineering project management and quality control

• Acceptance test preparation

• Behavior simulation

• Virtual commissioning


Simulation of behavior model

Name Simulation of behavior model Description • Simulation of behavior of manufacturing systems is

one key approach the reduce failure within the different phases of planning

• Behavior models of plant component (uncontrolled internal behavior of the plant component) as facet of the corresponding plant components can be used to create an overall behavior model of MSs

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

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

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

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

Application cases

• Virtual commissioning • Behavior simulation


Requirement driven test and validation

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

requirements are defined to be fulfilled by the plant components of the resulting mechatronic system

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

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

Application cases

• Engineering project management and quality control • Acceptance test preparation


Module acceptance (drawings)

Test and validate single modules based on virtual engineered data. • Check drawings for conformance to requirements • Check behavior by simulation of virtual

modules/behavior

3D module drawings

Automation drawings

Electrical drawings


Integration

Name Integration Description • Aggregating/linking all single modules into one system in

order to ensure the system functionalities

• Connecting module interfaces (information interface as well as material and energy interfaces)

• Using different integration methods, see

o Vertical integration

o Horizontal integration

o Star integration

o Common data format/semantics (e.g. ontologies) Application cases

• Composition of manufacturing system




Detailed system specifications (drawings)

3D module drawings

Automation drawings

Electrical drawings

Bill of Materials


Integration test (virtual)

Name Integration test Description • Combination of modules is tested

• Based on module tests

• Verifying requirements fulfillment (functional, quality, etc.)

• Is done by a black-box test only using interfaces of modules

• Prevents unexpected behavior especially when using intelligent, adaptive self-optimizing and/or self-organizing modules like agents and mechatronic units

• Different testing techniques like top-down, bottom-up or big-bang can be used e.g. [Bei90], [Bin00]

Application cases • Acceptance tests based on paper/digital information






Simulation of behavior model

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

approach the reduce failure within the different phases of planning






Application cases • Virtual commissioning • Behavior simulation



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

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



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


FAT (First Acceptance Test) of overall system

Test and validate overall system based on virtual engineered data. • Check drawings for conformance to requirements • Check behavior by simulation of virtual system/emerging system

behaviour


Realization & Commissioning phase


Module test (physical)

Name Module tests (physical) Description • Testing of single agents and mechatronic units if they are fit for

use

• Test is done as a white-box test, so that also the internal behavior could be verified

• Test cases have to be independent from each other

• Test is done by using the predefined interface of agents and mechatronic units to avoid module interaction failures

• Module test is done to improve integration of modules and integration tests

• Different standards for module testing can be used Application cases • Acceptance tests based on paper/digital information






Execution of behavior

Name Execution of behavior Description • Simulation of behavior of manufacturing systems is one key







Application cases








Application cases



Module acceptance (physical)

Test and validate single physical modules. • Check conformance of physical modules to drawings • Check functionality of physical modules • Check correctness of module installation (electrical

wiring, etc.) • Check behavior by execution of automation code of the

according modules • Check conformance of modules / behavior to

requirements


Integration (realization)

Name Integration (realization) Description • Aggregating/linking all single modules into one system in order to

ensure the system functionalities

• Connecting module interfaces (information interface as well as material and energy interfaces)

• Using different integration methods, see

o Vertical integration

o Horizontal integration

o Star integration

o Common data format/semantics (e.g. ontologies) Application cases

• Composition of manufacturing system




Detailed system specifications (drawings)

3D module drawings

Automation drawings

Electrical drawings

Bill of Materials


Real plant (as built) - mechanical

Mechanical construction of the plant based on drawings


Real plant (as built) - electrical

Electrical installation (wiring, pinning, power supply) of the plant


Real plant (as built) - automation

Implementation of plant automation (installation/setup of hardware; compiling and deployment of Software; teaching, etc.)


Real plant (as built)


Integration test (physical)

Name Integration test (physical) Description • Combination of modules is tested

• Based on module tests

• Verifying requirements fulfillment (functional, quality, etc.)

• Is done by a black-box test only using interfaces of modules

• Prevents unexpected behavior especially when using intelligent, adaptive self-optimizing and/or self-organizing modules like agents and mechatronic units

• Different testing techniques like top-down, bottom-up or big-bang can be used e.g. [Bei90], [Bin00]

Application cases

• Acceptance tests based on paper/digital information






Execution of behavior

Name Execution of behavior Description • Simulation of behavior of manufacturing systems is one key







Application cases








Application cases



Requirement Fulfillment Tracing

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

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

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

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

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

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

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

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

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

projects • Project management


Final acceptance

Test and validate overall real system. • Check conformance of overall system to drawings • Check functionality of overall system • Check correctness of system installation (electrical wiring, etc.) • Check behavior by execution of automation code / check

especially for emerging behavior • Check conformance of system / behavior to requirements


Accompanied project activities


Accompanying project activities


Project management

Name Project management Description • Managing (planning, organizing, securing) resources to successfully process a specific project

• Each Project is underlying typical constraints:

o Scope o Time o budget

• traditionally distinguished between five stages [Pro08]:

o initiation o planning o execution o monitoring & controlling o closing

• covering nine basic knowledge areas [Pro08]:

o Project Integration Management o Project Scope Management o Project Time Management o Project Cost Management o Project Quality Management o Project Human Resource Management o Project Communications Management o Project Risk Management o Project Procurement Management

Application cases • Project spanning activities


Consistency management

Name Consistency management Description • An important success factor for (mechatronic) engineering processes is the avoidance of data

inconsistencies among planning stages and engineering disciplines • Consistency management is the process of inconsistency avoidance based on

o Unique object identification of each plant components o One to one relation between plant component and plant component, the following terms apply

plant components do not contain the complete information about plant component in any case

Information based engineering artefacts that are independent from plant component are templates

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

o Automatic actualization of dependencies within different planning objects Change tracing and propagation Delta views between different planning stages and disciplines

• Consistency management provides means to guarantee engineering quality Application cases • Combination of planning stages

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


Change Management and Change Impact Analysis

Name Change Management and Change Impact Analysis Description • Within the mechatronic engineering process information within the different facets are integrated,

enriched, changed or deleted. • Information within facets may have dependencies, i.e. integration, enrichment, changes or deletions

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

• The process of integration, enrichment, changes or deletions of related information can o Have multiple levels o Be cyclic o Be executed automatically

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

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

additional wiring


User guidance within engineering process

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

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

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

• User guidance includes o First level passive user guidance provides information useable to understand and execute the

engineering process like help systems and documentations, o Second level passive user guidance provides basic engineering results which can be applied and

improved within the engineering process like pre-developed templates o Third level active user guidance analyses engineering result consistency and quality based on

consistency and quality rules like observation of code syntax within PLC programming o Fourth level active user guidance provides active engineering activity navigation through the

engineering process with engineering result observation like Microsoft Office letter assistant

Application cases • All engineering activities


Procurement

Name Procurement Description • Goal is to ensure that all resources needed for the project execution are available at the right time, at

the right place in the right quality and quantity

• Consists of the following seven steps

o Information gathering

o Supplier contact

o Background review

o Negotiations

o Fulfillment

o Consumption, maintenance, disposal

o Renewal

o Tender notification Application cases • Project spanning activities


Last tip…


Have (some) meetings…

… in order to build up trust, appreciation of each others work, dedication towards the common project goal and to avoid misunderstandings.

engineering handbook - grace...

Documents