GRACE| June 2013| www.grace-project.org|Page 1
Contract n° NMP2-SL-2010-246203
Engineering Handbook
GRACE| June 2013| www.grace-project.org|Page 2
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
GRACE| June 2013| www.grace-project.org|Page 3
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.
GRACE| June 2013| www.grace-project.org|Page 4
Part 1 -
GRACE Multi-Agent System (MAS) for decentralized production
systems
GRACE| June 2013| www.grace-project.org|Page 5
Multi-Agent Systems
GRACE| June 2013| www.grace-project.org|Page 6
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.
GRACE| June 2013| www.grace-project.org|Page 7
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.
GRACE| June 2013| www.grace-project.org|Page 8
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| June 2013| www.grace-project.org|Page 9
GRACE MAS architecture
GRACE| June 2013| www.grace-project.org|Page 10
• 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)
GRACE| June 2013| www.grace-project.org|Page 11
• 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)
GRACE| June 2013| www.grace-project.org|Page 12
• 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)
GRACE| June 2013| www.grace-project.org|Page 13
• 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)
GRACE| June 2013| www.grace-project.org|Page 14
• 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| June 2013| www.grace-project.org|Page 15
GRACE – Multi-Agent System
GRACE ontology
GRACE| June 2013| www.grace-project.org|Page 16
Part 2 -
Fischertechnik® Plant Demonstrator
GRACE| June 2013| www.grace-project.org|Page 17
Fischertechnik® Demonstrator
GRACE| June 2013| www.grace-project.org|Page 18
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
GRACE| June 2013| www.grace-project.org|Page 19
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
GRACE| June 2013| www.grace-project.org|Page 20
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
GRACE| June 2013| www.grace-project.org|Page 21
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
GRACE| June 2013| www.grace-project.org|Page 22
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
GRACE| June 2013| www.grace-project.org|Page 23
Fischertechnik® Demonstrator – Positioning and security switches 2
Security switches
X-Position switches
Y-Position switches
Z-Position switches
GRACE| June 2013| www.grace-project.org|Page 24
Fischertechnik® Demonstrator – positioning axis’
X1X2
X3X4
X5
X6X7
X8
X1X2
X3
X4X5
X6X7
X8
Y1Y2
Y1
Y2
Y3
Y3 y
x
z
GRACE| June 2013| www.grace-project.org|Page 25
Part 3 -
Engineering decentralized Production Systems using GRACE
Engineering Methodology
GRACE| June 2013| www.grace-project.org|Page 26
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.
GRACE| June 2013| www.grace-project.org|Page 27
Concept Design Phase
GRACE| June 2013| www.grace-project.org|Page 28
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
GRACE| June 2013| www.grace-project.org|Page 29
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
GRACE| June 2013| www.grace-project.org|Page 30
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.
GRACE| June 2013| www.grace-project.org|Page 31
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.
GRACE| June 2013| www.grace-project.org|Page 32
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
GRACE| June 2013| www.grace-project.org|Page 33
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
GRACE| June 2013| www.grace-project.org|Page 34
Plant hierarchy
GRACE| June 2013| www.grace-project.org|Page 35
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
GRACE| June 2013| www.grace-project.org|Page 36
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).
Application cases • Manufacturing system structuring
• Hierarchy definition
• Reuse of engineering results
• Specification of manufacturing system capabilities
GRACE| June 2013| www.grace-project.org|Page 37
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
Application cases • Manufacturing system structuring
• Hierarchy definition
• Reuse of engineering results
• Specification of manufacturing system capabilities
GRACE| June 2013| www.grace-project.org|Page 38
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.
GRACE| June 2013| www.grace-project.org|Page 39
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
GRACE| June 2013| www.grace-project.org|Page 40
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
GRACE| June 2013| www.grace-project.org|Page 41
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
GRACE| June 2013| www.grace-project.org|Page 42
Plant hierarchy & modularization – crane system
GRACE| June 2013| www.grace-project.org|Page 43
Plant hierarchy & modularization – manufacturing and transportation system
GRACE| June 2013| www.grace-project.org|Page 44
Basic Design Phase
GRACE| June 2013| www.grace-project.org|Page 45
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
GRACE| June 2013| www.grace-project.org|Page 46
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)
GRACE| June 2013| www.grace-project.org|Page 47
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.
GRACE| June 2013| www.grace-project.org|Page 48
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
• Specification of manufacturing system capabilities
• Definition of necessary module characteristics
• Parallel and distributed engineering
GRACE| June 2013| www.grace-project.org|Page 49
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.
GRACE| June 2013| www.grace-project.org|Page 50
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
GRACE| June 2013| www.grace-project.org|Page 51
System architecture with general modules
Instantiate reusable modules from library
in order to create system architecture
within the engineering tool based on general
modules
GRACE| June 2013| www.grace-project.org|Page 52
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
GRACE| June 2013| www.grace-project.org|Page 53
P&ID Electrical
Circuit Diagram
Object „Drive“
Electrical Single Line Diagram
3D Model
Logical Diagram
Cabinet Layout
System views
GRACE| June 2013| www.grace-project.org|Page 54
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
GRACE| June 2013| www.grace-project.org|Page 55
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
GRACE| June 2013| www.grace-project.org|Page 56
Detailed Design Phase
GRACE| June 2013| www.grace-project.org|Page 57
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
• Specification of manufacturing system capabilities
GRACE| June 2013| www.grace-project.org|Page 58
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
GRACE| June 2013| www.grace-project.org|Page 59
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.)
GRACE| June 2013| www.grace-project.org|Page 60
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
GRACE| June 2013| www.grace-project.org|Page 61
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
GRACE| June 2013| www.grace-project.org|Page 62
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
GRACE| June 2013| www.grace-project.org|Page 63
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
GRACE| June 2013| www.grace-project.org|Page 64
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
• Specification of manufacturing system capabilities
• Use of templates within the process of device structure definition and implementation
GRACE| June 2013| www.grace-project.org|Page 65
Detailed system specifications (drawings)
3D module drawings
Automation drawings
Electrical drawings
Bill of Materials
GRACE| June 2013| www.grace-project.org|Page 66
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
• Engineering project management and quality control
• Acceptance test preparation
• Behavior simulation
• Virtual commissioning
GRACE| June 2013| www.grace-project.org|Page 67
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
GRACE| June 2013| www.grace-project.org|Page 68
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
GRACE| June 2013| www.grace-project.org|Page 69
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
GRACE| June 2013| www.grace-project.org|Page 70
Realization & Commissioning phase
GRACE| June 2013| www.grace-project.org|Page 71
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
• Engineering project management and quality control
• Acceptance test preparation
• Behavior simulation
• Virtual commissioning
GRACE| June 2013| www.grace-project.org|Page 72
Execution of behavior
Name Execution of behavior 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
GRACE| June 2013| www.grace-project.org|Page 73
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
GRACE| June 2013| www.grace-project.org|Page 74
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
GRACE| June 2013| www.grace-project.org|Page 75
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
• Specification of manufacturing system capabilities
• Use of templates within the process of device structure definition and implementation
GRACE| June 2013| www.grace-project.org|Page 76
Detailed system specifications (drawings)
3D module drawings
Automation drawings
Electrical drawings
Bill of Materials
GRACE| June 2013| www.grace-project.org|Page 77
Real plant (as built) - mechanical
Mechanical construction of the plant based on drawings
GRACE| June 2013| www.grace-project.org|Page 78
Real plant (as built) - electrical
Electrical installation (wiring, pinning, power supply) of the plant
GRACE| June 2013| www.grace-project.org|Page 79
Real plant (as built) - automation
Implementation of plant automation (installation/setup of hardware; compiling and deployment of Software; teaching, etc.)
GRACE| June 2013| www.grace-project.org|Page 80
Real plant (as built)
GRACE| June 2013| www.grace-project.org|Page 81
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
• Engineering project management and quality control
• Acceptance test preparation
• Behavior simulation
• Virtual commissioning
GRACE| June 2013| www.grace-project.org|Page 82
Execution of behavior
Name Execution of behavior 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
GRACE| June 2013| www.grace-project.org|Page 83
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
GRACE| June 2013| www.grace-project.org|Page 84
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
GRACE| June 2013| www.grace-project.org|Page 85
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
GRACE| June 2013| www.grace-project.org|Page 86
Accompanied project activities
GRACE| June 2013| www.grace-project.org|Page 87
Accompanying project activities
GRACE| June 2013| www.grace-project.org|Page 88
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
GRACE| June 2013| www.grace-project.org|Page 89
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
GRACE| June 2013| www.grace-project.org|Page 90
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
GRACE| June 2013| www.grace-project.org|Page 91
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
GRACE| June 2013| www.grace-project.org|Page 92
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
GRACE| June 2013| www.grace-project.org|Page 93
Last tip…
GRACE| June 2013| www.grace-project.org|Page 94
Have (some) meetings…
… in order to build up trust, appreciation of each others work, dedication towards the common project goal and to avoid misunderstandings.