Content uploaded by Eike Wolfram Schäffer
Author content
All content in this area was uploaded by Eike Wolfram Schäffer on Aug 10, 2020
Content may be subject to copyright.
ScienceDirect
Available online at www.sciencedirect.com
Available online at www.sciencedirect.com
ScienceDirect
Procedia CIRP 00 (2017) 000–000
www.elsevier.com/locate/procedia
2212-8271 © 2017 The Authors. Published by Elsevier B.V.
Peer-review under responsibility of the scientific committee of the 28th C IRP Design Conference 2018.
28th CIRP Design Conference, May 2018, Nantes, France
A new methodology to analyze the functional and physical architecture of
existing products for an assembly oriented product family identification
Paul Stief *, Jean-Yves Dantan, Alain Etienne, Ali Siadat
École Nationale Supérieure d’Arts et Métiers, Arts et Métiers ParisTech, LCFC EA 4495, 4 Rue Augustin Fresnel, Metz 57078, France
* Corresponding author. Tel.: +33 3 87 37 54 30; E-mail address: paul.stief@ensam.eu
Abstract
In today’s business environment, the trend towards more product variety and customization is unbroken. Due to this development, the need of
agile and reconfigurable production systems emerged to cope with various products and product families. To design and optimize production
systems as well as to choose the optimal product matches, product analysis methods are needed. Indeed, most of the known methods aim to
analyze a product or one product family on the physical level. Different product families, however, may differ largely in terms of the number and
nature of components. This fact impedes an efficient comparison and choice of appropriate product family combinations for the production
system. A new methodology is proposed to analyze existing products in view of their functional and physical architecture. The aim is to cluster
these products in new assembly oriented product families for the optimization of existing assembly lines and the creation of future reconfigurable
assembly systems. Based on Datum Flow Chain, the physical structure of the products is analyzed. Functional subassemblies are identified, and
a functional analysis is performed. Moreover, a hybrid functional and physical architecture graph (HyFPAG) is the output which depicts the
similarity between product families by providing design support to both, production system planners and product designers. An illustrative
example of a nail-clipper is used to explain the proposed methodology. An industrial case study on two product families of steering columns of
thyssenkrupp Presta France is then carried out to give a first industrial evaluation of the proposed approach.
© 2017 The Authors. Published by Elsevier B.V.
Peer-review under responsibility of the scientific committee of the 28th CIRP Design Conference 2018.
Keywords: Assembly; Design method; Family identification
1. Introduction
Due to the fast development in the domain of
communication and an ongoing trend of digitization and
digitalization, manufacturing enterprises are facing important
challenges in today’s market environments: a continuing
tendency towards reduction of product development times and
shortened product lifecycles. In addition, there is an increasing
demand of customization, being at the same time in a global
competition with competitors all over the world. This trend,
which is inducing the development from macro to micro
markets, results in diminished lot sizes due to augmenting
product varieties (high-volume to low-volume production) [1].
To cope with this augmenting variety as well as to be able to
identify possible optimization potentials in the existing
production system, it is important to have a precise knowledge
of the product range and characteristics manufactured and/or
assembled in this system. In this context, the main challenge in
modelling and analysis is now not only to cope with single
products, a limited product range or existing product families,
but also to be able to analyze and to compare products to define
new product families. It can be observed that classical existing
product families are regrouped in function of clients or features.
However, assembly oriented product families are hardly to find.
On the product family level, products differ mainly in two
main characteristics: (i) the number of components and (ii) the
type of components (e.g. mechanical, electrical, electronical).
Classical methodologies considering mainly single products
or solitary, already existing product families analyze the
product structure on a physical level (components level) which
causes difficulties regarding an efficient definition and
comparison of different product families. Addressing this
Procedia CIRP 72 (2018) 310–315
2212-8271 © 2018 The Authors. Published by Elsevier B.V.
Peer-review under responsibility of the scientific committee of the 51st CIRP Conference on Manufacturing Systems.
10.1016/j.procir.2018.03.190
Available online at www.sciencedirect.com
ScienceDirect
Procedia CIRP 00 (2018) 000–000
www.elsevier.com/locate/procedia
2212-8271 © 2018 The Authors. Published by Elsevier B.V.
Peer-review under responsibility of the scientific committee of the 51st CIRP Conference on Manufacturing Systems.
51st CIRP Conference on Manufacturing Systems
Configurators as the basis for the transfer of knowledge and standardized
communication in the context of robotics
Eike Schäffera,*, Matthias Barteltb, Tobias Pownuka, Jan-Peter Schulzc, Bernd Kuhlenkötterb,
Jörg Frankea
aUniversity Erlangen-Nuremberg, Institute for Factory Automation and Production Systems (FAPS), Egerlandstr. 7, Erlangen,91058 Germany
bRuhr-Universität Bochum, Chair of Production Systems, Universitätsstr. 150, 44801 Bochum, Germany
cIcarus Consulting GmbH,Friedrich-Penseler-Straße 10, 21337 Lüneburg, Germany
* Corresponding author. Tel.: +49-9131-85-28314; fax: +49-9131-302825.E-mail address: Eike.Schaeffer@faps.fau.de
Abstract
Complex robot systems and intelligent automation concepts play a key role in manufacturing companies. Due to the required high level of
expertise in such systems, many robot automation solutions do not achieve a good economical cost-benefit ratio. In order to meet these
challenges, intuitive engineering platforms are urgently needed. In this paper, we present the evolution of such a platform, which we are
building in a modular way. By using a configuration module, best-practice automation solutions are modified in order to meet specific
requirements. With this, employees without special knowledge of robotics can achieve optimizedautomation solutions quickly.
©2018The Authors. Published by Elsevier B.V.
Peer-review under responsibility of the scientific committee of the 51st CIRP Conference on Manufacturing Systems.
Keywords: Robot-based Production Systems, Managemet of Knowledge, Configurator, Onion-View Model, AutomationML
1. Introduction
Robot-based production systems are a good meansof
automatizing tasks that are currently performed by hand.
However, the creation of such systems is complex due to
various options,which must be taken into account. In order to
simplify the creation process and to reduce errors, simulation-
systems up to a virtual commissioning are used. With these
tools, problems can be identified and prevented in the virtual
world and the commissioning of the planned automation
system becomes smooth.Unfortunately, the complexity of this
virtual planning as well as the high costs of maintaining
suitable software prevent small and medium-sized enterprises
(SME) to benefit from these advantages.A continuous robotic
simulation, smart standardization, and the reduction of the
tools’ functions to the specified application by guiding the user
through the process are crucial developments in order to reduce
the costs for creating robot-based production systems and to
enable non-skilled users to use corresponding planning and
simulating methods.
2. State of the art
The planning and simulation of robot-based production
systems is affected by a rapid development of the
corresponding tools. Especially from the point of view of an
unexperienced user, the tools exhibit a high complexity,they
are not easy to use, and the process of creating appropriate
simulations is not straightforward. Commonly, these
challenges are summed up in the keywords volatility,
uncertainty,complexity, and ambiguity, which are abbreviated
by the acronym VUCA [1].As a result, many tasks are
automatized with a high effort or they are not automatized at
all. For this fact, we can identify two main reasons: too
complex technical systems and missing knowledge.
Amongst others, the transition to a flexible production, an
increasing number of variants, and an increasing amount of
product functions as well as production technologies are main
reasons for the increasing complexity of technical systems. In
particular, for the planning of robotics solutions, a
Eike Schäffer et al. / Procedia CIRP 72 (2018) 310–315 311
2Author name / Procedia CIRP 00 (2018) 000–000
comprehensive technical and interdisciplinary expertise is
necessary in order to utilize the required technologies, e.g.
sensors, image recognition, mechanics, end-effectors, and
simulation. Due to the large number of different technology
providers, the market offers a broad range of peripheral
components and a different range of solutions in the field of
robot systems. In fact, standards for interoperability gain
acceptance very slowly because manufacturers only partially
support them for strategic reasons,e.g. to keep the entry
barriers for new competitors as high as possible and not to be
easily replaced by cheaper competitors. For these reasons,
customerssuffer a high expense in terms of costs and time in
order to obtain anoverview of optimized automation solutions
quickly.
The second reason for the high effort that is currently
required in order to create automatized solutions is missing
knowledge. Especially for small and medium-sized enterprises
(SME), the development of the most suitable, reusable,
customizable,and scalable automation solutions causes
extremely high expenses for the engineering processes [2].
However, due to the high cost pressure in production, fast
realizable and cheap solutions are often preferred. Scalable and
in the long term cheaper solutions would require a high
development effort, a high degree of different expertise,and a
good coordination between the experts. With respect to
currently builtsolutions, many compromises and tradeoffs
(technical debt) are received between the exploration of new
knowledge and exploitation of the current knowledge. A
limited learning effect, an insufficient management of
knowledge and less scalable modules are major drawbacks of
this approach.
In the context of management of knowledge, documenting
is an important requirement in order to shape effectively the
learning ability and future viability of a company in the age of
digitalization.However, the preparation of a standardized,
comprehensive and understandable meta information in the
form of documentation enriched with examples usually
dependson the personal commitment and the knowledge on
how to prepare the information e.g. in the form of graphical
visualizations of the individual employees. Missing time for
documentation, a limited standardization in the documentation
process, and an insufficient automation of the documentation
with process-tools are preventing an efficient management of
knowledge,which is practicable in day-to-day business. For
example, anunstructured text-input leads to very
heterogeneous documentation results compared to a dropdown
selection.
Furthermore, the storage of information is usually realized
in form of folder structures, Wikis or in documents such as
Word, Excel,or PDF files [3].The manual transfer of text-
based information into the appropriate development tools,
which is carried out by employees, has its limitations and, in
addition, has a negative impact on its acceptance and
motivation [3,4]. A solution to overcome this issue are
recommendations, as practiced e.g. at Amazon (“customers
who bought this item also bought”) [5]. However, this approach
is currently not feasible in the domain of planning of production
systems due to the architecture of the utilized software-tools. A
lack of knowledge culture in companies reinforces this trend
through competition between the individual production plants
of a company or the individual SME.The lack of knowledge-
management results from a culture of work where knowledge-
exchange is not rewarded, but rather represents additional
expenses for the individual participants.Therefore, many
learning experiences are made multiple times, resulting in
higher costs for the market and the end-users. Even though,
user can be motivated to create documentations, e.g. by
utilizing a service platform where knowledge can be sold to
other users [6].
3. A modular configuration platform for robotic solutions
in the context of knowledge-management
Actually,a single software-tool cannot solve theproblem of
toocomplex systems and missing management of knowledge.
Instead, an overarching platform is required, which provides
holistic information usage in the context of planning of robotic
production systems. However, currently available production
planning systems (e.g. Siemens Process Simulate [7]), do not
provide sufficient configuration functionalities. In order to
meet the mentioned challenges, we develop a modular platform
for planning, configuration and simulation of robot-based
systems within the research project ROBOTOP.While the
platform integrates a sophisticated management of knowledge,
the corresponding user is guided by an online assistant,using a
minimalistic front-end that displays only one process-step at a
time. The complexity of an entire robotics solution splitsinto
many small tasks such as layout selection, gripper selection, or
delivery. By solving these single tasks, users can create task
descriptions, select components, and build robot-based
solutions for the specified task.
3.1. Configurators in the context of knowledge-based
engineering and digitization
The right configuration of an automatized solution has a
significant impact on the quality,the costs,and the cycle-time.
A meansto achieve the best configuration simply is
knowledge-management by reproducing or adapting existing
learning effects instead of creating new ones. By utilizing
knowledge-management, learning effectscan be integrated in
order to gain knowledge. As a result, corresponding
configurators improve continuously.Thus, configurators
significantly affect the economic success of an industrial
company. They savethe process knowledge, makeknowledge
accessible and enablea practicable use and further
development of the knowledge.
The proper selection of automation solutions is dependent
on the experience and specific knowledge of the respective
developer. The development tasks, which are often formally
unclearly defined, must therefore be solved in multi-level,
inconsistent, time-and communication-intensive knowledge
transfer between several experts [8].The provision of a
collaborative development simplifies this process.
Product configuration systems are established in the
consumer field as extremely effective tools to align individual
customer requirements with available product offerings. These
312 Eike Schäffer et al. / Procedia CIRP 72 (2018) 310–315
Author name / Procedia CIRP 00 (2018) 000–000 3
configurators, which are primarily used as a tool of mass
customization in the context of the "configure-to-order" (CTO)
model, can also be considered as knowledge management
systems [9]. In the configuration process, it is the customer's
knowledge that ultimately leads to the aggregated product by
selecting and configuring predefined attributes. However, the
complex configuration of robotic solutions takes place within
the framework of the engineer-to-order (ETO) model. In order
to reduce the planning complexity, we are using pre-configured
best-practice automation solutions. Configurators reduce entry
barriers for inexperienced users by reducing transaction costs.
Transaction costs can be e.g. the time required to obtain,
standardize, evaluate and structure information from numerous
sources and to check the final selection for completeness and
consistency. A technically adept employee should be able to
quickly and easily obtain an overview and, above all, necessary
knowledge about potential solutions, without any special
knowledge of robotics. By storing the configured variants, they
share along colleagues and experts in a community. The
models CTO and ETO link together by integrating a robotic
configurator into the development process, which takes
complexity from the development projects in automation
technology.
3.2. The onion-view model for software engineering
As part of the development of complex software systems,
the design of the software architecture, which mapsthe
structure of the overall system, is one of the central challenges
in software engineering. In addition to a detailed and solution-
oriented requirement analysis, the use of suitable structured
methods and models for software architecture development
were proven useful [10,11].Various reusable approaches and
process models at different levels of abstraction are available.
Examples can be found in [12,13].In order todevelop the
software architecture of the configuration platform presented in
this paper, we postulate the approach of the so-called onion-
view model. This model is a method that helps to show
different layers of a system in order to allow the assignment of
classes or modules while designing complex architectures with
different experts.As a feature, the onion-view model that has
its origins in the field of social sciences [15] supports the 4 + 1-
view model [14],which is used successfully in software
engineering. In the context of architecture development, the
onion-view model shows the cyclical course of the aggregation
of knowledge as well as the learning effect over time on
different views (Fig. 1). For the development of the software
architecture, we have divided the onion-view model into three
layers.Fig. 2depicts the three layers, from the physical layer
in the outer shell, the digital layer, to the meta-layer in the inner
shell.
The physical layer is characterized by a completely
perceptible and understandable physical view with a high
degree of complexity, e.g. real robotic solutions whose
behavior can be directly observed, recorded and evaluated by
humans.
The digital layer can only be perceived by humans using
appropriate human machine interfaces (HMI) and consists of
e.g. digital programs or software-tools in combination with a
computer or tablet.The layer serves as interface to humans,e.g.
via an HMI,and bridges the gap between physical and meta-
sight,e.g. with a 3D-scene created from the meta-information
enriched with real physical values like sensor measurements.
The digital layer is particularly responsible for simplifying
complex contexts in order to make the applications and models
more manageable by the user. Possible approaches are
reduction of information, control of processes,creating
simplified views, focusing on the essential information, and
leading the user through a certain task.
The meta-layer includes abstract information, i.e. semantic
definitions and models. E.g., component or simulation models
are defined in the meta-layer. The digital layer can utilize the
models in order to create corresponding entities that resists in
Fig.
1. The onion-view model for the development of software architectures.
The processes are divided by the Onion-Views: The cyclical
progression shows the aggregation of knowledge
and the learning effect over time.
Specialist
Views
•Development
•Engineering
•Operation
•Maintenance
•Marketing
•Controlling
• etc.
Learning and understanding needs
Modelling architectures and
universal solutions e.g. based on
mathematical models,
meta models and others.
Fig.
2. Information and knowledge clustering through physical, digital and
meta
-perspective.
Onion-View Model
Physical-View
Real robot ic plant s can be viewed and
examined by human beings . Features :
Recording of many individual data and
data sets. Evaluation of meta-models
f or practic ability .
Feedback f or modelling.
Digital-View
Allows the physi cal vi ew and meta
view to communicate v ia a us er
interf ace and making models and data
visible and comprehensible in the
representat ion by conf igurators,
simulations, v ideos, images , audio, etc .
Complex interrelationships can be
easily identified.
Meta-View
The underlying meta models,
ontology , f ormulas and relat ional
knowledge/graphs can be aggregated
f rom indiv idual dataset s and ev aluated
in practice. Scalability, possible
functionalityand reliabilityof
predictions depend heav ily on the
quality of the models.
Increasing compl exity through higher information density
Digital execut ables, sof tware for t he
perception is only indirectly
possible v ia a user interface:
Meta information,dat a, models ,
knowledge is required
f or additional understanding:
Representat ion of
knowledge and
information:
Physical ob jects, e. g. real
manuf acturing f acilit ies and real
component s, can only be perceived
directly v ia the human senses:
Percei ving and understanding is
enabled through
increas ingly
better k nowledge-and/ or s oftware-tools .
Logical vi ew
Scenarios
Development view
Process view Physical vi ew
Ontolog y
<OWL/>
<RDF/>
<AutomationML/>
<X ML / >
{JS ON }
Eike Schäffer et al. / Procedia CIRP 72 (2018) 310–315 313
4Author name / Procedia CIRP 00 (2018) 000–000
the digital layer. The meta-layer with its data models,
ontologies, formulas, datasets, etc. is the main requirement for
the quality of practicability,the user-feedback about modeling,
and simplified leading through the processes.
4. Meta-layer andthe flow of information
By using the platform, customers can work in the digital
layer in order to create a robotic-based system suitable for the
customers’ needs. However, there are two kindsof models
involved within this process, which both lay in the meta-layer:
the component-model and the meta-model.
The first kind of model describesspecific components or a
combination of components, respectively. As a combination of
components can be considered as a more complex component,
this model is called the component-model. This model reflects
our view of the real world, in which we can build specific parts
and combine them to parts that are more complex. Thus, by
combining components to more complex systems e.g. a
production system can be built.A model of a single component
includes a geometrical representation, information about the
kinematical structure, physical parameters like mass or size,
and additional information, e.g. its order-number. With a
complete definition, the model is a virtual counterpart of a real
component.
The second kind of model is a meta-model for components.
A meta-model does not define a specific component but it
describes how to create one. The meta-model contains a build-
pattern for components. E.g.,a meta-model for a 2-finger
grasping module contains the information that there is a flange
as well as two grasping points (one for each finger). In addition,
the grasping module must have some signal to control the
finger position. In addition, the meta-model declares certain
necessary parameters, e.g. the grasping force or the closing
speed. By using the meta-model, the specified information can
be filled in order to create a specific component-model of the
first kind.
Even though the meta-layer includes more models, the
component-model and the meta-model are essential for several
services in the digital-layer, e.g. the configuration, the
simulation, or the ordering of components. However, a
component-model will always derive from a meta-model,
while the meta-models will create a hierarchical structure: the
2-finger grasping module model will derive from a grasping
module. The grasping module model will derive from a generic
end-effector model, and so on. Information of parental models
are inherited in order to keep compatibility, i.e. a 2-finger-
grasping module is always a grasping module.
4.1. Best-practice definitions
As described above, several component-models can
combine to a model of a more complex component. E.g.,
mechanical parts, electronic parts as well as a pneumatic
actuator can combined to a spot welding tool. However, not
only complex components but also complete production
systems can be created by this means. The motional sequence
of these production systemscan then be simulated and
modified. Afterwards, a corresponding order can be placed in
order to buy the production system.
A main issue of this workflow is the missing knowledge to
combine components to a production system suitable to solve
a given production problem. In order to overcome this issue of
missing knowledge, we are using best-practice definitions that
will comprehend the required knowledge. A main feature of
these best-practice definitions is the possibility to use both,
component-models as well as meta-models, to create a project
that describes a prototype of a production system. As an
example, a best-practice definition of a pick and place problem
would include an industrial robot as well as a grasping tool. The
specific kind of the robot or the grasping tool is not defined yet.
However, as soon as a user specifies the required parameters
(i.e. pick and place position and the mass of the workpiece)
appropriate component-models replace the meta-models within
the best-practice definition.
4.2. Relationship to the digital layer
Fig. 3depicts the relationship of the described models in the
meta-layer and the digital-layer. By using the meta-models,
virtual components can be created and stored in a database. A
corresponding service in the digital-layer createsand modifies
them. By using this component-service, digital twins of real
components can be created, which then can be utilized within
specific user projects. User projects themselves are created by
using a configurator service. This configurator will firstly
acquire information of the users’ process. With this, an
appropriate best-practice definition will be selected and
substantiated with the user-individual inputs. This will yield to
a project with a full-functional proposal of a production system
able to solve the automation problem specified by the user. A
simulation service can then be used to visualize and modify the
received project. Finally, subsequent processes like an order
process can be triggered.
Fig.
3. Sketch of the flow of information in order to build a robot-based
production system. By using a configurator, a project which contains a
proposal of a production system gets created. Before placing the order, the
system can be simulated and modified.
314 Eike Schäffer et al. / Procedia CIRP 72 (2018) 310–315
Author name / Procedia CIRP 00 (2018) 000–000 5
4.3. Transition from the meta layer to the digital layer
In order to enable services and tools persisting in the digital
layer to work with the models within the meta-layer we need
the possibility to exchange information between both layers.
Commonly, this is done by utilizing a certain exchange format.
However, there are different concepts involved in the model-
definitions,which an exchange format must comply with. An
XML-based format, which is able to meet our requirements, is
the so called AutomationML standard [16]. The standard
supports the description of topologies and the classification of
objects by specifying different roles. Additionally, objects can
be supplied by interfaces, which allow a connection to other
objects as well as external resources. With this, we can create
meta-models for components. As depicted in Listing 1, meta-
models derive from other meta-models in order to build a
hierarchy of meta-models with different levelsof
specialization. Not shown in the listing are required attributes
and interfaces. However, we can define that e.g. an end-effector
has a geometry interface as well as a flange interface. A gripper
that derivesfrom the end-effector role requires a grasping
signal in addition to the geometry and flange interfaces.
By utilizing the defined roles, we can create best-practice
solutions as depicted inListing 2. The shown example required
two items, one able to grab an object (the Gripper role) and one
able to move the object around (the Manipulator role).
However,the specific kind of utilized manipulator or gripper is
not important.
In addition, component-models can derive from a specific
role. E.g.,a specific gripper module available on the market can
inherit the Gripper or the more specific Pneumatic Gripper role
in order to create a component-model of the corresponding
product. In order to create a certain project based on a best-
practice solution, the available component-models can be
filtered in order to receive a list of suitable components. Listing
3shows an example of such a project. For both items defined
within the best-practice solution, appropriate components are
used. As it can be seen, the gripper has a more specific role than
the best-practice solution requires, which still yield to a proper
solution.
5. Acquiring and transferring knowledge
A main aim of the meta-layer is the construction of a model
of a production system which is suitable to solve a given
automation problem. While the meta-layer defines models used
to describe different levels of development progress, the digital
layer is responsible for modifying and improving the
corresponding models. For this, three main services are
involved: the component service, the configurator, and the
simulation service. However, by using the AutomationML
standard, we can achieve a digital model that any provided
service can process.
The component service gathersinformation about real
components. By utilizing the component-models of the meta-
layer, this service creates and modifies digital counterparts of
the real components. Interaction with the service is possible
either automatically via a programming interface or manually
by a web-based user interface. Furthermore, the service
provides functionalities to validate and sign digital components
in order to achieve an error-free and secure usage in other
services. To make real components usable for planning and
simulation, this service is the main entry-point.
The configuration assistant providesusers an interface to
bridge the gap between the physical and the meta-sight, as
discussed in section 3.2. The configuration assistant aims to
provide potential users with a knowledge-based system. In the
context of product development processes, a distinction can be
made between direct, indirect and automatic knowledge
acquisition [17]. The configuration assistant acts as a self-
learning system and represents a tool for automatic knowledge
acquisition, where expert support is not required. The
configuration assistant shown in Fig. 4structuresvarious robot
solutions in primary categories, which are subdivided into
further subcategories. The solution space “pick and place”, for
example, is divided into subcategories of component placement
and assembly. Best-practice solutions embed the engineering
Listing 1: Simplified AutomationML snipped of different roles defining
meta-models of components.
<RoleClass Name="Manipulator">
<RoleClass Name="Robot" RefBaseClassPath="…/Manipulator" />
</RoleClass>
<RoleClass Name="End-Effector">
<RoleClass Name="Gripper" RefBaseClassPath="…/End-Effector">
<RoleClass Name="Pneumatic Gripper" RefBaseClassPath="…/Gripper" />
<RoleClass Name="Sucction Gripper" RefBaseClassPath="…/Gripper" />
</RoleClass>
<RoleClass Name="Grinder" RefBaseClassPath="…/End-Effector" />
</RoleClass>
Listing 2: Simplified AutomationML snipped defining a best-practice
solution.
<SystemUnitClass Name="Pick'n'Place">
<SystemUnitClass Name="Handling Device">
<SupportedRoleClass RefRoleClassPath="…/Manipulator" />
</SystemUnitClass>
<SystemUnitClass Name="Tool">
<SupportedRoleClass RefRoleClassPath="…/Gripper" />
</SystemUnitClass>
</SystemUnitClass>
Fig.
4. A simple, structured and method-based approach for the configuration
process which guides the user iteratively trou
gh individual robot components.
Listing 3: Simplified AutomationML snipped of a specific project.
<InternalElement Name="Handling Project"
RefBaseSystemUnitPath="…/Pick'n'Place" >
<InternalElement Name="IRB 120" RefBaseSystemUnitPath="…/IRB 120" >
<SupportedRoleClass RefRoleClassPath="…/Robot" />
</InternalElement>
<InternalElement Name="PGN+64" RefBaseSystemUnitPath="…/PGN+64" >
<SupportedRoleClass RefRoleClassPath="…/Pneumatic Gripper" />
</InternalElement>
</InternalElement>
Eike Schäffer et al. / Procedia CIRP 72 (2018) 310–315 315
6Author name / Procedia CIRP 00 (2018) 000–000
knowledge. Based on the inquiries concerning the required
concept of the automation solution, apotential robot system
derivesfrom preconfigured best-practice component groups. In
addition, by integrating further knowledge carriers (e.g. layout,
CAD data for components, machinery, etc.) the user gains more
and more understanding of the specific robot solution.
Furthermore, there is the possibility to share generated problem
solutions with colleagues and system integrators for knowledge
transfer. The configuration assistant thus acts as a knowledge-
based engineering tool, which promotes an internal and
external company collaboration.
The simulation service is the main service to visualize and
modify the current state of the planning of the desired robotic-
based production systems. Using commonly available tools,
this is a very complex task. Thus, the service demonstrates two
aspects in the context of configurators and management of
knowledge: the transfer of knowledge and the simplifying of
complex contents to the user. While working on the digital
production system, this system becomesmore detailed and it
improvessuccessively. However, corresponding knowledge
required to improve the digital model is already included within
the simulation service. While using the service, available
knowledge transfers from the service to the model. Available
tools to simulate production systems are mostly designed for
appropriate experts. Unexperienced users are not able to use
them efficiently. Thus, the simulation service must reduce this
complexity in order to enable also unexperienced users to
utilize them. By using state-of-the-art technologies, i.e. an
online-based user interface, the ROBOTOP research project
aim at both the transfer of knowledge and the simplifying of
tools’ complexity. With a smooth communication, users can
modify and simulate the current status of the planned
production system. The user interface has a context-related
view and presents only those functionalities to the user,which
are required for the current task.
6. Evaluation
In project-internal workshops as well as in discussion with
industrial experts we evolved the definition of the described
models, concept,and requirements. Based on a user-centered
design, we developed first demonstrators in the shape of a
software-mockup. While target users are working with the
mockup, we have evaluated our approach. In addition, we can
identify the skills and needs of the users in a very early stage of
the research project. When the mockup expands with more
functionalities, users become more and more integrated for
testing and evaluation. In particular,the user-oriented design of
the system as well as the system-internal processes and process
flows are examined. Supported bycontinues evaluating the
user tests, further methods for user-specific and skill-based
support of the configuration process will be developed.
7. Conclusion and future work
In order to gain the application in robotic production
systems, we have proposed an online platform for planning and
simulation of corresponding systems. The platform integrates a
sophisticated knowledge-management and provides an easy to
use web-based interface. The different abstraction layers
classify components and production systems yielding to a high
reusability. Within future work, we will proceed with the
implementation of the concept.In addition,future
developments consider security related aspects like e.g.
authentication.
Acknowledgements
The Federal Ministry of Economic Affairs and Energy
(BMWi) fund the research and development project
ROBOTOP. It is part of the technology program “PAICE
Digitale Technologien für die Wirtschaft” and is guided by the
DLR Project Management Agency “Information Technologies
/ Electromobility”, Cologne.
References
[1] Uden L, Lu W, Ting I-H, (Eds.) (2017) Knowledge Management in
Organizations: 12th International Conference, KMO 2017, Beijing,
China, August 21-24, 2017, Proceedings, pp. 239-253.
[2] Jackson, M., Hedelind, M., Hellström, E., Granlund, A., Friedler, N.
(2011) Lean Automation: Requirements and solutions for efficient use
of robot automation in the swedish manufacturing industry.
International Journal of Engineering Research and Innovation:36–43.
[3] Götz, A., Donges, C. Automatisierter Übergang vom dokumenten-zum
modell-zentrierten Requirements Engineering als Ausgangsbasis für
MBSE. Tag des Systems Engineering 2016, pp. 301–310.
[4] Huckriede, V., Joachim, B., Storck, S. Systems Engineering im
Maschinen-und Anlagenbau verstehen, anwenden und beherrschen. Tag
des Systems Engineering 2016, pp. 151–160.
[5] Bagher RC, Hassanpour H, Mashayekhi H (2017) User trends modeling
for a content-based recommender system. Expert Systems with
Applications 87:209–19.
[6] Soto-Acosta P, Popa S, Palacios-Marqués D (2017) Social web
knowledge sharing and innovation performance in knowledge-intensive
manufacturing SMEs. J Technol Transf 42(2):425–40.
[7] Siemens Process Simulate for Robotics and Automation. Siemens.
[8] Chandrasegaran SK, Ramani K, Sriram RD, Horváth I, Bernard A,
Harik RF, Gao W (2013) The evolution, challenges, and future of
knowledge representation in product design systems. Computer-Aided
Design 45(2):204–28.
[9] Zheng P, Xu X, Yu S, Liu C (2017) Personalized product configuration
framework in an adaptable open architecture product platform. Journal
of Manufacturing Systems 43:422–35.
[10] Kruchten P (2007) The rational unified process: An introduction. 3rd ed.
Addison-Wesley, Upper Saddler River, NJ.
[11] Hofmeister C, Nord R, Soni D (2006) Applied software architecture.
Addison-Wesley, Reading, Mass.
[12] Jansen A, Bosch J (2005) Software Architecture as a Set of
Architectural Design Decisions. 5th Working IEEE/IFIP Conference on
Software Architecture (WICSA'05), pp. 109–120.
[13] Allen R, Garlan D (1997) A formal basis for architectural connection.
ACM Trans. Softw. Eng. Methodol. 6(3):213–49.
[14] Kruchten P Architectural Blueprints -The "4+1" View Model of
Sotware Architecture. IEEE Software 12 (6) 1995:42–50.
[15] Alexander I, Robertson S (2004) Requirements -Understanding project
sociology by modeling stakeholders. IEEE Softw. 21(1):23–7.
[16] International Electrotechnical Commission (IEC) (2014) Engineering
data exchange format for use in industrial automation systems
engineering -Automation markup language -Part 1: Architecture and
general requirements(IEC 62714-1:2014).
[17] Brandmeier M, Bogner E, Brossog M, Franke J (2016) Product Design
Improvement Through Knowledge Feedback of Cyber-physical
Systems. Procedia CIRP 50:186–91.
[18] Klein R (2000) Towards an Integration of Engineering Knowledge
Management and Knowledge Based Engineering. Journal for
Manufacturing Science and Production 3(2-4).