<!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>A Model-Based Assessment for the Solution Space of a Cognitive Coffee Robot Waiter</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Thierry Sop Njindam</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Torsten Metzler</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Udo Lindemann</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Kristin Paetzold</string-name>
        </contrib>
      </contrib-group>
      <pub-date>
        <year>2013</year>
      </pub-date>
      <fpage>45</fpage>
      <lpage>57</lpage>
      <abstract>
        <p>Cognitive products are tangible and durable things with cognitive capabilities that meet and exceed user expectations by using cognitive functions, e.g. to perceive, to learn, to reason, etc., to reduce the need for human input. This paper presents a model-based assessment of the solution space for cognitive products. So far, the design of cognitive products has been based on prototype-oriented approaches, which mainly focus on cognitive algorithms, relying too much on designer´s experience, beliefs or ad hoc arbitrated processes and following as a consequence the “design it now and fix it later!”-philosophy. A model-based assessment of the solution space would enable a better and early estimation of design alternatives that meet not only software requirements but also hardware requirements from the very early stages down to system structural and behavioural aspects in highly dynamic and uncertain environments. The conventional MBSE approach has been adapted to cognitive products and is demonstrated using a cognitive coffee robot waiter.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>1. Introduction</title>
      <p>
        Cognitive products are tangible and durable things with cognitive capabilities such as
perceiving the environment, learning and reasoning from knowledge models that are
created through tight integration between a physical carrier system with embodied
mechanics, electronics, microprocessors and advanced software algorithms [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ]. A
typical cognitive product basically perceives its environment as well as the actions
performed by the user with whom it interacts through its embedded sensors, then
stores acquired information in its knowledge base, reorganizes and enlarges its prior
knowledge and skills through learning and then plans its actions either on the basis of
processes and sequences of operations stored in its knowledge base or from logical
reasoning mechanisms.
      </p>
      <p>The design of cognitive products requires a collaborative effort between
engineering sciences, information processing, cognitive and life sciences and artificial
intelligence. A holistic view of how the entire system fits together is required with regards
to the number and diversity of interconnected elements, the tight integration between
hardware and software elements, the close interaction with the surrounding
environment and the cognitive behavior over time. To date, there is no holistic approach to
support the development process of cognitive products. From the engineering design
point of view, systematic approaches (VDI 2221; VDI 2206; Axiomatic Design;
Gero´s FBS-Model), even though they provide fundamental aspects of the design as a
problem solving activity from the conceptual design and embodiment design to detail
design, have several shortcomings since they do not adequately consider the system as
a whole as well as the various involved disciplines (information processing, cognitive
sciences, etc.) and refer to disconnected simulation models in different design stages.</p>
      <p>With regards to the development of cognitive products, traditional long-lasting
prototype-oriented approaches with disintegrated hardware and software processes are
highly iterative, inefficient, time consuming, error-prone and do not fully comprehend
the system under consideration, especially during the early design phases.
The goal of this contribution is to improve the design process of cognitive products
and provide a generic model-based approach by addressing the following problems:
• Incoherent and non-holistic representation of the system with its cognitive
functions, especially during the early design phases.
• Insufficient traceability between core aspects of cognitive products such as
the flexibility of their requirements, functions including cognitive functions,
structure, behavior, performance and operational scenarios processed during
their lifetime.
• Arbitrary, experience-based or a priori selection of design parameters
without analysis and evaluation of system requirements, design options,
uncertainties during the product lifecycle, etc.
• Limited re-use of specifications, system models, and design artifacts to
support the development of complex embedded systems such as cognitive
products.</p>
      <p>The analysis and visualization of the solution space in the design process of
cognitive products will support decisions to be made in the selection of system design
parameters. A cognitive coffee robot waiter is used as an illustrative example.
Section 2 introduces cognitive products and how they are modeled from a functional
perspective. Section 3 describes a model-based systems engineering approach to
assess the solution space of systems in general. This approach is then applied to
partially assess the solution space of the coffee robot waiter in Section 4. Section 5 discusses
the results and section 6 concludes this contribution.</p>
    </sec>
    <sec id="sec-2">
      <title>2. Cognitive Products</title>
      <p>
        Cognitive products are tangible consist of a physical carrier system with embodied
mechanics, electronics, microprocessors and software. The surplus value is created
through cognitive functions enabled by flexible control loops and cognitive
algorithms, e. g. stemming from AI. Cognitive functions, like to perceive, to learn, to
reason, etc., allow cognitive products to act in an increasingly intelligent and
humanlike manner. They can adapt to dynamic environments as well as to the changing
product state and can be integrated in human living environments easily. They interact
and cooperate with humans, have a better performance than non-cognitive products
and are able to maintain multiple goals and make appropriate decisions and thus
exceed current user expectations [
        <xref ref-type="bibr" rid="ref11 ref8">8, 11</xref>
        ].
      </p>
      <p>
        To support the interdisciplinary development of cognitive products a taxonomy of
cognitive functions and flows is presented in [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ]. The taxonomy enables and fosters a
model-based development of formal functional models in the conceptual design phase
of cognitive products. Functional architectures, combining a functional model with a
structural model, make the reuse of the allocation from function to structure possible
as well as the identification of patterns. Another method, addressing how cognitive
functions can be identified in activity diagrams and integrated in cognitive product
concepts, has been published in [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ].
3.
      </p>
    </sec>
    <sec id="sec-3">
      <title>Model-Based Assessment of Solution Space in the early Design</title>
    </sec>
    <sec id="sec-4">
      <title>Phase</title>
      <p>
        This section describes a general model-based systems engineering (MBSE)
assessment of the solution space using systems engineering and extends it for cognitive
products by including the flexibility needed to handle the cognitive behaviour.
Generally, the earlier a new technology is adopted in complex systems development, the
more likely it is to create an inconsistent and error-prone design, at least before
adequate design methodologies are developed. Model-based systems engineering has
been widely recognized as an effective means to manage the complexity of systems
by using descriptive and simulation models to support the specification, design,
analysis and verification of systems consisting of both hardware and software components
[
        <xref ref-type="bibr" rid="ref4">4</xref>
        ]. The conventional framework as depicted in fig. 1 has been adapted to emphasize
cognitive functions as well as environmental conditions among the core
characteristics of cognitive products. This top-down approach maintains consistency between the
system views and activities within the design process such as requirements
specification, functional analysis, functional-structural allocation, architecture definition,
evaluation and optimization of design alternatives, verification and validation. New
challenges faced in designing cognitive products emerge on the one side from the
flexibility of requirements and related operational scenarios in a cognitive context and on the
other side from unpredictable and dynamic environmental conditions
      </p>
      <p>
        The adapted MBSE-Workflow begins with the well-known typical early design
tasks which focus on the identification of user needs as a basis for the technical
requirements specification. This stage defines and at the same time consequently
constrains the design space [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ].
      </p>
      <p>
        Next, the identified user needs and system requirements are turned into functions.
Functions are a solution-neutral description of what the system does and can be
represented conveniently in blocks with interfaces between them. The emphasis in
generating functional architectures of cognitive products is placed on the identification of
flows of information and energy among cognitive functions and between cognitive
functions and other non-cognitive functions. A deep understanding of the interactions
between the system and its surrounding dynamic environment, by means of inputs and
outputs, is crucial to determine the system boundary [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ]. It is usually necessary for
complex systems, to decompose their primary functions into sub-functions. This
increases the level of detail of the model and provides a good overview about the flows
(information, energy or matter) on which the functions operate [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ]. As a result, this
functional model, on the one side, provides a link between the system´s specifications
and the subsequent physical embodiment. The resulting functional model is an
abstract and static view of “what the system should do” and illustrates the internal
relations between the functions.
      </p>
      <p>
        On the other side, functional models strategically guide further allocation of system
functions to physical components even though there exists no direct or objective
mapping from functional elements to physical elements [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ], [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ]. This implies that
more than one design may ensue from the mapping between the functional domain
and the physical domain. Defining the system architecture, which further reduces the
solution space of design, includes the specification of structural design parameters
such as geometric attributes of parts and physical relationships between the parts.
However, the cognitive system behaviour is implemented to a great extent in the
system software elements. Even though related cognitive system attributes can not be
estimated at these design stages, it is crucial to set critical system parameters, limit
values and boundary conditions within which the cognitive system behaviour is
assumed to be performed. The context-dependent solution space of the design is then
tremendously influenced by these cognitive system variables and is the result of the
optimization of possible design alternatives in a well-defined context with a wide
range of possible scenarios. It is assessed by trading off structural and performance
design parameters, based on equations of the system dynamics and technical
constraints with regard to previously defined performance requirements, and by coupling
them with environmental variables and cognitive system attributes. A relatively high
level of imprecision of the environmental and system design parameters is assumed in
the early design phase. Several methods such as fuzzy arithmetic, interval
mathematics or probability-box have been introduced to cope with such uncertainties and
imprecision issues to estimate value ranges and margin of design parameters [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ],[
        <xref ref-type="bibr" rid="ref13">13</xref>
        ].
The final verification and validation activities are intended to make sure that the
selected design alternatives satisfy the previously defined system requirements in the
specified context.
4.
      </p>
    </sec>
    <sec id="sec-5">
      <title>Assessing the Solution Space of a Cognitive Product using an</title>
    </sec>
    <sec id="sec-6">
      <title>Application Example</title>
      <p>
        In this section is shown how the assessment of the solution space in cognitive product
development is accomplished using a coffee robot waiter as an example. The coffee
robot waiter (see fig.2 left) is a cognitive product serving coffee autonomously in a
known environment [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ]. It was developed by students and assistants with the goal to
implement and test cognitive functions in a physical product. The robot is able to
serve coffee based on orders placed on a website. This is possible because the robot
knows its working environment that it learned prior to the use-case when serving
coffee. If more than one order is placed at the same time it calculates the optimal
route according to an online traveling salesman algorithm which depicts some aspects
of the cognitive system behavior by planning the delivery route and then moves to the
target positions (compare tours in fig. 2 right). In addition, it checks if enough coffee
and energy is available to satisfy user requests. On its way it avoids static and
dynamic obstacles. It remembers reoccurring obstacles at certain locations and adds them to
the map to consider them in the next path calculation. Based on the robot´s
experience, it estimates the time till coffee is delivered for every target and sends a message
to the user screen.
      </p>
      <p>The focus of this paper regarding the assessment of the solution space of the coffee
robot waiter is on the top-level functional requirement “cognition” with its derived
sub-requirements “autonomy”, as illustrated in fig. 3. Other sub-requirements are not
relevant for this work. The objective herein is limited to the specifications of
“WHAT” the system should do in terms of its cognitive functions. Given this problem
and assumed requirements specifications, we identify the following core cognitive
functions:
• Perceive working environment
• Learn working environment
• Decide best route
• Think about orders
• Act in environment</p>
      <p>Perceives
user state</p>
      <p>Judges best
route</p>
      <p>Reasons
about coffee
range</p>
      <p>User4</p>
      <p>User3
User5</p>
      <p>User3</p>
      <p>User2
User1</p>
      <p>User4
User5</p>
      <p>User2</p>
      <p>User1
Starting Point</p>
      <p>Tour 1</p>
      <p>Starting Point</p>
      <p>
        Tour 2
Next, a functional architecture, as an essential element of the conceptual design of the
system is developed and serves as basis for the derivation of the system architecture.
In the application example the Systems Modeling Language (SysML) in combination
with the taxonomy of cognitive functions and flows is used. Cole Jr. underlines in [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ]
the importance of this integrated functional view in the design process even though
things are fuzzy at this stage of the design process. Hierarchical functional
identification diagrams and functional flow diagram are typical diagrams belonging to a
frontend functional analysis.
      </p>
    </sec>
    <sec id="sec-7">
      <title>4.1 Defining the system identification diagram cognitive functions with the functional</title>
      <p>Functional analysis, as viewed in the MBSE process (fig. 1), includes a top-down
view, from the highest to the lowest abstraction level which is usually required to
hierarchically decompose high level functions into sub-functions and illustrated by
functional identification diagrams. Fig. 4 illustrates the function hierarchy of the
coffee robot waiter.</p>
    </sec>
    <sec id="sec-8">
      <title>4.2 Representing the system functional model with functional flow diagram</title>
      <p>As functions are more detailed, functional flow diagrams show the linkage between
these functions and also provide valuable information on the arrangement of
functional elements, their sequence of actions and the interaction amongst the system
functions. The lines connecting the functions illustrate the functional flows by means of
information, data and energy flows. Figure 5 illustrates the functional flows of the
coffee robot waiter.</p>
    </sec>
    <sec id="sec-9">
      <title>4.3 Allocating functional to structural parts</title>
      <p>Allocating functional elements to structural elements is a common aspect in the
design process called system architecture which provides an overview about the
concrete relation between cognitive functions and the structural elements they need to be
realized in the physical world. The complexity of cognitive products is reflected in
this stage with the number and diversity of interrelated system elements. Linking
cognitive functions with physical elements is basically essential to identify the
necessary hardware modules and generate the system physical architecture. An example of
the functional-structural allocation for the cognitive function “Act in environment” is
illustrated in fig. 6. The complete functional-structural allocation of the system is
illustrated in a functional-structural allocation matrix in fig. 7.</p>
      <p>The complete hardware configuration of the coffee robot waiter with characteristic
design parameters is shown in fig. 8. The associated design parameters related to the
hardware components are displayed as values and serve as basis for the subsequent
value-oriented exploration of the solution space of design. The linkage between the
models of the coffee robot waiter and external numerical solver for the computation
of the solution space of design is done with the SysML-Parametrics diagrams.</p>
    </sec>
    <sec id="sec-10">
      <title>4.4 Use of causal loops to optimize design alternatives</title>
      <p>The main task to assess the solution space of structural elements of the coffee robot
waiter is to trade-off performance and structural design parameters with a view to
requirements specification and technical constraints. At the same time, designers must
make sure the coffee robot waiter has enough energy left to perform its cognitive
functions while delivering coffee orders as fast as possible. As already stated in the
description of the cognitive coffee waiter, a map of the environment with
environmental variables such as the estimated position of the users is incorporated into its
knowledge module. The coffee robot waiter is equipped with a coffee pot having a
capacity of five cups and being able to deliver coffee at maximum to five users out of
ten potential users in one tour after which it automatically returns to its starting point
to refill the coffee pot and recharge its batteries. Fig. 2 illustrates the map of the
environment with two tours we reproduced in an external numerical computing
environment. Possible scenarios with boundary conditions are hereby defined with these
assumptions.</p>
      <p>Voltage
Electrical motor rotational speed
Power consumption of electronic components
Gear Ratio
Speed range
Mass of the hardware components</p>
      <p>
        Variable Parameters
[24:3:96] V
[2000:750:10000] 1/min
[24:0.4:64] W
6:1:16
0.1:0.05:0.4 m/s
[5.243:0.036:7.171] kg
Acceleration of gravity
Desired Acceleration during the delivery
Coefficient of friction
Wheel radius
Transmission efficiency
Mass of the coffee pot
Mass of one coffee cup
9.81 m/s²
0.2 m/s²
0.01
0.035 m
0.8
0.728 kg
0.3 kg
From this, the coffee robot waiter chooses up to five users (represented in fig. 2) from
the ten assumed available users (boxes on the map; blue boxes represent the locations
of the unselected users during the delivery tour) and drives back to the starting point
(colored in green, fig. 2). The traveling salesman algorithm has been computed to
calculate the optimal route (see fig. 2) for the delivery. We did not include static and
dynamic obstacles for this work. The simulation of the environment with the assumed
user locations was numerically solved with the well-known Traveling Salesman
Problem and has the objective to estimate the distance covered by the cognitive coffee
robot waiter during the coffee delivery which is the basis for the energy consumption
while moving. However, one of the most difficult problems encountered at this design
stage when optimizing complex systems is, as explained above, the suitable
estimation of their component design parameters whose values cannot be predicted with
certainty. To cope with this issue, interval analysis has proven useful in bounding the
values, by means of their minimum and maximum, of uncertain design parameters
[
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]. The system design parameters employed for this case study can be selected either
on the basis of the designer´s experience or on empirical values and are to be varied
as shown in Table 1. Common parameters such as coefficients of friction, mass of the
coffee pot can be assumed as fixed.
      </p>
      <p>
        Based on these assumptions, a trade-off between the design parameters is done, the
constraints related to the system´s dynamic behavior and the optimization objectives.
Fig. 9 shows the results of the performed simulation of the solution space. For a better
understanding of the use case scenario, the distance travelled by the cognitive coffee
waiter was divided in five different sub-distances, corresponding to the delivery of
one coffee cup to a user. It is assumed that no obstacle disturbs during the delivery. It
is also assumed, due to the significant energy consumption of activities requiring high
level computation such as cognitive processing, that the energy consumption of the
motion of the robot accounts only for half of the total energy consumption [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ]. The
feasible solution space of design shows that the results of the trade-off analysis are
not obtained from the maximization or minimization of the assumed design
parameters. We used a variance coefficient (var = 0.2) to express the deviation from these
extreme values (maximum and minimum). This reflects the fact that the global
optimum does not fulfill the previously defined requirements. Based on these results,
designers are able to support their decision making process concerning the mass of the
structural components and the energy consumption, by means of the battery capacity
the cognitive coffee waiter needs to perform its cognitive tasks, thus satisfying the
optimization objectives.
      </p>
      <p>Tour 1
Robot mass: 8,02kg
Capacity: 31,80 mAH</p>
      <p>Tour 2
Robot mass: 8,02kg</p>
      <p>Capacity: 22,80 mAH</p>
    </sec>
    <sec id="sec-11">
      <title>5. Discussion</title>
      <p>The context-dependent assessment of the solution space of the coffee robot waiter,
while considering two delivering tours (fig. 2 left), is illustrated in figure 9. The
required capacity of the battery throughout the delivering from one user to the next and
back to the starting point is illustrated. For example, with an assumed robot total mass
of 8,02 kg, the battery must have at least 31.8 mAh in the first delivery simulation
(tour 1, see fig. 2) from the starting point to user 1 and 22.8 mAh in the second
delivery simulation (tour 2, see fig. 2) from the starting point to user 1. As expected, the
mass of the robot as well as the distance between the users play a huge role in power
consumption. The estimation of the driving distance with the TSP algorithm (see
delivery tour 1 and 2 in fig. 2) has proven to be necessary for the approximation of the
delivery distance. On a broader scale, simulating as many as possible scenarios and
delivery tours is appropriate to consider many use cases before building a physical
prototype. The assessment of the solution space is also possible regarding other
design parameters from Table. 1. However, designers must be aware of the
unpredictable delivering sequence of orders in the sense that users ordering can not be fully
predictable. After simulation, it is possible to estimate depending on the mass and the
delivering state how much energy the cognitive coffee waiter requires. Further work
is needed to reasonably estimate the power consumption of electronic components,
especially during high computation tasks such as the cognitive processing. This
cannot be achieved without several testing procedures.</p>
    </sec>
    <sec id="sec-12">
      <title>6. Conclusion</title>
      <p>In this contribution, an approach is proposed to analyze and visualize the solution
space of cognitive products using the cognitive coffee waiter as an example. The feed
forward approach starts with the requirements specification up to the optimization and
evaluation of design alternatives which are represented in the design solution space.
On this basis, designers can computationally generate and verify several use cases and
analyze the solution space to support their decisions concerning the choice of system
design parameters.</p>
    </sec>
    <sec id="sec-13">
      <title>7. References</title>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <given-names>Abdul</given-names>
            <surname>Rahman</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M. A.</given-names>
            ,
            <surname>Mayama</surname>
          </string-name>
          ,
          <string-name>
            <given-names>K.</given-names>
            ,
            <surname>Takasu</surname>
          </string-name>
          ,
          <string-name>
            <given-names>T.</given-names>
            ,
            <surname>Yasuda</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            and
            <surname>Mizukawa</surname>
          </string-name>
          ,
          <string-name>
            <surname>M. “</surname>
          </string-name>
          <article-title>ModelDriven Development of Intelligent Mobile Robot Using Systems Modeling Language”</article-title>
          , In "Mobile Robots - Control
          <string-name>
            <surname>Architectures</surname>
          </string-name>
          ,
          <article-title>Bio-Interfacing, Navigation, Multi Robot Motion Planning</article-title>
          and Operator”,
          <year>2011</year>
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [2]
          <string-name>
            <surname>Antonsson</surname>
            ,
            <given-names>E.K.</given-names>
          </string-name>
          , and
          <string-name>
            <surname>Otto</surname>
            ,
            <given-names>K.N.</given-names>
          </string-name>
          (
          <year>1995</year>
          ), 'Imprecision in Engineering Design',
          <source>ASME Journal of Mechanical Design 117</source>
          , pp.
          <fpage>25</fpage>
          -
          <lpage>32</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3]
          <string-name>
            <surname>Cole</surname>
            ,
            <given-names>E.L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Jr</surname>
          </string-name>
          ., “
          <article-title>Functional analysis: a system conceptual design tool [and application to ATC system]</article-title>
          ,
          <source>in IEEE Transactions on Aerospace and Electronic Systems</source>
          , Vol.
          <volume>34</volume>
          , Issue 2, pp.
          <fpage>354</fpage>
          -
          <lpage>365</lpage>
          ,
          <year>1998</year>
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [4]
          <string-name>
            <surname>Estefan</surname>
            ,
            <given-names>J. A.</given-names>
          </string-name>
          :
          <article-title>Survey of Model.Based Systems Engineering (MBSE) Methodologies</article-title>
          , Jet Propulsion Laboratory, California Institute of Technology,
          <source>Tech. Rep</source>
          ., May 2007
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [5]
          <string-name>
            <surname>Gero</surname>
            ,
            <given-names>J.S.</given-names>
          </string-name>
          (
          <year>1990</year>
          ) '
          <article-title>Design prototypes: a knowledge representation schema for design'</article-title>
          ,
          <source>AI</source>
          Magazine
          <volume>11</volume>
          (
          <issue>4</issue>
          ), pp.
          <fpage>26</fpage>
          -
          <lpage>36</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [6]
          <string-name>
            <surname>Kordon</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wall</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Stone</surname>
            ,
            <given-names>H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Blume</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Skipper</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ingham</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Neelon</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Chase</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Baalke</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hanks</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Salcedo</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Solisch</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Postma</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Machuzak</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          (
          <year>2007</year>
          )
          <article-title>'Model-Based Engineering Design Pilots at JPL</article-title>
          '
          <source>IEEE Aerospace Conference Proceedings, 3rd -10th March</source>
          ,
          <year>2007</year>
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [7]
          <string-name>
            <surname>Mei</surname>
            ,
            <given-names>Y.</given-names>
          </string-name>
          ,;
          <string-name>
            <surname>Lu</surname>
            , Y.-H.; Hu,
            <given-names>Y.C.</given-names>
          </string-name>
          ;
          <string-name>
            <surname>Lee</surname>
            ,
            <given-names>C.S.G.</given-names>
          </string-name>
          <article-title>A case study of mobile robot´s energy consumption and conservation techniques</article-title>
          ,
          <source>Proceedings of the 12th International Conference on Advanced Robotics</source>
          ,
          <year>2005</year>
          . ICAR '
          <volume>05</volume>
          , pp.
          <fpage>492</fpage>
          -
          <lpage>497</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          [8]
          <string-name>
            <surname>Metzler</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Shea</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          :
          <article-title>Cognitive Products: Definition and Framework</article-title>
          ,
          <source>In: Proceedings of International Design Conference (DESIGN2010)</source>
          , May 17-20, Dubrovnik, Croatia,
          <year>2010</year>
          , pp.
          <fpage>865</fpage>
          -
          <lpage>874</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          [9]
          <string-name>
            <surname>Metzler</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Shea</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          :
          <article-title>Taxonomy of Cognitive Functions</article-title>
          ,
          <source>In: Proceedings of 18th International Conference on Engineering Design (ICED11)</source>
          ,
          <source>August 15 - 18</source>
          , Copenhagen, Denmark,
          <year>2011</year>
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          [10]
          <string-name>
            <surname>Metzler</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Jowers</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kain</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lindemann</surname>
            ,
            <given-names>U.</given-names>
          </string-name>
          :
          <article-title>Development of Cognitive Products via Interpretation of System Boundaries</article-title>
          ,
          <source>In Proceedings of 4th Conference on Research into Design (ICoRD´ 13)</source>
          ,
          <source>January 7th - 9th</source>
          , Chennai, India
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          [11]
          <string-name>
            <surname>Paetzold</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <article-title>Ethische Aspekte bei der Entwicklung kognitiver technischer Systeme für die Unterstützung bei demenziellen Erkrankungen</article-title>
          , In Internation Conference on Engineering Design, ICED'
          <volume>07</volume>
          ,
          <fpage>28</fpage>
          -
          <lpage>31</lpage>
          august
          <year>2007</year>
          ,
          <article-title>Cite des</article-title>
          Sciences et de l´Industrie, Paris, France
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          [12]
          <string-name>
            <surname>Pahl</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Beitz</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Feldhusen</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Grote</surname>
          </string-name>
          , K.-H., “Engineering Design:
          <article-title>A Systematic Approach”</article-title>
          , 3rd ed., Springer,
          <year>2007</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          [13]
          <string-name>
            <surname>Rekuc</surname>
            <given-names>S.J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Aughenbaugh</surname>
            <given-names>J.M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bruns</surname>
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Paredis</surname>
            <given-names>C.J.J.</given-names>
          </string-name>
          , “
          <article-title>Eliminating design alternatives based on imprecise information</article-title>
          .” In Society of Automotive Engineering World Congress. Detroit, MI,
          <year>2006</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          [14]
          <string-name>
            <given-names>Sop</given-names>
            <surname>Njindam</surname>
          </string-name>
          ,
          <string-name>
            <given-names>T.</given-names>
            ,
            <surname>Platen</surname>
          </string-name>
          ,
          <string-name>
            <given-names>E.</given-names>
            and
            <surname>Paetzold</surname>
          </string-name>
          ,
          <string-name>
            <surname>K.</surname>
          </string-name>
          (
          <year>2012</year>
          )
          <article-title>„Modellbasiertes Systems Engineering zur frühzeitigen Absicherung komplexer multidisziplinärer Systeme“</article-title>
          , in Maurer, M. and
          <string-name>
            <surname>Schulze</surname>
            ,
            <given-names>S.-O.</given-names>
          </string-name>
          , (eds.) (
          <year>2012</year>
          ),
          <article-title>Tag des Systems Engineering</article-title>
          , Paderborn, Germany, November 7th-9th, München, Hanser.
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          [15]
          <string-name>
            <surname>Suh</surname>
            ,
            <given-names>N.P.</given-names>
          </string-name>
          (
          <year>1990</year>
          ) “
          <article-title>The Principles of Design”</article-title>
          , Cambridge, Massachusetts, Oxford Series on Advanced Manufacturing.
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>