<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Adaptive Autonomous Machines - Requirements and Challenges</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Lothar Hotz</string-name>
          <email>hotz@informatik.uni-hamburg.de</email>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Stephanie von Riegen</string-name>
          <email>stephanie.von.riegen@informatik.uni-hamburg.de</email>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Rainer Herzog</string-name>
          <email>herzog@informatik.uni-</email>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Matthias Riebisch</string-name>
          <email>riebisch@informatik.uni-</email>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Markus Kiele-Dunsche</string-name>
          <email>Markus.Kiele-Dunsche@lenze.com</email>
        </contrib>
      </contrib-group>
      <abstract>
        <p>In mechanical and plant engineering, the general challenge is to achieve flexibility in order to process changes in the requirements or operating conditions of a machine on the site of the plant operator. Changes to the machine and its configuration require the operator to work together with the machine builder (or plant constructor for several machines) and, if necessary, with his suppliers, which requires time and effort due to communication and delivery routes. Hence, an autonomous acting machine or component that deal with needed changes through automatically triggered adaptations would facilitate this process. In this paper, subtasks for constructing autonomous adaptive machines are identified and discussed. The underlying assumption is that changes of machines and components can be supported through configuration technologies because those handle variability and supply automatic derivation methods for computing needed changes in terms of machine and component updates.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>INTRODUCTION</title>
      <p>In recent years, the demand for the industrial production of small
quantities has increased steadily. Whereas in the past larger industrial
plants were designed for the production of large quantities of exactly
one product whose parameters did not change, today the possibility
of fast, flexible adaptation to changes in product lines is becoming
increasingly important. While an adjustment of the machine settings is
often sufficient for minor changes, larger adjustments require a
modification of a machine by the machine manufacturer, or even changes
of a complete production plant. For this purpose, the dependencies of
individual plant components must be taken into account, e.g., the use
of a stronger motor at one point would possibly also require the use
of a drive shaft that can withstand higher torques. If individual plant
modules can be configured to give a higher or lower speed, instead
of a higher throughput other modules could be enabled to achieve a
higher accuracy.</p>
      <p>In this paper, we present first considerations for enabling machines
or components to themselves start adaptations of their configurations.
Firstly, we discuss the current process in plant engineering for
adapting machines (Section 2). In Section 3, we provide an illustrating
example and in Section 4, we present our concept for autonomous
adapting machines and in Section 5, we discuss main challenges for
realizing such machines, especially in respect to configuration tasks
such as reconfiguration.
2</p>
    </sec>
    <sec id="sec-2">
      <title>CURRENT SITUATION IN PLANT</title>
    </sec>
    <sec id="sec-3">
      <title>ENGINEERING</title>
      <p>
        The component manufacturer has developed products whose
product features can be configured in a variety of ways to cover a wide
range of missions [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ]. For a power unit, such product characteristics
are: Torque, rotary speed, type of sensors, type of actuator,
mechanical interfaces, electrical interfaces, control characteristics, functional
characteristics, but also something basic like color. These have to
be considered as drive systems, which in some cases have to be
understood as poly systems, since there are central components, such
as the power supply, or a controller, which specifies a coordinated
movement, such as in robot kinematics.
      </p>
      <p>The interactions between the power unit components of a drive
axle or a drive system, starting with the connection to the control
system up to the driven components or the mechanics, can be very
extensive, so that the machine builder is dependent on the knowledge
of the component or solution supplier. The development of suitable
drive solutions is therefore usually carried out in close cooperation
these days. On the other hand, machine builders want to reuse their
developed results wherever possible, which forces them to
modularize their machine solutions. Machine modules are then defined which
combine one or more drive axes or drive systems.</p>
      <p>A general overview of the current plant engineering process is
given in Figure 1. After the mission and the classification of the
client’s requirements, a concept is created that may include
existing solutions. Requirements for such solutions can be functional
(movements, production steps) and constructive characteristics
(dimensions, interfaces such as connecting elements etc.). When
deciding on a solution, various aspects have to be taken into account. Some
lead to severe restrictions, others are free, and still others have
consequences for other solutions or components. If automation or partial
solutions are available (selction of partial or automation solutions),
these can be integrated into a machine solution. Integration refers to
function, design, parameterization, wiring, but also to organizational
issues such as spare parts inventory and documentation. The planned
mechanical design can be verified by means of a simulation
(simulation). Once a decision has been made on an overall solution, the
electrical, pneumatic and hydraulic design (construction) is carried out.</p>
      <p>This is incorporated into the development of machine control and
operation and can be put into operation virtually (virtual
commissioning). After the customer has placed his order (order and logistics) on
the designed solution, the montage and initial commissioning with
Copyright © 2019 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
selection of
automation
solution
simulation
mechanical</p>
      <p>design
selection of
partial solutions
virtual commissioning
order &amp; logistics
decision
about
overall solution
construction
development of machine control and operation system
the commissioned construction and machine control and operation
will take place. The process concludes with customer acceptance.
3</p>
    </sec>
    <sec id="sec-4">
      <title>EXAMPLE FOR AN AUTONOMOUS AGENT</title>
      <p>Our goal is to deliver not only a machine (consisting of several
components) or a component to a customer, but also so-called
autonomous agents. These have the task of monitoring the
machine/component and adapting it to requirement changes. The
machine/component together with the autonomous agent forms the
autonomous adapting machine. If changes are made in the machine,
the autonomous agent also changes the description of the machine.
The agent can be regarded as an IT system for changing the machine,
whereby the agent, i.e. the IT system, also adapts itself dynamically.</p>
      <p>Figure 2 shows the interaction of the autonomous agent with the
machine and its environment in a scenario with independent
adaptation to new or changed requirements, where only one agent and one
machine are shown.</p>
      <p>Since configuring a plant is a common example that illustrates
configuration processes, the following are examples of the
individual elements in Figure 2 based on a plant engineering configuration.
In addition to the main components (drive unit, fan, running gear,
rack feeder, sensor, picker arm, etc.), a classic plant can have fans
for cooling the internal case temperature or individual components.
We assume that a plant is already configured in a certain way (B) to
solve a certain task (A). Using sensors, an autonomous agent could
now determine that the system load is slightly higher than 1, which
means that the plant is slightly overloaded (C1). An internal list of
suitable components (C2) could show that it is possible to replace
the drive unit with a more powerful model. However, we assume that
the drive unit delivers weaker performance than possible due to
overheating. Since this information is also made available via sensors
(C1) to the agent, he will decide (C3) to optimize the cooling instead
of changing the drive unit. Since the installed fans already deliver
the full performance, a solution could be to install another fan, as
far as the case offers this possibility, which would also be ensured
by checking (C2). Alternatively, the manufacturer could also offer
an improved fan with higher cooling capacity (E), which would
replace an installed one. While monitoring (D) ensures that changes to
a plant do not adversely affect plants placed nearby, virtual
verification (C4) will check whether the improved cooling capacity will be
sufficient even under summer factory workshop temperatures and if
proper cooling is sufficient to lower the system load below 1.
Adaptation planning (C5) means determining that shutting down the plant is
necessary for the given changes and could also determine the optimal
time to do so. Both virtual verification (C4) and adaptation planning
(C5) are monitored and accompanied by human experts. Finally, the
change must be made (C6), which then changes the system properties
(B).
4</p>
    </sec>
    <sec id="sec-5">
      <title>GENERAL CONCEPT FOR AUTONOMOUS</title>
    </sec>
    <sec id="sec-6">
      <title>ADAPTING MACHINES</title>
      <p>
        We expect that the machine is accompanied by a complete
description of the currently installed (probably parameterized) components,
the configuration. The configuration is an instance of a
configuration model. The configuration model is given in machine-readable,
semantically interpretable form [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ]. It represents the variants of
system components as well as mappings between external parameters
describing requirements and components realizing those.
Additionally to this configuration model a here called action model describes
how the agent can acquire new requirements in the productive
environment. This happens on the one hand by sensors, which seize
the environment (e.g., pressure, temperature), on the other hand, by
accesses to other systems in the productive environment (like for
example other machines and the development system with the
machinebuilder). Adaptation now is defined by changing the configuration
and the actual system, the machine. Changes in turn can be
parameter changes, additional components, or component replacements.
      </p>
      <p>The requirements are continuously determined and compared with
the external system parameters of the current machine. This is used
to determine which properties, parameters or functions are not
fulfilled by the current configuration or solution (C1 in Figure 2). If
the boundary conditions of the environment or process parameters
change during system operation so that requirements are no longer
fulfilled, the autonomous agent becomes active in the same way as
when requirements are changed in order to achieve fulfillment of the
requirements by changing parameters, configuration or solution
elerequirements
machine incl. product
lifecycle management
autonomous agent for machine
ments.</p>
      <p>The models will be delivered with the machine in order to achieve
autonomy. On the other hand, it should be possible to extend the
models by using remote knowledge structures at the component
manufacturer (E). This solution cloud contains a lot of solutions that the
agent cannot calculate on his own. This can be the case with complex
calculations, innovations regarding other components or integration
tasks. These descriptions are available as configuration models in a
form that can also be evaluated by the autonomous agent.</p>
      <p>In addition to access the set of solutions, the autonomous agent
also has an engineering knowledge model (C2) that can be used to
determine solutions. This knowledge model contains different reusable
means such as component, machine and context models, procedures
(e.g. planning and design methods), different libraries of solution
ideas (descriptions of earlier solutions together with their properties
and evaluations in the form of models) and solution knowledge (such
as heuristic elements or regular information).</p>
      <p>In some cases, the autonomous agent can find a solution that meets
the requirements (C3). This is tested and realized e.g. by
parameterizing or changing the configuration of the system. In other cases, the
autonomous agent proposes solution variants that require additional
development activities by a machine builder or an exchange of
solution parts. In these cases, the autonomous agent provides the
necessary information such as requirements and boundary conditions to
the solution provider (e.g. special machine builder or drive supplier),
which are checked and evaluated by a development engineer and then
implemented.</p>
      <p>Due to its engineering knowledge model, the autonomous agent
can participate in the verification by the developer by, for example,
checking the consistency of the solution, simulating processes and
evaluating predictions of the behavior after the changes (C4).</p>
      <p>If necessary, the autonomous agent is accompanied by an
engineer while he applies the steps involved in implementing the solution,
such as selecting elements to be replaced, changing the configuration
and defining new parameters. By using the engineering configuration
model with the means of finding solutions, risks during
implementation are reduced by monitoring (D) the consistency of parameters
and configurations at each intermediate step and applying
successful procedures at implementation steps. In addition to simulation
and verification, undesired emergence, which could arise from
autonomous decisions, is recognized and ultimately prevented by
monitoring. Knowledge-based monitoring monitors the activities of the
autonomous agent. For this purpose, knowledge modeling about the
possible activities of the agent as well as of the machine and its
environment is used. This makes it possible to analyze and reflect on
actions while the agent is performing them and thus to recognize
unsafe actions and interactions. The simulation shows on the other
hand the system’s adapted behavior by means of a simulation model,
which processes the changes of the system behavior.</p>
      <p>The autonomous agent involves various solution component
vendors in order to obtain additional or new solution elements and new
configurations. These new solution elements can also be deployed
after the component vendor has analyzed the new requirements and
then developed a new component - which of course takes some time.</p>
      <p>Several solution agents based on our concepts carry out
selforganization in the sense that solution knowledge is brought together
both at the (special) machine manufacturer and at the supplier of
solution parts such as drive solutions in the search for suitable
solutions. There is also interaction with domain experts who contribute
further engineering knowledge or make decisions.</p>
      <p>Some examples of scenarios that an autonomous agent can support
are briefly listed below:</p>
      <sec id="sec-6-1">
        <title>Scenario 1: Increasing the load on a machine.</title>
        <p>Examples: Higher number of cycles than previously planned,
larger masses than previously planned.</p>
        <p>Possible solutions of the agent: A different machine model is
proposed, a larger engine is proposed.</p>
      </sec>
      <sec id="sec-6-2">
        <title>Scenario 2: Changing the requirements of a machine.</title>
        <p>Examples: Different environmental conditions, higher accuracy
Possible solutions of the agent: Other devices are proposed, a
reduced machine speed is proposed, another position sensor is
proposed.</p>
        <p>Scenario 3: Change of the solution offered by the supplier.</p>
        <p>Examples: A new low-maintenance gearbox or a new, more
powerful conveyor module is available.</p>
        <p>Possible solutions from the agent: A redesign of the machine or
the line is proposed and argued (costs, benefits).</p>
      </sec>
    </sec>
    <sec id="sec-7">
      <title>CHALLENGES FOR CREATING</title>
    </sec>
    <sec id="sec-8">
      <title>AUTONOMOUS ADAPTING MACHINES</title>
      <p>
        We identify following technologies for realizing autonomous
adapting machines. Figure 3 depicts a summary of the proposed
knowledge separation. The configuration model of a machine represents
all variants of the machine and its components [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]. The
configuration model (depicted as CM-C) is distributed, i.e., the autonomous
agent contains one part (CMA-C) of the configuration model and the
cloud of the component manufacturer another part (CMC -C).
CMAC contains the variants that are used and included during the time the
machine was manufactured. It is updated if the machine is adapted.
Considering that only some components supplied by a component
manufacturer constitute a machine, CMA-C has to be extracted from
the configuration model that represents all components of a
manufacturer. CMC -C changes over time if the component manufacturer
develops new components. Besides the configuration model the
autonomous agent contains the actual configuration of the machine
(current running hardware and software of the plant), i.e., an instance
CM-I of the configuration model. Besides the configuration model
CM-C, a requirement model RM will describe all possible
requirements the components of CM-C shall supply [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ]. Additionally to the
requirements and the configuration model, we consider here a
sensor model as a further artifact for structuring the knowledge of an
autonomous agent. The sensor model SM represents all sensors that
can acquire values about states in the environment [
        <xref ref-type="bibr" rid="ref3 ref5">3, 5</xref>
        ]. This model
also entails knowledge about thresholds for deriving qualitative
values about the world external to the machine. Those are mapped to
the RM for deriving possible requirements R the machine has to
fulfill [
        <xref ref-type="bibr" rid="ref5 ref6">5, 6</xref>
        ].
      </p>
      <p>Instan a on
sensor
model
sensor
values</p>
      <p>Mapping
requirements
model RM
requirements R
configura on
model CM-C
configura on
CM-I</p>
      <p>
        By representing all those models and mappings as well as the
identified new sensor values in a reasoning tool, a new configuration can
be inferred with commonly known technologies [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ]. Monitoring and
verification of intended adaptations are further tasks which will apply
simulation technologies and high-level monitoring of (here intended)
activities [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]. The needed adaptations (e.g., component changes or
updates) have to be identified, e.g., by comparing the original
configuration and the adapted configuration. Furthermore, necessary
planning actions have to be derived from a planning domain and finally
executed [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ]. All those technologies have to be combined in an
architecture for autonomous adapting machines which includes decision
about local and remote computations [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ].
      </p>
      <p>
        In a later step of our research, a further challenge comes into play
when interactions with other machines that become part of a
collaborative system as part of a changed manufacturing process are
considered. Collaborative systems in manufacturing processes are also
considered in the area of Industrie 4.0. However, in this field the focus is
to automatically setting up collaborative cyber physical systems for
production, through adaptive systems, as we are considering here,
the adaptation comes as a further challenge into consideration. In the
field of Internet of Things (IoT) similarily the processing of senor
data is considered. Their combination with configuration tasks were
also discussed by others, e.g. [
        <xref ref-type="bibr" rid="ref3 ref9">3, 9</xref>
        ].
6
      </p>
    </sec>
    <sec id="sec-9">
      <title>SUMMARY</title>
      <p>In this paper, we propose the use of configuration technologies not
only in the beginning of a product lifecycle, but also during
runtime of machines in production. Knowledge about variants and
dependencies, as well as reasoning methods known from the area of
knowledge-based configuration can support the adaptation of
machines. However, additional technologies, such as sensor evaluation,
as well as adaptation planning, monitoring and simulation have to
be considered. During our further research we will identify concrete
application scenarios for guiding the research in the direction of
autonomous adaptive machines.</p>
    </sec>
    <sec id="sec-10">
      <title>ACKNOWLEDGEMENTS</title>
      <p>We would like to thank the referees for their comments, which helped
improve this paper considerably. The paper is supported through the
project ADAM granted by the Federal Ministry of Education and
Research of Germany.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <given-names>Wilfried</given-names>
            <surname>Bohlken</surname>
          </string-name>
          , Patrick Koopmann, Lothar Hotz, and Bernd Neumann, '
          <article-title>Towards ontology-based realtime behaviour interpretation', in Human Behavior Recognition Technologies: Intelligent Applications for Monitoring and</article-title>
          Security, eds.,
          <string-name>
            <given-names>H.W.</given-names>
            <surname>Guesgen</surname>
          </string-name>
          and
          <string-name>
            <given-names>S.</given-names>
            <surname>Marsland</surname>
          </string-name>
          , IGI Global, pp.
          <fpage>33</fpage>
          -
          <lpage>64</lpage>
          , (
          <year>2013</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [2]
          <string-name>
            <given-names>A.</given-names>
            <surname>Felfernig</surname>
          </string-name>
          ,
          <string-name>
            <given-names>L.</given-names>
            <surname>Hotz</surname>
          </string-name>
          ,
          <string-name>
            <given-names>C.</given-names>
            <surname>Bagley</surname>
          </string-name>
          , and
          <string-name>
            <given-names>J.</given-names>
            <surname>Tiihonen</surname>
          </string-name>
          ,
          <string-name>
            <surname>Knowledge-Based</surname>
            <given-names>Configuration</given-names>
          </string-name>
          : From Research to Business Cases, Morgan Kaufmann Publishers, Massachusetts, US,
          <year>2014</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3]
          <string-name>
            <given-names>Alexander</given-names>
            <surname>Felfernig</surname>
          </string-name>
          , Andreas Falkner, Muslum Atas, Seda Polat Erdeniz, Christoph Uran, and Paolo Azzoni, '
          <article-title>ASP-based Knowledge Representations for IoT Configuration Scenarios'</article-title>
          ,
          <source>in Proc. of the 19th Configuration Workshop</source>
          , Paris, France, (
          <year>September 2017</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [4]
          <string-name>
            <given-names>L.</given-names>
            <surname>Hotz</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Felfernig</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Stumptner</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Ryabokon</surname>
          </string-name>
          ,
          <string-name>
            <given-names>C.</given-names>
            <surname>Bagley</surname>
          </string-name>
          , and
          <string-name>
            <given-names>K.</given-names>
            <surname>Wolter</surname>
          </string-name>
          , '
          <article-title>Configuration Knowledge Representation &amp; Reasoning', in Knowledge-based Configuration -</article-title>
          From Research to Business Cases, eds.,
          <string-name>
            <given-names>A.</given-names>
            <surname>Felfernig</surname>
          </string-name>
          ,
          <string-name>
            <given-names>L.</given-names>
            <surname>Hotz</surname>
          </string-name>
          ,
          <string-name>
            <given-names>C.</given-names>
            <surname>Bagley</surname>
          </string-name>
          , and
          <string-name>
            <given-names>J.</given-names>
            <surname>Tiihonen</surname>
          </string-name>
          , chapter
          <volume>6</volume>
          ,
          <fpage>59</fpage>
          -
          <lpage>96</lpage>
          , Morgan Kaufmann Publishers, (
          <year>2013</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [5]
          <string-name>
            <given-names>L.</given-names>
            <surname>Hotz</surname>
          </string-name>
          and
          <string-name>
            <given-names>K.</given-names>
            <surname>Wolter</surname>
          </string-name>
          , '
          <article-title>Smarthome Configuration Model', in Knowledge-based Configuration -</article-title>
          From Research to Business Cases, eds.,
          <string-name>
            <given-names>A.</given-names>
            <surname>Felfernig</surname>
          </string-name>
          ,
          <string-name>
            <given-names>L.</given-names>
            <surname>Hotz</surname>
          </string-name>
          ,
          <string-name>
            <given-names>C.</given-names>
            <surname>Bagley</surname>
          </string-name>
          , and
          <string-name>
            <given-names>J.</given-names>
            <surname>Tiihonen</surname>
          </string-name>
          , chapter
          <volume>10</volume>
          ,
          <fpage>157</fpage>
          -
          <lpage>174</lpage>
          , Morgan Kaufmann Publishers, (
          <year>2013</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [6]
          <string-name>
            <given-names>L.</given-names>
            <surname>Hotz</surname>
          </string-name>
          ,
          <string-name>
            <given-names>K.</given-names>
            <surname>Wolter</surname>
          </string-name>
          ,
          <string-name>
            <given-names>T.</given-names>
            <surname>Krebs</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            <surname>Deelstra</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Sinnema</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.</given-names>
            <surname>Nijhuis</surname>
          </string-name>
          , and
          <string-name>
            <surname>J. MacGregor</surname>
          </string-name>
          , Configuration in Industrial Product Families - The ConIPF Methodology, IOS Press, Berlin,
          <year>2006</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [7]
          <string-name>
            <given-names>K.C.</given-names>
            <surname>Ranze</surname>
          </string-name>
          ,
          <string-name>
            <given-names>T.</given-names>
            <surname>Scholz</surname>
          </string-name>
          ,
          <string-name>
            <given-names>T.</given-names>
            <surname>Wagner</surname>
          </string-name>
          ,
          <string-name>
            <surname>A</surname>
          </string-name>
          . Gu¨nter,
          <string-name>
            <given-names>O.</given-names>
            <surname>Herzog</surname>
          </string-name>
          ,
          <string-name>
            <given-names>O.</given-names>
            <surname>Hollmann</surname>
          </string-name>
          ,
          <string-name>
            <given-names>C.</given-names>
            <surname>Schlieder</surname>
          </string-name>
          , and
          <string-name>
            <given-names>V.</given-names>
            <surname>Arlt</surname>
          </string-name>
          , '
          <string-name>
            <given-names>A</given-names>
            <surname>Structure-Based Configuration Tool: Drive Solution Designer</surname>
          </string-name>
          <string-name>
            <surname>DSD</surname>
          </string-name>
          ',
          <volume>14</volume>
          . Conf.
          <source>Innovative Applications of AI</source>
          , (
          <year>2002</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          [8]
          <string-name>
            <given-names>S.</given-names>
            <surname>Rockel</surname>
          </string-name>
          ,
          <string-name>
            <given-names>B.</given-names>
            <surname>Neuman</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.</given-names>
            <surname>Zhang</surname>
          </string-name>
          ,
          <string-name>
            <given-names>K. S. R.</given-names>
            <surname>Dubba</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A. G.</given-names>
            <surname>Cohn</surname>
          </string-name>
          , S˘. Konec˘ny´,
          <string-name>
            <given-names>M.</given-names>
            <surname>Mansouri</surname>
          </string-name>
          ,
          <string-name>
            <given-names>F.</given-names>
            <surname>Pecora</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Saffiotti</surname>
          </string-name>
          , M. Gu¨nther, S. Stock,
          <string-name>
            <given-names>J.</given-names>
            <surname>Hertzberg</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A. M.</given-names>
            <surname>Tome´</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A. J.</given-names>
            <surname>Pinho</surname>
          </string-name>
          ,
          <string-name>
            <given-names>L. S.</given-names>
            <surname>Lopes</surname>
          </string-name>
          , S. von Riegen, and L. Hotz, '
          <article-title>An ontology-based multi-level robot architecture for learning from experiences', in Designing Intelligent Robots: Reintegrating AI II, AAAI Spring Symposium</article-title>
          , Stanford (USA),
          <source>(March</source>
          <year>2013</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          [9]
          <string-name>
            <given-names>D.</given-names>
            <surname>Schreiber</surname>
          </string-name>
          ,
          <string-name>
            <surname>Gembarski P.C.</surname>
          </string-name>
          , and
          <string-name>
            <given-names>R.</given-names>
            <surname>Lachmayer</surname>
          </string-name>
          , '
          <article-title>Modeling and configuration for Product-Service Systems: State of the art and future research'</article-title>
          ,
          <source>in Proc. of the 19th Configuration Workshop</source>
          , Paris, France, (
          <year>September 2017</year>
          ).
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>