Content uploaded by Eike Wolfram Schäffer
Author content
All content in this area was uploaded by Eike Wolfram Schäffer on Nov 14, 2019
Content may be subject to copyright.
System architecture and conception of a standardized
robot configurator based on microservices
Eike Schäffer1a, Tobias Pownuk1b, Joonas Walberer1c, Andreas Fischer2, Jan-Peter
Schulz3, Marco Kleinschnitz4, Matthias Bartelt5e, Bernd Kuhlenkötter5f, Jörg Franke1d
1 Institute for Factory Automation and Production Systems (FAPS),
University Erlangen-Nuremberg, http://faps.fau.de
aEike.Schaeffer@faps.fau.de
bTobias.Pownuk@fau.de
cJoonas.Walberer@fau.de
dJoerg.Franke@faps.fau.de
2Robert Bosch GmbH, AndreasFabian.Fischer@de.bosch.com
3ICARUS Consulting GmbH, jan-peter.schulz@icarus-consult.de
4Infosim GmbH & Co. KG, kleinschnitz@infosim.net
5Institute of Production Systems (LPS), Ruhr-University of Bochum (RUB)
eBartelt@lps.ruhr-uni-bochum.de
fKuhlenkoetter@lps.ruhr-uni-bochum.de
Abstract. The design and integration of robotic-based automation solu-
tions is a common problem for robotic component providers and espe-
cially for their consumers. In this work, a standardized robot configurator
is introduced, based on a modular system architecture and best practice
solutions. Due to this modular structure, as a backbone of an intuitive
web-based configurator, customized robot applications can easily be
planned, visualized, simulated and finally realized. The system architec-
ture of the presented robotic configurator is based on microservices,
which is a modern, scalable and complexity-reducing solution for the
overall system. This paper demonstrates an exemplary configuration pro-
cess to get an impression about the prospective use of pre-configured ro-
botic solutions.
Keywords: Configurators, robot configuration, microservice architecture
1 Introduction
The increasing possibilities and functionalities of robot systems and the continuously
growing technical requirements in industrial applications (e.g. high precision, repro-
ducibility and safety) lead to high levels of complexity for the successful implementa-
tion of robotic automation solutions. Robotics engineers need a deep understanding of
robot kinematics, programming and a comprehensive experience to meet the specific
consumers’ requirements. Since necessary engineering tools are not available or are
isolated applications, the functional and secure integration of individual peripheral
2
components is often realized in expensive trial-and-error procedures. The development
processes for robot solutions are therefore characterized by high engineering costs for
robotic system engineers and integrators. For this reason, individual, special-purpose
and therefore complex and unique solutions are created. However, their engineering
expenses do not achieve an economical cost-benefit ratio, especially for small and me-
dium-sized enterprises.
To overcome this issue, we present within this paper we present a concept for an
intelligent standardization and reuse of software, hardware, and peripheral components
in order to achieve a significant reduction in quotation and engineering expenses for
robotic applications. The solution will be a modular platform for planning and simula-
tion of robot-based systems. This platform allows a systematic development, applica-
tion, and marketing in the areas of industry, logistics and services.
The proposed platform includes a robotic configurator that suggests appropriate
best-practice robot component combinations, depending on process and interface char-
acteristics. By using a standardized engineering tool with unified interfaces for kine-
matics, effectors, sensors, peripherals, and controls as well as publicly available soft-
ware libraries and knowledge-bases, a rapid implementation of robotic automation con-
cepts will be achieved.
This article is structured as follows. Section 2 provides a comprehensive insight into
the state of the art and the challenges of the implementation of robotics solutions. The
system architecture for a standardized configuration process is presented in section 3.
Section 4 describes an exemplary configuration procedure of a robot system based on
best-practice solutions. A summary and an outlook about further research work is given
in section 5.
2 State of the Art / Related Work
Looking at the software tools available today in the field of industrial robotics, they are
increasingly focusing on the simulation of automation concepts as a system integration
aid. Known simulation and planning software, such as Microsoft Robotics Studio [1],
Siemens Process Simulate [2], RoboLogix [3], or Webots [4], enable the design and
verification of robot applications in dynamic 3D environments and thus provide an
early detection of process-related issues. Also, approaches exist to work simultaneously
with these tools exist, e.g. the solution developed within the conexing research project
[5]. However, due to the increasing complexity of robot components, it is no longer
sufficient to carry out the design of a robot system solely based on simulation results.
The demand for design methodologies and concepts to provide the best practices of
reconfigurable robotic systems is becoming increasingly important in the industrial au-
tomation field [6]. The design process is often a poorly defined, complex and iterative
procedure, where the needs and specifications of the required artifact are not refined
until the design is almost completed [7]. Especially in this early product development
step, it is crucial, that designers are provided with an interactive and vision-oriented
tool, which supports in the decision-making process to build up reconfigurable robotic
3
automation solutions. Currently available tools (e.g. robolink, [8]), however, only in-
clude specific component segments. On the other hand, centralized, holistic, and pow-
erful platforms are required, that cover the entire product development process, from
design phase to virtual commissioning.
In summary, the current situation can be characterized by specialized solutions for
robot-based automation concepts from certain service providers. Furthermore, a trans-
fer of those concepts to other applications is limited. The elaboration of these solutions
is often carried out by intensive manual exchanges between providers and integrators.
To meet these challenges, the use of web-based technologies represents one of the most
powerful tools for sharing, pooling and distributing information between project’s team
members [9]. By using web-based platforms, it is possible to carry out a simultaneous
and collaborative design processes with an efficient transfer of knowledge between the
project partners [7]. In [10], the optimization of plant engineering and the efficient op-
eration of complex production facilities based on community systems, using knowledge
management techniques, were investigated. Other approaches regard a web-based
worker information system, where data streams from different controller databases are
coordinated and ergonomically presented to the operator [11, 12]. These projects have
shown that a web-based cockpit, which dynamically generates an overview of upcom-
ing tasks, has a positive effect on the interaction between automation systems and hu-
mans [13].
Currently available systems, as described, focus on different sub-areas regarding the
development and integration of robotics solutions. Either they focus on the simulation
of the final application or they provide configuration options for restricted component
areas with different levels of detail. Due to the interdisciplinarity of robotics it is nec-
essary to develop an overlapping ontology for the configurability of robots. The system
architecture defines the submodules, interfaces (APIs) and standards that are brought
together for a platform-compatible overall solution in the context of configuration.
3 Microservice architecture
During a lecture in 2006, the CTO of Amazon, Werner Vogels, spoke about small teams
that develop and operate services with their own databases. This was the first time that
microservices were mentioned [14]. Microservice, which does not have an official def-
inition, is a service-oriented architecture in which software is made up of small inde-
pendent services. These services are very loosely coupled, small and focused on a single
feature of the software [15]. There are four principles for the development of micro-
services. A service has only one task and can be programmed within two weeks. The
services work together and only universal interfaces may exist between them [14].
Often the system architecture concepts service-oriented architecture (SOA) and mi-
croservices architecture (MSA) are mixed up. Although both concepts have much in
common, there are some important differences. The biggest differences are in the de-
velopment of the database and the GUI. At microservices, each service has its own
database and an integrated GUI component. In contrast, at SOA the GUI is developed
independently of the services, a database can be used by several services and a central
4
orchestration of the services is needed [16]. There are also differences in the responsi-
bility of services. For example, only one team can be responsible for a service at mi-
croservices, but at SOA different teams can work on one service. This is one reason for
the possibility of an independent deployment of the services at microservices. However,
the entire system must be deployed at SOA. [14]
3.1 Advantages of microservices
Every distributed system also has some of the advantages of microservices. However,
microservices usually implement the concepts of distributed systems and service-ori-
ented architectures more consistently than any other system, so that the potential of
modular services is better used.
Fig. 1. A microservice approach represents a modern and scalable solution, with a sim-
ultaneous complexity reduction of the overall system [18].
Each system can be modularized to a certain degree. But experience shows that modu-
larization is very difficult to implement for a monolith because many dependencies ex-
ist in the software. A monolith is a large coherent program where all logic and data are
processed in a single database. To prevent dependencies, microservices rely on almost
complete autonomy of the services, as shown in figure 1.
Because of the modularization, each service can be independently scaled. Thus, the
entire system doesn’t need to be scaled if only one service is used more intensively.
This does not only simplify the system, but also can generate a decisive competitive
advantage. [14]
In contrast to monoliths, there is a technological freedom for each individual service
in the case of collaborative services of existing systems. This offers two major ad-
vantages. New technologies can be tested on a microservice without affecting other
services. In use, the potential of the technology can be better determined. The risk of a
State in Monolithic approach
State in microservices approach
stateless services with
separate stores
stateful
service
s
stateless
service
stateless
presentation
services
single
database
5
new technology is low because it can be exchanged at any time. The second major
advantage of the technological freedom is the ability to use the most suitable tool for
each task. Databases are the best example. For monoliths, it is necessary to use the same
database with the same properties for each task. However, it might be best to use dif-
ferent database types depending on the task. For example, a data store for documents is
the best database type to save messages between two users of a platform. However, this
is not suitable for linking friends where a graphical database should be used. Both da-
tabase types are therefore required for the creation of a social media platform. [16]
3.2 Architecture concept
Creating a microservice architecture it is necessary to divide the overall task into sub-
tasks (domain cut). The sub-tasks determine so-called macroservices, which should be
as independent as possible. Due to their high functionality, the macroservices must be
subdivided into further services until the corresponding microservice granularity is
reached. With this in mind, we have developed an architecture concept shown in figure
2.
Fig. 2. The minimum viable prototype macroservice architecture (green) for robot con-
figuration and additional services for the further development of microservices
6
Building component relations: This service is responsible for determining the possi-
ble composition of the individual components. For this, a graph-based database is nec-
essary, in which all components with possible relationships and restraints are listed.
This service is one of the minimum requirements of a robot configurator.
Best-practice solutions: The best solution for a scenario with fixed variables is shown
to the user. For example, a user would like to select the scenario “pick and place” with
a range of one meter and a specific gripping component. With the aid of the service
“best-practice solutions”, the most suitable components will be selected.
2D visualization: Icons are used to display the composition of the components to the
user. This is the last service, which is one of the minimum requirements.
3D visualization: This service will complement the tasks of 2D visualization. It visu-
alizes the scenario in 3D using for example WebGL.
Export service: Export service is responsible for exporting data. The data includes bill
of materials (BOM) lists in pdf or videos and images exported by the 3D visualization.
Robot simulation: With robot simulation, a path planning for the robots can be created.
This task also consists of further services like the manipulation of 3D objects, the cre-
ation of path locations and other applications.
Component provider: Service to provide a component’s information. The information
is described by using e.g. the AutomationML format. It may be used for storage and
exchange of robot planning data.
Sub-components: This service is mainly a database, which shows other possible com-
ponents to the selected components.
One-Stop-Shop: The one-stop-shop lists all the data about the components.
User-data: A dedicated service for managing the data of the users.
Rights management: Every user has specific rights, which control what content can
be seen, read or altered by him. These rights are managed by this service.
Payment system: High security is required for the payment. Therefore, the payment
system is usually outsourced to specialized companies. To ensure that the external
workers cannot change the source code, a service is also suitable here.
7
4 Robot configuration process based on microservices
One possible configuration process shown in figure 3 starts with the scenario query for
a required robot solution. This is one way to reduce the solution space and the com-
plexity. The various robot solutions with the greatest potential are presented in primary
categories, which are subdivided into further subcategories. By now, the user can select
between the primary categories “pick and place”, “packaging” and “palletizing” as well
as “quality control”.
The solution space “pick and place” is divided into the subcategories of component
placement and assembly. After the corresponding category has been selected, the con-
figuration process is started. A default scenario based on best-practice queries is pre-
sented to the user and can be defined in detail by means of partial configurators. If, for
example, the user selects the subcategory of machine feeding, first basic input parame-
ters are defined with the basic requests for the component weight, the necessary range
(distance), the positional accuracy, the height of the initial position, or the insertion
position. In addition, layout and CAD data (component, machinery, devices, etc.) make
it possible to further define the initial setup. Based on these inquiries concerning the
required concept of the application, first parts (robots, end effectors) of the robot overall
system are preconfigured. The next step, in the case of machine feeding, consists of the
partial configuration of the machine cell, which is specified by further inquiries regard-
ing the base area and the protective device. Further sub-configurations to be carried out
by the user (parts delivery, separation) ultimately lead to a specified basic solution of
the robot system and complete the basic configuration process.
Fig. 3. The configuration process guides the user iteratively trough individual robot
components and is implemented in a simple, structured and method-based approach.
8
The basic configurator offers a simple and fast overview of the most suitable automa-
tion solutions for the specific applications to the user. In addition, individual precon-
figured automation modules, such as a part feed, can be reused based on standard small
charge carriers. The modular design provides an intuitive user experience, which makes
robot solutions much easier to plan and to order with reduced effort. The preselection
of a potential solution generated in the configuration process can be shared with col-
leagues and system integrators simply via a web link, which promotes an internal and
external company collaboration.
5 Conclusion and Future Work
We presented an approach for an architecture concept and a domain cut to build up a
modular engineering and configuration platform for robotic automation systems. In the
space of the research project ROBOTOP we have to define the architecture and to struc-
ture the application as a set of loosely coupled services. It has the benefit to get devel-
opment easier understood, to make developers more productive, to start application
faster and speed up the developments.
The configuration of system instances requires standardizable and modularizable ro-
bot components. An architecture based on microservices offers a service-oriented ap-
proach that enables a modular design of task-specific services. However, microservices
go several steps further along with virtualized platforms and containers to create a hy-
brid service integration that replaces monolithic, single code base applications. The ar-
chitecture concept described in this paper was developed in a project-internal workshop
and defines the submodules required for a flexible, modular and scalable configuration
platform. The configuration of robot systems is based on the central best-practice ser-
vice, which ensures an accelerated design, reduced complexity and modular re-usabil-
ity. Future work will focus on the elaboration of the operating concept based on scien-
tific and psychological recommendations. The operating concept is intended to be a
structured approach to divide a complex configuration process into various, inter-
changeable modules. It is necessary to specify which processes can run serial and which
in parallel. In addition, methods for the user-specific, skill-based support of the config-
uration process will be developed.
6 Acknowledgments
The research and development project ROBOTOP is funded by the Federal Ministry of
Economic Affairs and Energy (BMWi). It is part of the technology program “PAICE
Digitale Technologien für die Wirtschaft” and is guided by the DLR Project Manage-
ment Agency “Information Technologies / Eelectromobility”, Cologne.
9
References
1. Jackson, J.: Microsoft Robotics Studio: A Technical Introduction. In: IEEE Robotics Auto-
mation Magazine (2007).
2. Siemens, “Process Simulate for Robotics and Automation”, URL: https://www.plm.automa-
tion.siemens.com, last visited: 07.09.2017.
3. LogixSim, “RoboLogix”, URL: https://www.logixsim.com/robologix.php, last visited:
07.09.2017.
4. Michel, O.: Webots: Professional Mobile Robot Simulation. In: International Journal of Ad-
vanced Robotic Systems, vol. 1, num. 1 (2004).
5. Bartelt, M., Kuhlenkötter, B. (Hg.): conexing Abschlussbericht. Werkzeug zur inter-
disziplinären Planung und produktbezogenen virtuellen Optimierung von automatisierten
Produktionssystemen. In: Bochumer Universitätsverlag Westdeutscher Universitätsverlag
(Maschinenbau, 10). DOI 10.12906/9783899667653 (2016)
6. Ferreira, P., Reyes V., Mestre, J.: A Web-Based Integration Procedure for the Development
of Reconfigurable Robotic Work-Cells. In: International Journal of Advanced Robotic Sys-
tems, vol. 10, num. 295, pp. 1-9 (2013).
7. Chandrasegaran, S., Ramani, K., Siriam, R., Horvath, I., Bernard, A., Harik, R., Gao, W.:
The evolution, challenges, and future of knowledge representation in product design sys-
tems. In: Computer Aided Design, vol. 45, pp. 204-228 (2013).
8. igus, “Robotik-Baukasten robolink”, URL: http://www.igus.de/robolink/roboter, las visited:
08.09.2017.
9. Eynard, B., Lienard, S., Charles, S., Odinot, A.: Web-based Collaborative Engineering Sup-
port System: Applications in Mechanical Design and Structural Analysis. In: Concurrent
Engineering: Research and Applications, vol. 13, num. 2, pp. 145-153 (2005).
10. Michl, M., Fischer, C., Merhof, J., Franke, J.: Comprehensive Support of Technical Diag-
nosis by Means of Web Technologies. Proceeding of the 7th DET, pp. 73-82 (2011).
11. Fischer, C., Bönig, J., Franke, J., Lusic, M., Hornfeck, R.: Worker information system to
support during complex and exhausting assembly of high-voltage harness. In: 5th Interna-
tional Electric Drives Production Conference: Proceedings. Piscataway, NY: IEEE, pp. 212-
128 (2015).
12. Fischer, C., Lusic, M., Bönig, J., Hornfeck, R., Franke, J.: Webbasierte Werkerinformati-
onssysteme: Datenaufbereitung und -darstellung für die Werkerführung im Global Cross
Enterprise Engineering. In: wt – Werkstatttechnik online, vol. 104, num. 9, pp. 581-585
(2014).
13. Kohl, J., Fleischmann, H., Franke, J.: Intelligent energy profiling for decentralized fault di-
agnosis of automated production systems. In: Green Factory Bavaria Colloquium (2015).
14. Wolff, E.: Microservices. Grundlagen flexibler Softwarearchitekturen. 1., korrigierter Nach-
druck. Heidelberg: dpunkt.verlag (2016).
15. Scholl, B., Swanson, T., Fernandez, D.: Microservices with Docker on Microsoft Azure.
Boston: Addison-Wesley (Addison-Wesley Microsoft technology series) (2016).
16. Bernhardt, S.: Microservices und SOA: Zwei Architektur Ansätze im Vergleich. In:
DOAG/SOUG News (04) (2015)
17. Newman, S.: Microservices. Konzeption und Design. Frechen: mitp. (2015)
18. Torre, C., Singh, D. K., Turecek, V.: Microsoft Azure – Azure Service Fabric and the Mi-
croservices Architecture, URL: https://msdn.microsoft.com/en-us/maga-
zine/mt595752.aspx, last visited: 05.10.2017