See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/333986602

Generic automation task description for flexible assembly systems

Article in Procedia CIRP · January 2019

DOI: 10.1016/j.procir.2019.03.185

CITATIONS READS

0 148

3 authors:

Rainer Müller Matthias Scholer

ZeMA Universität des Saarlandes
80 PUBLICATIONS 295 CITATIONS 13 PUBLICATIONS 48 CITATIONS

SEE PROFILE SEE PROFILE

Martin Karkowski
ZeMA
6 PUBLICATIONS 2 CITATIONS

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

FOURBYTHREE: Highly customizable robotic solutions for effective and safe human robot collaboration in manufacturing applications View project

Tolerance Management for the Assembly View project

All content following this page was uploaded by Martin Karkowski on 27 June 2019.

The user has requested enhancement of the downloaded file.

 Available online at www.sciencedirect.com

ScienceDirect
Procedia CIRP 81 (2019) 730–735
www.elsevier.com/locate/procedia

52nd CIRP Conference on Manufacturing Systems

Generic automation task description for flexible assembly systems

Rainer Müller, Matthias Scholer, Martin Karkowski*
ZeMA gGmbH – Zentrum für Mechatronik und Automatisierungstechnik, Eschberger Weg 46, D-66121 Saarbrücken, Germany

* Corresponding author. Tel.: +49 (0) 681 85787 529; fax: +49 (0) 681 85787 11. E-mail address: m.karkowski@zema.de

Abstract

To face the increased requirements for mass customization and frequent technological changes, currently used assembly systems require a high
level of flexibility and re-configurability. These requirements lead to increased time-to-manufacture and manufacturing costs, which goes against
manufacturer’s goals. To mitigate the impact of these challenges a holistic approach for planning and programming an assembly system is
presented in this paper. The approach will minimize the implementation effort of flexible automation tasks suitable for industrial applications by
utilizing a combination of an abstract process description, a virtual model of the assembly system, and a standardized control system
© 2019 The Authors. Published by Elsevier Ltd.
This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/3.0/)
Peer-review under responsibility of the scientific committee of the 52nd CIRP Conference on Manufacturing Systems.
Keywords: assembly systems, control system, modularity, workflow, design methodology

1. Introduction process. The specification is later used as work instruction for

To handle the needs for mass customization, flexible and
adaptable assembly systems are required [1]. Customized
automation, human robot cooperation (HRC) and modular
assembly systems are utilized to face these challenges. This
results in an increased complexity of the already demanding
implementation of an automation task [1,2]. In addition, while
widely used, Programmable Logic Controllers (PLCs) only
offer a low level of abstraction, which complicates the
development of reusable, maintainable and well-structured
software components even more. [3]
Because of changing market situations, the assembly system
– and thereby its software – remains subject of many
technological changes. The thereby extended implementation
process goes against the demand for faster commissioning of
assembly systems, reduced costs and a shortened time-to-
manufacture [1], and leads to the need for holistic design of
assembly systems.
This paper presents a holistic approach to reduce the
implementation effort of flexible assembly systems suitable for
industrial applications. Therefore the specification of an
assembly system and processes is obtained from an iterative
a standardized control system. As a consequence the assembly
process is expressed as a sequence of skills and is divided into
a program-flow – the logic of the process – and a data-flow –
the flow of information during the process. Based on this
generic task description, the suitable production equipment
implementing those skills via services can be determined. This
generic task description is then detailed and adapted. To
execute the assembly task a virtual model of the assembly
system – describing its independencies and properties – is
designed. Afterwards the virtual model and the task description
are exported into the standardized control system, to perform
the assembly process.
Section 2 presents the theoretical basics of this research as
an introduction to the topic. The following section 3
summarizes currently published approaches to simplify the
implementation process of an assembly process. Based on those
approaches, the research needs are identified (section 4) and the
developed approach is presented in detail (section 5). The
designed modular control system and its main components are
briefly introduced in section 6.

2212-8271 © 2019 The Authors. Published by Elsevier Ltd.

This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/3.0/)
Peer-review under responsibility of the scientific committee of the 52nd CIRP Conference on Manufacturing Systems.
10.1016/j.procir.2019.03.185
 Rainer Müller et al. / Procedia CIRP 81 (2019) 730–735
2. Theoretical Basis
2.1. Software Architectures
Architectural patterns are reusable solutions for commonly
occurring problems which divide systems into smaller sub
systems. Architectural patterns may also contain design
patterns, which define the relations between different elements
of the system to achieve the desired goals. [4] Currently used
development models are often service- or agent-based. A
Service Orientated Architecture (SOA) describes how systems
provide and consume loosely coupled services (methods and
applications) – the orchestration of the system – to achieve a
given goal instead [3,4].
2.2. Programmable Logic Controller (PLC)
In most production systems, process state changes are
triggered by events, for instance changed pressure values. By
now PLCs are utilized as economical solutions for controlling
those production systems. Next to the economic benefits,
machine manufactures are facing constraints related to the
characteristics of PLCs. PLCs are characterized by their cyclic
data processing and real-time execution, which results in a state
based design for sequencing control. [5,6] Due to the low level
of abstraction, the fail supporting high-level programming. [7]
2.3. Petri nets
Petri nets represent discrete event dynamic systems and
consist of four basic elements – places, transitions, arcs and
tokens. Whereas places model states of a system or subsystem,
transitions model the activities and events of a system. To
indicate that a modelled state is met, places can contain tokens.
These tokens are consumed or produced by the transitions of a
net. Arcs connect places with transitions or vice versa and
define the flow of the tokens. [8]
The explicit state-based modelling of a system enables
simplified analysis of the system. In addition, petri nets have a
formal mathematical description and support simple methods
for model-checking. For modelling a petri net, their graphical
representation is utilized. [9]
3. Approaches to simplify the Implementation Process of
Automation Systems
Approaches to simplify the implementation of automation
system are often based on standardization, the utilization of
(customizes) middleware, and (multi-) agent-systems for
process planning and execution. These tools are summarized in
the following sections.
3.1. Standardization of Programming Languages,
Communication Protocols and Exchange Formats
Despite the standardization of textual and graphical
programming languages of PLCs (IEC 61131-3), it remains a
manufacturer’s task to apply this standard. (compare [10,11]).
The PLCopen XML standard was developed on top of
731
IEC 61131-3 standard, to be a distribution format for function
block libraries, which could be used on different platforms [12].
An event based programming paradigm for PLCs is provided
by the IEC 61499. It utilizes concepts and methodologies of
modern software, but it is widely claimed that it doesn’t satisfy
the requirements of automation systems. [13,14]
Next to a standardization of the utilized Programming
Languages, standards for communication layers and protocol –
like the Open Platform Communications - Unified Architecture
(OPC-UA) – have been developed. OPC-UA combines a
language and platform independent communication model with
a generic information model. This enables a platform
independent implementation of an automatic task
communication with other control systems or software like
ERP- or MES-Systems. [15] Thereby OPC-UA simplifies and
unifies the distribution and communication of controllers.
AutomationML™ – a XML-based neutral and object
orientated data exchange format to save interdisciplinary
planning data – is capable of storing geometric, kinematic,
logical and structural information of a technical facility. It
utilizes already existing data formats like Collada (geometry
and kinematic information) and CAEX (structural information).
[16]
3.2. Utilizing Middleware
Middleware is defined as a generic software layer for
distributed software, which simplifies its distribution and
unifies communication between the nodes. [4] Due to its
generic approach, middleware enables high-level
programming. In addition, it often offers various packages for
common domain specific tasks like path planning, navigation
and machine vision. [17] Nevertheless, the development of
complex systems often becomes challenging due to the
overhead caused by required prior knowledge of the setup,
configuration and integration [18].
3.3. Utilizing (Multi-)Agent-Systems
Distributed assembly system controllers relying on
middleware and standard communication models only shift the
effort of implementing the required system behavior. [19] To
support the implementation process, projects like MyJoguhrt
[20] or SkiROS [21] utilize self-organizing agent systems on
top of middleware. Unfortunately Wooldridge [22] describes
the behavior of distributed agent systems as hardly predictable,
which contradicts the requirements for maintainability and
safety. The high safety requirements and standards of semi-
automated systems prevents using those approaches in an
industrial applications without further adaptation.
3.4. Published Research Projects
On top of the presented tools, concepts such as “Plug and
Produce” [23,24] – a vision, enabling structural changes in
automatic systems with minimal manual adaption and
reconfiguration of the software – have been developed.
Based on the conceptual implementation of this vision
different aspects such as automatic integration of real-time
732 Rainer Müller et al. / Procedia CIRP 81 (2019) 730–735
communication systems [25,26], “high-level” programming
[23,27] or automatic programming [3,25,28] are considered in
different research projects. To create more versatile systems
with automatic configuration, the concepts of skills and self-
describing assets are introduced (e.g. [24], [28] or [29]). This
enables automatic orchestration of processes based on the
current configuration of the system and a corresponding task
description. The mentioned approaches following the Product
Process Resource (PPR)-based modelling, utilize a stateless
description of the assembly process, which complicates the
consideration of relevant aspects for an industrial application,
such as processes having encountered errors or disturbances
caused by human workers. In addition, these concepts are
hardly transferable to the standards regarding hardware and
software used by the industry.
4. Research Needs
One significant challenge is to provide a simple, predictable,
flexible and maintainable task description, which satisfies
standards used by the industry while reducing the
implementation effort of the assembly process and system. In
particular, mid-life cycle adaptations of the system and
interaction with a human worker must be considered. The main
research questions are:
• How can a holistic planning method for an assembly
system and its corresponding assembly process be
designed to support a developer during the specification,
configuration, (re-) implementation and adaptation stages?
• How can an assembly process and system be modelled in
such a way that it helps to identify critical states and events
which can occur as well as to model the disturbances
caused by human workers?
• How can the assembly process be expressed to become a
deterministic work instruction for a standardized control
system?
5. Methodology
In order to address these research questions, a holistic and
iterative methodology is introduced (Fig. 1). The service based
approach seems to be appropriate to describe a distributed,
flexible and loosely coupled assembly system, whereas
utilizing the concept of skills provides a more generic high-
level description of the process and system.
The solution oriented approach separates the technical
implementation and the design of the assembly process.
Utilizing petri nets as a formal description of an assembly
process – and thereby the orchestration of the services – allows
for predictable behavior during runtime.
To interpret the generated process specification and thereby
speed up the virtual commission and simplify the
implementation, a standardized control concept is utilized.
Fig. 1. Graphical representation of the Methodology.
5.1. Determining the assembly process and –system
Beginning with a detailed analysis of the product being
considered, the product-related requirements for the assembly
process are derived. Based on those requirements, the assembly
process is planned. This results in a process sequence, structure
as well as a list of assembly operations for each assembly
station. In a next step this information is analyzed to determine
the necessary operations of the assembly stations.
In doing so, the assembly operations are constructed from
smaller and generic skills. The skills are combined into
program-flows and data-flows. Whereas the program-flow
describes the required logic to perform the assembly process,
the data-flow is used to model the flow of information during
the process. Combined, the data-flow and program-flow will be
called workflow.
The program-flow is expressed as a petri net, wherein each
place represents a state while performing the described process.
These transitions between states can occur by performing a skill
(for instance open a valve during a filling process) or a status
change (for instance a changed pressure value during a filling
process). These changes are modelled with transitions and their
conditions. The defined conditions have to be fulfilled to
change the state of the process.
Utilizing petri nets as formal and simple descriptions of the
logic, simplifies parallelization and synchronization of
assembly operations and enables later execution, analysis and
simulation of the process. Due to the state based modelling,
petri nets support situational definition of the assembly
system’s behavior. Furthermore, petri nets provide an intuitive
and simple visual model of the process.
Next to the program-flow, the data-flow – the flow of
information between the used skills of the workflow – has to be
modelled. This enables connecting information from different
software functionalities or the utilized production equipment to
other elements.
An additional semantic model for describing the assembly
process allows a more abstract, reusable and generic
 Rainer Müller et al. / Procedia CIRP 81 (2019) 730–735 733

description. The semantic model is used to determine the the determined production equipment. This results in detailing
required production equipment based on the required skills. For the workflow by adding additional states and required skills
this purpose, a predefined modular system is utilized, whose into the workflow. As a result, the designing process of the
elements implement skills via services. assembly system and process becomes iterative and must be
An assembly station is obtained by a skill-based matching carried out until appropriate production equipment have been
process. During this process, a set of appropriated elements, determined for all required skills.
capable to performing the required skills of the workflow, is An example is given in Fig. 2, in which “Object A” must be
generated, whereas skills, on the other hand, can be established picked at its current position and placed at a desired position. In
by combining multiple skills or services. the given example, the “Pick-and-Place” operation should be
The elements must respect the requirements of the product performed by a robotic system. Therefore the position of the
and process and must be compatible with one another. object must be detected. Then the robot must move to that
position and grab the object by closing its gripper. After
5.2. Detailing the workflow grabbing the object, the robot must move to the desired position
and can open the gripper.
Process Planning To obtain all states and events of the assembly process, the
description is expanded and specified until every transition of
the process is able to fire without consuming time. From the
Pick & Place
Object A
Object A from
Object A given example, the highlighted transitions and states are
at at considered and detailed. After a successful detection of the
“Pos. 1“ to
“Pos. 1“ “Pos. 2“
“Pos. 2“ object’s position, an idling robot can be commanded to the
determined position. Therefore the robot changes its state to
Abstract Process
“moving robot”.
Assigning the Pick and Place Task to a Robot To fully specify the process, the newly added states have to
be analyzed. In doing, critical events (highlighted in yellow) of
Object A
at Close Gripper
Robot at the process regarding the application and the current state are
„Pos. 2“ determined and actions to prevent those unwanted states system
„Pos. 1“
must be derived. For instance, a human could enter the robot’s
workspace while it is moving. In this example, the robot must
Detect Object A
stop, which could require fencing off the robot’s workspace or
Object A
grasped
Open Gripper integrating additional sensors to detect the human being.
In addition to the logic of the assembly process the
“Pos.1“ Robot at
information flow has to be modelled. Therefore the inputs and
known “Pos. 1“
outputs of services and skills are connected among each other
Object A to specify the required input parameters of a service. In the
at
Command Robot
Command Robot Command Robot “Pos. 2“
given example, the skill to detect the object extracts the object’s
to “Pos. 1“ to “Pos. 2“ id and position. This position is used as target position to
More detailed Program-Flow to perform the Pick & Place Task
command the following service. Next to dynamic values,
constants can be used as inputs. For instance, speed and
Specification of the sub process
acceleration are limited to the specified values. To allow data
Object A Command Robot
aggregation of multiple data sources, partial connections are
Human enters allowed. This allows for e.g. using only the translation of a pose
detected to “Pos. 1“
Position Target as an input parameter.
ID Acceleration
Speed
Robot is
Collision Thereby integrating technical upgrades into the assembly
moving
… system results inter alia in adapting the dataflow.
Move-Task
“Pos. 1“ completed 5.3. Defining a virtual model
known
Next to the assembly process and a data model, the physical
assembly system’s electrical and mechanical design has to be
1.0 m/s² modelled. Based on this model, certain connections of the
Robot is Robot at
idling “Pos. 1“ production equipment like their kinematic coherences and
1.0 m/s
interdependencies can be obtained. To match the physical
Fully specified Workflow with highlighted Data-Flow assembly system, the corresponding parameters of the model
can be adapted. This allows adapting the system in its
Fig. 2. Example of detailing the workflow. The detailed operation contains mechanical design without adapting the workflow. In the given
the required process-logic and data-flow. example mounting a previously static installed camera – for
object detection – to the robot’s end-effector requires only
After obtaining the assembly process and station, the generic adapting the virtual model without adapting the workflow.
skills of the workflow are replaced with the actual services of
734 Rainer Müller et al. / Procedia CIRP 81 (2019) 730–735

An additionally semantic description of sensor-values, data-
points and events complete the virtual model.
5.4. Performing the assembly process
After the mechanical and electrical setup of the assembly
system, the virtual model has to be transferred into the
standardized control system. An assembly operation is
performed by loading and starting the corresponding worklist.
Thereby its stored assembly operations are executed predictable
by the control system. Alternating product variants or
production equipment of the system is performed by adapting
the service or workflow and if necessary the virtual model of
the assembly system.
6.1. Dynamic logic interpreter –DLI
To analyze and execute the given program-flow of the
assembly process, the DLI generates the corresponding petri
net. The transitions are designed as agents sensing their
surrounding for changes. Thereby they are able to check their
firing conditions autonomously. Based on the distributed design
of the DLI, the transitions have to request firing at a supervised
manager if they are able to fire to prevent runtime related
synchronization errors. On firing a transition, the supervised
manager asynchronously request the execution of linked
services at the modular broker system.
6.2. Volatile Memory System – VMS

6. Architecture of the Control System The VMS is used to represent the information model of the
assembly system and processes. Therefore all data of the
Virtual Model Workflow utilized modules and results of performed services are merged
Object A Command Robot
detected
Position
ID
to “Pos. 1“
Target
Acceleration Robot is
Human enters

into a shared data space. Its data is accessed and manipulated

Speed Collision
A.1 E.1 moving
…

Move-Task
with text-based data-pointers. The shared data space of the
A B.1 C.1 „Pos. 1“
known
completed

B E.2 1.0 m/s²

VMS includes a topic-based publish-and-subscribe pattern for
Object A

B.2 D 1.0 m/s

Robot is
idling
at „Pos.
2“ the contained data-points. By utilizing a publish-and-subscribe
pattern, changing the content of data-points results in adapting
Modular Workflow-Engine the information model as well as informing its subscribers.
Dynamic Logic Volatile Modular Broker
Interpreter Memory System 6.3. Modular Broker System – MBS
System

➔ PROGRAM-FLOW ➔ DATA-FLOW ➔ EXECUTION The extendable MBS delegates and observes the execution
of a service at its provider. Therefore the MBS determines the
CONNECTOR required service providers at its service registry and forwards
the requests to the service providers utilizing the specified
communication layers. During the execution of a service, its
Internal
MQTT OPC-UA ROS … status, errors and results are forwarded to the VMS, which leads
Module
to updating the information model. To cancel the execution of
Communication Layers a service, the MBS keeps track of currently active services.
Service Providers
6.4. Communication Layers

Communication layers are used to enable extension of the

control system by providing generic interfaces for different
communication protocols. Therefore communication protocols
are connected with the VMS. This allows bridging between
Fig. 3. Elements of the modular control system. different protocols. The integration of different communication
protocols decouples the control system from specific
To utilize the virtual model and workflow of the assembly communication models.
system and process, the modular control system consists of the
following main elements (Fig. 3): 6.5. Modules

• A Dynamic Logic Interpreter (DLI) for interpreting, The required skills and thereby services of a workflow are
analyzing and executing the given logic of a workflow. provided and performed by modules. These modules are used
• A Volatile Memory System (VMS) for verifying the to implement a required behavior of the production equipment
configured data-flow and thereby connecting the inputs or logical functionalities in services. The modules extend the
and outputs of the services. functionality of the control system. Modules are developed
• A Modular Broker System (MBS) for processing the independently and can be distributed to other computational
requested service defined in the workflow. units. Therefore they are integrated over the communication
• Communication Layers to connect to the services layers.
• Modules providing at least one required service
 Rainer Müller et al. / Procedia CIRP 81 (2019) 730–735
7. Conclusion and Outlook
To decrease the implementation effort of flexible assembly
systems and their processes, a new development method and
the architecture of a generic modular control system are
presented.
The service based approach and concept of skills are utilized
to obtain a more generic task description and separate the
technical implementation of the assembly system from the
assembly operations. The assembly process is expressed as an
orchestration of skills, called “generic workflow”. The
orchestration is defined as a petri net and consists of a program-
flow – describing the logic of the process – and an information
flow – called data-flow. The state based modelling of the
assembly process supports identifying critical and unwanted
states. Preventing those states supports developing safe
processes suitable for industrial applications.
The generic task description is used to derive the required
production equipment, which will implement the skills via
services. These assets and their interdependencies are modelled
in the virtual model. Based on the application, selecting
production equipment results in iterative adaptation and
[17] M. Quigley, K. Conley, B. P. Gerkey et al., “ROS: an open-source Robot
detailing of the workflow and virtual model by adding
additional skills, states, transitions, and, if necessary,
production equipment.
To perform the assembly process the virtual model and the
workflow – thereby the specification of the assembly system
and its process – are transferred into a standardized control
system. This reduces the time-to-manufacture by providing a
basically programming-free implementation process.
Small case studies proved the flexibility of the control
system and the development method. Currently the validation
and optimization of the methodology is done with industrial
application partners in a complex use-case with requirements
for real-time. Therefore a web-based graphical editor will be
used to model the workflow and virtual model, which is
currently in development. In the future a more precise semantic
model of the assembly system and process will be examined.
References
[1] G. Michalos, S. Markis, N. Papakotas et al., “Automotive assembly
technologies review: challenges and outlook for a flexibleand adaptive
approach,” CIRP: Journal of Manufactoring Sience and Technology, vol.
2010, no. 2, pp. 81–91.
[2] F. Jammes and H. Smit, “SERVICE-ORIENTED PARADIGMS IN
INDUSTRIAL AUTOMATION,” vol. 2015, pp. 716–723, 2015.
[3] M. Loskyll, I. Heck, J. Schlick et al., “Context-Based Orchestration for
Control of Resource-Efficient Manufacturing Processes,” Future Internet,
vol. 4, no. 3, pp. 737–761, 2012.
[4] J. Goll, Methoden und Architekturen der Softwaretechnik,
Vieweg+Teubner Verlag, Wiesbaden, 2011.
[5] B. Vogel-Heuser, J. Fischer, S. Feldmann et al., “Modularity and
architecture of PLC-based software for automated production Systems:
An analysis in industrial companies,” Journal of Systems and Software,
vol. 131, pp. 35–62, 2017.
[6] G. Olsson, “Programmable Logic Controllers,” in Handbook of
Networked and Embedded Control Systems, D. Hristu-Varsakelis, R.
Alur, K.-E. Årzén et al., Eds., pp. 259–278, Birkhäuser Boston, Boston,
MA, 2005.
View publication stats
735
[7] Z. Mammeri, ed., IEEE 16th Conference on Emerging Technologies &
Factory Automation (ETFA), 2011: Toulouse, France, 5 - 9 Sept. 2011,
IEEE, Piscataway, NJ, 2011.
[8] W. Reisig, Understanding Petri Nets, Springer Berlin Heidelberg, Berlin,
Heidelberg, 2013.
[9] W.M.P. van der Aalst, “Geschäftsprozessmodellierung: Die ,,Killer-
Applikation“ für Petrinetze,” Informatik-Spektrum, vol. 37, no. 3, pp.
191–198, 2014.
[10] Siemens, “Standards compliance according to IEC 61131-3 (3rd
Edition),” vol. 2015.
[11] International Electrotechnical Commission, “IEC International Standard
IEC 61131–3,” 2013-02, 61131–3.
[12] PLCopen Technical Committee 6, “XML Formats for IEC 61131-3,”
http://www.plcopen.org/pages/tc6_xml/downloads/tc6_xml_v201_technic
al_doc.pdf.
[13] K. Thramboulidis, “IEC 61499 vs. 61131: A Comparison Based on
Misperceptions,”.
[14] L. H. Yoong, P. S. Roop, Z. E. Bhatti et al., Model-Driven Design Using
IEC 61499: A Synchronous Approach for Embedded and Automation
Systems, Springer International Publishing, Cham, s.l., 2015.
[15] OPC Foundation, “PLCopen for efficiency in automation: Introduction
in the PLCopen and OPC UA Communications Model,” OPC Foundation,
http://www.plcopen.org/pages/tc4_communication/downloads/intro_plco
pen_opc_v3.pdf.
[16] “<AutomationML/>: standardized data exchange in the engineering
process of production systems,” vol. 2018.
Operating System,” ICRA Workshop on Open Source Software, 2009.
[18] R. Hoogervorst, “VIKI—More Than a GUI for ROS,” in ROBOT
OPERATING SYSTEM: The complete reference, pp. 633–655, Springer,
[S.l.], 2017.
[19] J. Jasperneite, S. Hinrichsen, and O. Niggemann, “,,Plug-and-Produce“
für Fertigungssysteme,” Informatik-Spektrum, vol. 38, no. 3, pp. 183–
190, 2015.
[20] D. Pantförder, F. Mayer, C. Diedrich et al., “Agentenbasierte
dynamische Rekonfiguration von vernetzten intelligenten
Produktionsanlagen: Evolution statt Revolution,” in Handbuch Industrie
4.0, M. ten Hompel, B. Vogel-Heuser, and T. Bauernhansl, Eds., 2016.
[21] F. Rovida, M. Crosby, D. Holz et al., “SkiROS—A Skill-Based Robot
Control Platform on Top of ROS,” in ROBOT OPERATING SYSTEM:
The complete reference, pp. 121–160, Springer, [S.l.], 2017.
[22] M. J. Wooldridge, An introduction to multiagent systems, Wiley,
Chichester, 2009.
[23] A. Zoitl, Dr., “AutoPnP - Plug&Play für Automatisierungssysteme:
Schlussbericht - Konsortialbericht,”.
[24] P. Ferreira and N. Lohse, “Configuration Model for Evolvable Assembly
Systems,” 2012.
[25] C. Buckl, G. Kainz, N. Keddis et al., “Technische Umsetzung des
Plug&Play-Konzepts auf Basis von CHROMOSOME im Projekt
AutoPnP: Plug&Play-Umsetzung in Chromosome,” 2014.
[26] J. Jatzkowski, P. Adelt, and A. Rettberg, “Hierarchical Scheduling for
Plug-and-Produce,” Procedia Technology, vol. 26, pp. 227–234, 2016.
[27] N. Antzoulatos, E. Castro, D. Scrimieri et al., “A multi-agent
architecture for plug and produce on an industrial assembly platform,”
Production Engineering, vol. 8, no. 6, pp. 773–781, 2014.
[28] P. Danny, P. Ferreira, N. Lohse et al., “An AutomationML model for
plug-and-produce assembly systems,” in 2017 IEEE 15th International
Conference on Industrial Informatics (INDIN): University of Applied
Science Emden/Leer, Emden, Germany, 24-26 July 2017 : proceedings,
pp. 849–854, IEEE, Piscataway, NJ, 2017.
[29] J. Pfrommer, D. Stogl, K. Aleksandrov et al., “Modelling and
orchestration of service-based manufacturing systems via skills,” in IEEE
[International Conference on] Emerging Technologies and Factory
Automation (ETFA), 2014: 16 - 19 Sept. 2014, Barcelona, Spain, pp. 1–4,
IEEE, Piscataway, NJ, 2014