∎

11institutetext: L. Asprino 22institutetext: FICLIT, University of Bologna,
via Zamboni, 32 - 40126 - Bologna
STLab (ISTC-CNR), Via San Martino della Battaglia, 44, 00185 Rome, Italy
22email<EMAIL_ADDRESS>
33institutetext: A. G. Nuzzolese 44institutetext: A. Russo 55institutetext:
STLab (ISTC-CNR), Via San Martino della Battaglia, 44, 00185 Rome, Italy
55email<EMAIL_ADDRESS>
55email<EMAIL_ADDRESS>66institutetext: P. Ciancarini
77institutetext: DISI, University of Bologna, Mura Anteo Zamboni, 7, 40126
Bologna, Italy
Innopolis University, Russian Federation
77email<EMAIL_ADDRESS>88institutetext: V. Presutti
99institutetext: LILEC, University of Bologna, Via Cartoleria 5, Bologna,
Bologna, Italy
STLab (ISTC-CNR), Via San Martino della Battaglia, 44, 00185 Rome, Italy
99email<EMAIL_ADDRESS>
# A Reference Software Architecture for Social Robots

Luigi Asprino  Paolo Ciancarini  Andrea Giovanni Nuzzolese  Valentina Presutti
Alessandro Russo

(Received: date / Accepted: date)

###### Abstract

Social Robotics poses tough challenges to software designers who are required
to take care of difficult architectural drivers like acceptability, trust of
robots as well as to guarantee that robots establish a personalised
interaction with their users. Moreover, in this context recurrent software
design issues such as ensuring interoperability, improving reusability and
customizability of software components also arise.

Designing and implementing social robotic software architectures is a time-
intensive activity requiring multi-disciplinary expertise: this makes
difficult to rapidly develop, customise, and personalise robotic solutions.

These challenges may be mitigated at design time by choosing certain
architectural styles, implementing specific architectural patterns and using
particular technologies.

Leveraging on our experience in the MARIO project, in this paper we propose a
series of principles that social robots may benefit from. These principles lay
also the foundations for the design of a reference software architecture for
Social Robots. The ultimate goal of this work is to establish a common ground
based on a reference software architecture to allow to easily reuse robotic
software components in order to rapidly develop, implement, and personalise
Social Robots.

###### Keywords:

Social Robots Design Software Architectures Architectural Patterns
Interoperability Ontologies Linked Open Data

##  1 Software Design in Social Robotics

Social Robots Bartneck2004 (12, 19, 30, 38, 35, 42) are autonomous embodied
agents that interact, collaborate, communicate with humans, by following the
behavioral norms expected by people with whom robots are intended to interact.
Several definitions have been proposed for the term “social robot”, but all of
them broadly agree that a social robot has the following characteristics:  (i)
Physical embodiment, i.e. a social robot has a physical body;  (ii) Sociality,
i.e. a social robot is able to interact with people by showing human-like
features while following the social rules (defined through society) attached
to its role;  (iii) Autonomy, i.e. a social robot makes decisions by itself
(the autonomy is sometimes limited in testing phase, like in the Wizard of Oz
experimental setting Kelley1984 (54, 72)).  Social robots provide valuable
solutions for domains, such as education Kennedy2018 (55) or healthcare
Broekens2009 (21), where robots must have social skills to establish and
preserve social relationships (even if their domain is dominated by non-social
activities) Dautenhahn1995 (29).

##### Social Drivers.

In order to make robots able to establish social relationships, they must be
designed so to favor acceptability, trust and to guarantee a personalized
interaction with their users. Acceptability is described as the “the
demonstrable willingness within a user group to employ technology for the
tasks it is designed to support” Dillon2001 (34). Trust is defined as “a
belief, held by the trustor, that the trustee will act in a manner that
mitigates the trustor’s risk in a situation in which the trustor has put its
outcomes at risk” Wagner2009 (79). Humans assess the reliability of a relation
when interacting with another agent, hence it becomes critical for robots to
act in a way to create and maintain a trusted relation. No matter how capable
is an embodied agent, since its actions may entail risk for its users, they do
not interact with it if they do not trust it. To be accepted to our society
robots must show that they are worthy of trust Kuipers2018 (58).

A few studies Lee2012a (59, 48) have demonstrated that the ability of robots
of personalising the interaction with their users is one of the key features
that reinforces people’s rapport, cooperation, and engagement with a robot.
Robots able to personalise the social interactions adapt their behavior and
interaction policy in order to accommodate user preferences, needs, and
emotional and psychological state.

Moreover, there exists a variety of challenges that arises in the
implementation of a (social) robotics solution Ahmad2016 (1):  (i) How to
guarantee the syntactic and semantic interoperability of data exchanged by
software artifacts running on a robotic platform?  (ii) How to integrate and
ease the deployment of software modules in robotic architecture?  (iii) How to
ease the customization of robot’s behavior?  (iv) How to enhance the
reusability of software components in robot’s architectures?

##### Contributions.

Physical body, hardware and software components contribute to the development
of robot social skills and have a role in mitigating these social robotics’
challenges, and establishing and favoring the human-robot interaction
Dautenhahn2002 (32, 52). In this paper we will focus on robot’s software layer
by investigating how to organise software components in order to facilitate
the development of robot’s social skills as well as to enable robots to carry
out a personalised interaction with their users and to increase acceptability,
trust, and sociability. Specifically, we discuss how the design of the
software architecture of the social robots may benefit of well-known
architectural patterns and established technologies. We claim that the design
of the robot’s software architecture may mitigate common challenges for social
robotics at design time. Moreover, we propose a reference software
architecture for Social Robots that, in our opinion, may favor of the reuse of
established technologies and standardised software components thus
streamlining the development of social robotics solutions. This architecture:
(i) defines a common vocabulary that may facilitate the communications among
software designers;  (ii) serves as a template for developing systems;  (iii)
provides a generalization of 24 existing robotics solutions.  Finally, the
architecture is aimed at:  (i) easing customizability and extensibility of
robot’s behavior and social skills;  (ii) guaranteeing explainability and
predicatability of robot’s decisions;  (iii) improving both inner (among
architectural components) and outer (with external entities) interoperability;
(iv) enabling a rapid prototyping of robotic applications;  (v) enhancing
reusability of architectural components.

##### Design Methodology.

The proposed architecture has been developed with a bottom-up approach. We
have elicited a set of (general) architectural drivers (cf. Section 3) from
the (local) use cases MARIOD1.1 (16) defined in the context of a Socially
Assistive Robotics project (cf. Section 6) Mannion2019 (63). This
generalization was aimed at formulating the architectural drivers in a way to
capture major challenges for software architecture design in Social Robotics.
The drivers led us to the selection of a set of architectural principles,
namely architectural styles and patterns, that Social Robotics architectures
may benefit from. Furthermore, in order to generalize the design of the
architecture we have analysed 24 Social Robotics solutions in order to
characterise a reference architecture for a Social Robot. Finally, drivers and
principles have guided the design of the architecture presented in Section 5.
As a result, the architecture proposed in Section 5 is an instance of the
reference architecture of a Social Robot discussed in Section 2 that also
follows the architectural drivers elicited in Section 3 and the architectural
principles of Section 4. Finally, this paper discusses the implementation of
the proposed architecture in the context of the MARIO project (cf. Section 6).

##### Outline.

The rest of the paper is organised as follows. An overview of the existing
software architectures of the existing social robots is provided in Section 2.
Section 3 discusses the drivers that guided the design of the architecture. A
set of architectural and technological choices meeting the aforementioned
drivers are presented in Section 4. Section 5 describes the proposed
architecture and Section 6 gives an insight of how the architecture has been
implemented in MARIO. Finally, Section 7 concludes the paper and outlines the
future work.

##  2 Commonalities of Software Architectures for Social Robots

Despite the different application domains and the intended functions, software
architectures of Social Robots have a common underlying structure. This common
underlying structure has been synthesized in the Reference Architecture showed
in Figure 1.

Figure 1: Reference Architecture of a Social Robot.

This architecture is the result of the analysis of 24 papers describing social
robotics systems Bonaccorsi2016 (17, 23, 24, 25, 28, 39, 33, 40, 47, 49, 50,
51, 53, 57, 61, 60, 66, 70, 74, 75, 77, 78, 82, 84) and it also leverages on
our experience in the MARIO project Mannion2019 (63).

These works have been selected with Systematic Mapping Study (SMS) method
Petersen2008 (69) that comprises three steps:

  1. (i)

Planning a study. The research questions that guided this study have been
already discussed and discussed in Section 1;

  2. (ii)

Data collection. We have enriched the collection of 10 papers identified in a
previous analysis Asprino2019g (4) with a systematic analysis of all the
issues of the International Journal of Social Robotics (IJSR). We analysed
IJSR papers in order to select all the papers presenting social robotics
solutions. This first selection which resulted in 23 papers considered papers’
title and abstract only. A further deeper analysis of these papers was needed
in order to keep only papers presenting architectural design of the robot.
This step restricted the set of papers of IJSR papers to 11. Additional 3
papers were identified by analysing the references of the selected papers.

  3. (iii)

Analysing the results. The analysis of the selected 24 papers is presented in
this section.

All of the existing architectures define a layering of their components.
Almost all of them differentiate the robot’s “deliberative” from the
“automatic” level (terminology borrowed from Barber2001 (11)). The former is
meant to decide the next actions the robot has to perform. The latter allows
the robot to perceive the environment through its sensors (such as lasers,
cameras, touch sensors, microphones etc.), to manage the actuators (e.g.
wheels engines, speakers etc.) and to provide other basic facilities such as:
speech to text (S2T), text to speech (T2S), motion controller and HCI (the
human control interface, i.e. a software component that provides a set of APIs
that are meant to manage embodied devices, such as a tablet or buttons, that
can be used by users to command the robot). Software components running on the
automatic level are often provided by the standard development kit of robots.

An alternative terminology, proposed by Wood et al. Wood2019 (82), separates
sensors, which constitute the “sense” layer, from actuators, which form the
“act” layer, and the deliberative layer is called “think” layer.

Although most of the systems run entirely on robot, there also exist examples
of distributed robotic architectures, such as Bonaccorsi2016 (17, 57, 61), in
which the deliberative layer is hosted on a remote server and the automatic
runs on the robot. In such architectures the deliberative layer can also
control multiple robots at the same time.

Deliberative and automatic layers usually communicate through a semantic bus.
A semantic bus manager is a software component implementing the
publish/subscribe pattern for supporting a loosely coupled communication
throughout the system (e.g. topics in ROS Quigley2009 (71)). The semantic bus
manager allows software component to establish semantic buses that are N-to-N
communication channels in which strictly-typed messages flow from the
publishers to the subscribers of the channel.

Peculiarities of individual systems apart, all the architectures broadly
converge on a deliberative layer constituted by a Behavior Manager, a
Knowledge Base Manager, a set of predefined Behaviors, a set of Capabilities
(also called Skills) and, if necessary, a Supervisory Controller. The Behavior
Manager is a software component that gathers information from perceptual
components and knowledge base in order to decide the next actions the robot
has to perform. Specifically, it detects from the acquired information the
current state of the world and then it activates one of its predefined
Behaviors. A Behavior is a procedure that makes the robot perform actions
(e.g. movements, reproducing sounds etc.). Examples of Behaviors are entertain
the user, reminding something, charging its battery etc.

Some existing architectures Cao2019 (24, 49, 70) distinguish general purpose
functional capabilities of robots from their behavioral capabilities. In such
architectures functional capabilities used by multiple behaviors (such as face
detection, person tracking, dialogue managing etc.) form a layer apart that
enables the reuse of capabilities among Behaviors. These capabilities
complement basic functionalities provided (such as S2T, T2S, HCI, Motion
controller etc.) usually provided by the agent.

A Knowledge Manager is a software component that provides APIs to store
information for supporting the robot’s behaviors, tracing the users’
activities or preferences, and collecting from the operating environment (e.g.
maps). Many existing architectures Cao2016 (23, 24, 28, 39, 40, 57, 61, 78,
70) have a centralized Knowledge Base (sometimes articulated into two
databases, such as Louie2014 (61)) all the components can contribute
to/benefit from.

Some architectures, such as Cao2016 (23, 24, 39), explicitly define a
Supervisory Controller that enables to remotely govern the robot. Such a
interface is part of one of the most common HRI experimental techniques called
Wizard of Oz Kelley1984 (54, 72). In this setting subjects interacting with
the robot believe that it is autonomous but it is actually being operated by
an unseen human being.

##  3 Architectural Drivers

In this section we introduce the main drivers that lead the design of the
proposed architecture. We classified the drivers in functional, presented in
Section 3.1, and non-functional, discussed in Section 3.2.

###  3.1 Functional Drivers

Functional drivers are defined as capabilities that must be met by a system in
order to satisfy a form of request. Therefore, functional drivers may vary a
lot depending on the objectives of the specific system. In this section we
discuss the general functional drivers that a social robot should meet.

##### Perceiving/Interacting/Motioning within the Environment.

A social robot should be able to perceive, to move itself within and
physically interact with its operating environment Yan2014 (83). These drivers
must be met by all embodied agents that need to interact with their operating
environment through their physical body, such as mobile robots or service
robots. However, a social robot may overlook these drivers if the interaction
with humans is limited to non-physical languages (e.g. spoken language) and if
it does not need to perceive the external environment. Examples of this kind
of robots are the personal assistants (e.g. Amazon Echo, Google Home etc.).

##### Interacting with Humans.

Interaction between robots and humans may take several forms depending on
human-robot proximity (cf. Goodrich2008 (52)). For a social interaction it is
important that humans and the robots are co-located in the same environment.
Within the same environment the interaction may require mobility, physical
manipulation, cognitive (e.g. natural language understanding) or emotional
(e.g. emotion recognition) abilities. Here, we stress on the most important
abilities that enable interaction with humans and increase the social
acceptability of social robots.

Dialoguing is a form of interaction where two or more parties communicate.
There are two main forms of human-robot dialogue verbal and non-verbal. social
robots should be able to interact with humans using natural language (i.e.
verbal communication). Natural language dialoguing involve capabilities
related to speech and natural language processing such as:  (i) Speech
recognition, i.e. the ability of recognizing and translating spoken language
into digital-encoded text;  (ii) Natural language understanding(also called
machine reading), i.e. the ability of understanding the meaning of the text
and transforming the meaning to a formal structured representation that can be
interpreted by machines;  (iii) Dialogue managing, i.e. the ability of keeping
the history and state of a dialog, managing the general flow of the
conversation and formulating the semantic representation of the robot’s
utterances;  (iv) Natural language generation, i.e. the ability of generating
natural language text from a semantic representation of the utterance;  (v)
Speech Synthesis, i.e. the ability of converting the natural language text
into speech.

Non-verbal interaction include the use natural cues (e.g. gaze, gestures, body
positioning etc.). The use of basic cues can bootstrap a person’s ability of
developing a social relationship with a robot Duffy2003 (36). For example,
facial gestures Breazeal2000 (20) and motion behaviors Duffy2002 (37) may
facilitate to develop a social relationship with a robot.

Emotions play a significant role in facilitating human-robot interaction (e.g.
Ogata2000 (67, 22)). Therefore, it is important that a social robot is able to
recognize and identify emotions in humans, and to express emotions.

##### Learning and Memorising Knowledge.

In order to increase its social acceptability and to evolve its social skills,
a social robot must be able to learn (e.g. facts, rules, norms etc.)
Dautenhahn1995b (31). Continuously evolving the robot’s knowledge is useful
for adapting the robot’s behavior in order to accommodate humans’ requests in
a way they expect.

###  3.2 Non-Functional Drivers

Non-Functional Drivers specify general properties of a system, rather than its
specific functional behavior. This section summarizes the general non-
functional requirements that a social robot should meet.

##### Flexibility/Modifiability/Estensibility.

One of the major challenges in robotics concerns the design of software
architectures to support the development of the robot behaviors as plug and
play applications Chibani2013 (26). The robot software architecture should
offer an extensibility mechanism to support the composition of new robot
behaviors by combinating the existing ones as building blocks. The
requirements of flexibility, modifiability and extensibility of the software
architecture is even stronger for social robotics applications. In fact,
social robotics applications might involve a wide variety of components
ranging from the component that controls the wheel engines (i.e. components
that directly access to the robot’s hardware) to the component aimed at
understanding what the user says (i.e. components that perform high-level
tasks). Moreover, extensibility of robot’s behavior makes sure that the robot
is able to easily extend its capabilities to meet users’ requirements, thus
increasing its acceptability.

##### Customizability.

Customizing robot’s behavior and social skills on the basis of users’ needs is
crucial in order to improve robot acceptability Bailey2009 (10, 41).
Therefore, robotic software applications should either provide an easy
customization interface available for behavior’s designers or guarantee that
the robot is able to autonomously learn how to modify its behavior to meet the
user needs.

##### Predictability.

To instill trust to its users, a robot must be able to explain and justify its
actions, and its behavior should be predictable. Without a satisfactory
explanation for robots’ actions, users are not able to assess robots’
decisions thus reducing its trustworthiness Alaieri2016 (2).

##### Interoperability.

Generally speaking, interoperability is the ability of a system to interact
and work together with other systems Wegner1996 (80). In order to
interoperate, the systems have to agree on a common data format, an
unambiguous meaning for the exchanged data, and a protocol for exchanging
information. In robotics we can distinguish two kinds of interoperability:
inner and outer. The inner interoperability is defined as the ability of a
software component to interoperate with another component running on the same
robot. The outer interoperability is the ability of a robot (i.e. one of its
software component) to intoperate with another robot Mayoral2017 (65).
Interoperability is not directly related to social robotics challenges but it
is a transversal requirement that enables software components to be easily
integrated, reused and deployed.

##### Rapid Prototyping and Reusability of Software Components.

One of the major problems for the design of a social robot is the definition
of the user requirements, which, in turn, is critical to the adoption of the
robot itself. An accurate early elicitation of the requirements and early
feedback on the developing robotic solution may save from costly changes in
the robot design at a later stage. Similar problems are experienced by
software developers which usually mitigate these issues with rapid
prototyping. Rapid prototyping refers to a class of techniques that are meant
to create and test system prototypes at a very early stage with the aim of
getting feedback from users as early as possible. Rapid prototyping techniques
have long been adopted in robotics too (e.g. Bartneck2004b (13, 81)) and,
since user experience is even more critical than other domain, we believe that
rapid prototyping techniques should be extensively applied in social robotics.
A common strategy to enable rapid prototyping is to compose systems by reusing
off-the-shelf software components available on a trusted repository (e.g. apt
or yum for Linux). Therefore, we advocate for the establishment of a
repository of software components that can be easily used to quickly build
robotic solutions thus letting robot designers to focus only on personalising
robot’s behavior. Finally, rapid prototyping is not only a matter of software
but also of background knowledge. In fact, social robots need a wide range of
heterogeneous background knowledge for their tasks which should be available
for robots in the same way as software components are available.

##  4 Architectural and Technological Choices

This section provides an overview of the principles that led the design of the
architecture. Firstly, we chose a robotic approach, namely behavioral
robotics, which we consider the most appropriate to fulfill the requirements
elicited in Section 3. Then, we select the architectural style, i.e. service
oriented architecture, which best fits with this robotic approach. Finally, we
develop the architecture by applying a set of architectural patterns (i.e.
reflection, hot deployment and black board) and by selecting the most suitable
technologies with respect to the requirements (semantic web, linked open
data). The remaining of this section briefly presents these principles and
motivates such choices.

##### Behavioral robotics.

Behavioral robotics Arkin1998 (3) is a robotic approach in which robot’s
behavior is built in a bottom-up fashion, starting from simple behaviors which
are the basic building blocks to realise robot’s behavior. Robot behaviors can
run in general simultaneously and are situated (i.e. do not need of complex
abstract world models to operate). Behavior-based robotics is mostly oriented
to reactive behaviors in which there is a direct coupling between sensors and
actuator.

The architecture presented in this article generalises the classic behavioral
robotics approach by combining output of sensors with (symbolic) knowledge of
the robot. Sensors’ data and symbolic knowledge are combined in symbolic rules
that activate robot’s behaviors (not directly actuators). This strategy
increases the customizability and personizability since the robot’s knowledge
base can store users’ preferences or habits that can be used to personalise
robot’s behavior. Moreover, since robots behaviors are activated by symbolic
rules they provide an explanation of the behavior thus favoring the
predictability. Finally, this approach enhance since rapid prototyping and
reusability since behaviors, implemented as modular software components, are
used as building blocks.

##### Service-Oriented Computing.

Service-Oriented Computing (SOC) Papazoglou2003 (68) is a computing paradigm
in which services are the fundamentals elements for developing applications.
Services are applications that perform certain functions. A service is  (i)
invocable through a platform (e.g. the Web);  (ii) self-contained;  (iii)
technology neutral;  (iv) and, its behavior is described by a formal
specification.  Services can be easily composed in order to realise composite
functions. These features make software-oriented architectures an ideal
candidate to implement an architecture inspired to behavioral robotics
principles. In this solution robots provide a platform able to host pluggable
applications that either realise a robotic behavior or offer some
functionality to other applications. Different benefits might be achieved
through the adoption of software oriented principles for designing robotic
software architectures.  (i) SOC’s neutrality with respect to a specific
technology guarantees interoperability of software components.  (ii)
Compositionality of services ensures the rapid development of robot’s
behaviors.

##### Hot Deployment.

Hot-deployable services Friese2004 (43) are services that can be added to or
removed on-the-fly from a running server. This mechanism allows to change what
is currently deployed on the platform without redeploying the whole platform.
In particular, hot deployment may enable software architectures of social
robots to be dinamically extended with new components or to easily customize
the deployed ones.

##### Reflection Pattern.

The Reflection pattern Smith1984 (76) provides a mechanism for dynamically
changing structure and behavior of systems. This pattern splits a system into
two parts. A meta level which provides information about system properties
that makes the system self-aware of its own structure and behavior. This
information is provided by the so-called metaobjects. A base level which
implements upon the meta level the application logic by using metaobjects to
remain independent with respect to it is likely to change. Therefore, any
changing in the metaobjects (i.e. changing of the meta level) will be
automatically and transparently reflected on the base level.

Behavior controllers of social robots may benefit of a reflection mechanism to
dinamically extend capabilities at runtime with no need of re-deploying the
whole architecture. In order to adopt this pattern the behavior controllers
need to provide:  (i) a meta level that should be aware of the robot’s
capabilities and should allow to dinamically add new robot’s abilities (i.e.
metaobjects) in form of software modules;  (ii) a base level that provides an
interface for users’ requests.  In this scenario user requests’ would be
transparently handled by using metaobjects. This solution would increase the
extensibility of the software architecture.

##### Blackboard Systems.

Blackboard systems Corkill1991 (27) are systems constituted by independent
components that cooperate to solve a problem using a blackboard (i.e. a shared
knowledge base) as workplace for developing the solution. In these systems
each component is specialized at solving a certain task of the overall problem
(this realizes what is called modularization of expertise). Components are
activated either when a change in the blackboard occurs (e.g. addition or
removal of information) or when they receive an external events. Components
are at same time contributors and beneficiary of the blackboard, namely, their
behavior is influenced by the status of blackboard and they record information
on the blackboard.

Software architectures of social robots may benefit of a blackboard-system-
like design for several reasons. With such an architecture software components
benefit from and contribute to robot’s knowledge hence making robot’s behavior
conditioned by its knowledge. Since changing robot’s knowledge would affect
its behavior, this kind of architecture would increase the robot’s
customizability, personizability, predicability and adaptability over the time
with respect to user’s habits and preferences. This solution also pushes
software components to adopt a shared data model, thus favoring the inner
syntactic and semantic interoperability at data level. Finally, modularization
is also enhanced so the rapid prototyping and the reusability of software
components.

##### Semantic Web and Linked Open Data.

The Semantic Web Berners-Lee2001 (15) is an extension of the Web aims at
providing a set of standards that allows data to be shared and reused across
application boundaries. The Semantic Web standards mainly include: XML which
is a uniform data-exchange format thus providing a common syntax for exchange
data; RDF111RDF, W3C Recommendation https://www.w3.org/TR/rdf11-concepts/ is a
framework for modelling information in form of triples (i.e. subject,
predicate, object); RDFs222RDFs, W3C Recommendation https://www.w3.org/TR/rdf-
schema/ provides a data-modelling vocabulary for RDF data; OWL333OWL, W3C
Recommendation https://www.w3.org/TR/owl-ref/ adds constructs for describing
properties and classes: among others, relations between classes (e.g.
disjointness), cardinality (e.g. “exactly one”), equality, richer typing of
properties, characteristics of properties (e.g. symmetry), and enumerated
classes; SPARQL444SPARQL, W3C Recommendation https://www.w3.org/TR/rdf-sparql-
query/ is a query language for retrieving and manipulating data store in RDF
format. Linked Data is structured data that is shared across the internet
using Semantic Web standards. Linked data distributed with an open licence are
called Linked Open Data (LOD).

Robots’ architectures can profoundly benefit of Semantic Web technologies and
Linked Open Data paradigm.  (i) Semantic Web standards allow to easily
integrate data generated by the software components thus favoring the inner
interoperabilty of the software architecture.  (ii) Semantic Web standards
favor the the predictability of the robot.  (iii) Linked Data provides a
mechanism that allows robots to mutually share knowledge, thus increasing
outer interoperability.  (iv) Linked Open Data paradigm lets to easily reuse
existing external datasets so to bootstrap knowledge base with relevant
information for robots’ activities, and consequently enabling a rapid
prototyping of robotic applications.

##  5 Architecture Design

In order to enhance the separation of concerns among components, the software
architecture has been organised into four concentric layers. These layers are
complemented by a cross-layers group of components that provide architecture
with hot-deploy support. Software components on a layer use components of its
nested layers. The outermost layer (i.e. Behaviors) acts as interface with the
robot’s users and the environment. Every layer can exist without the layers
above it, and requires the layers inside it to function. Differently, the
layer supporting the hot-deploy mechanism is used by its adjacent layers.
Figure 2 depicts the architecture layering. This section provide an overview
of the different concerns of the levels.

The base layer is made up of the robot’s knowledge and the bus sub-levels
which constitute the blackboard of the system. Software components may use
knowledge base to store persistent information and the semantic bus to
asynchronously exchange messages or to generate and react to events. Each of
these sub-levels is split into two sub-levels, one providing the resources to
be accessed (i.e. the knowledge base and the semantic bus) and the other
providing the APIs to access to them. The access to blackboard level is
guaranteed by the object-ontology mapping API, which provides software
components with facilities for accessing the knowledge base, and the semantic
bus API that allows components to create, subscribe to, or publish messages on
a message queue (or topic).

Looking at the higher levels, software components are classified into
behaviors and capabilities. We define capabilities as software components that
give to robots human-like abilities such as: listening, speaking,
understanding natural language, moving etc. These capabilities are typically
domain independent and therefore such components can be re-used in different
robotic applications. Similarly to Duffy2000 (35), capabilities we classify
into basic and convoluted capabilities. Basic capabilities include both the
robot primitive functionalities (e.g. reproducing or capturing sounds) and
basic platform services strongly related to the robot primitive
functionalities (e.g. speech recognition). Convoluted capabilities are higher
level functionalities (e.g. making phone calls) built on top of the basic
ones. From a developer point of view, both classes of capabilities correspond
to functionalities provided by the robot platform. The main difference between
these two classes is that convoluted capabilities are services that can be
included in the robotic platform at run-time using an hot-deploy mechanism,
whereas, since typically need of hardware devices, they can only be included
at design time.

Software components that belong to the behavior level are meant to implement
the high level behavior of the robot. The robot’s behaviors are defined as
sequences of actions performed by the robot in order to achieve a goal. An
example of behavior is “entertaining the user”. This behavior might involve a
series of actions such as: “approaching” and “dialoguing” to the user,
“showing” videos, “reproducing” music and so on. Actions requires some robot
capabilities like: “moving”, “speaking”, “listening”, “understanding”,
“showing images” and so on.

Except for the base layer and the basic capabilities, each level has its own
component that allow hot-deploy new components of the same level. This means
that architecture enables (at running-time) to deploy new robots behaviors,
new robot-capabilities (that do not require new hardware components) and to
extend the structure of the knowledge base by instantiating new ontology-
object mappers. This feature allows to incrementally develop the robot’s
architecture.

Figure 2: The layered structure of the software architecture. It is worth
noticing that the layering organization of the architecture reflects the
structure of the architecture presented in Figure 1. The mapping between the
two architectures is emphasized by layers’ colors.

###  5.1 Architectural Components

The Figure 3 shows the UML component diagram of the proposed architecture.
Each box represents a software component of the architecture. The assembly
connector bridges a component’s required interface, which is depicted as a
socket, with the provided interface of another component which is represented
by a ball. When the communication between the two components is asynchronous
(namely, it is mediated by the Semantic Bus), sockets and ball are gray-
highlighted. The rest of the section is dedicated to the presentation of the
design of the architecture and the description of its software components.

Figure 3: The UML component diagram of the software architecture for social
robots. The coloring of the components reflects the color of the layer which
the component belongs to, namely: Behavior and Behavior Manager belong to
Behaviors level (purple-colored); Text to Speech, Human Control Interface
Manager, Speech To Text, and Perception and Motion Controller are part of the
Capabilities level (red-colored); Object-Ontology Mapping Module and Knowledge
Base are two sub-levels of the knowledge level (yellow-colored) which together
with the semantic bus (light-blue-colored) constitute the base level; the
software components belonging providing hot-deploy support are green-colored.

###  5.2 Behaviors Layer

This section gives an overview of the behavior-based mechanism supported by
the proposed architecture. The Behaviors are software artifacts implementing
the high-level behavioral capabilities of the robot that are orchestrated and
coordinated by the Behavior Manager. Design and functionalities of these two
components is inspired to behavioral robotics principles.

####  5.2.1 Robot’s Behaviors

A Behavior is a software artifact that aims to realize a specific goal.
Examples of Behavior include “entertain the user”, “locate a user”, “take user
to a place” etc. A Behavior relies on perceptual capabilities of the robot
that provide sensor data, performs potentially complex processing (e.g.
involving retrieving knowledge from and adding knowledge to the knowledge
base), and controls robot’s actuators and devices in order to operate on the
environment and interact with the user. Each Behavior maintains and updates an
internal state, and it decides the actions to perform based on sensor data,
its state, the general state of the robot and its internal behavior-specific
logic.

The Behaviors expose an interface (i.e. the Behavior Control Interface) that
allows the Behavior Manager to control (i.e. start and stop) them. Moreover,
in order to implement an affordance-based behavior arbitration (the details of
this mechanism are provided in the next section), the Behavior Control
Interface allows the Behavior Manager to retrieve the situations that can be
managed by the Behavior. Using the Behavior Control Interface, the Task
Manager can also grants the access to robot’s capabilities to the Behaviors.
Once granted the use to robot’s capabilities:  (i) the Behavior can use the
interface provided by the Text To Speech component to make the robot speak;
(ii) by using HCI Manager Interface provided by the Human Control Interface
Manager, the Behaviors can show to users pictures and videos (if the robot is
equipped with a table) or to receive notifications when a button is pressed by
a user;  (iii) the Behavior can subscribe to the Speech to Text topic to
retrieve what the user says;  (iv) the Behavior can use the Perception and
Motion Controller Interface to retrieve sensor data, and make the robot move
in its operating environment.

The Behaviors are also able to store/retrieve knowledge from the Knowledge
Base through an Object-Ontology Mapping Module which is a RESTful service that
mediates CRUD (Create, Read, Update, Delete) operations on the Knowledge Base.
The Object-Ontology Mapping Module makes sure that the interaction with the
Knowledge Base complies with the ontology adopted by the Behavior. A Behavior
can also extend (at both intensional and extensional level) the Knowledge Base
by generating a new Object-Ontology Mapping Module with the Generate Object-
Ontology Mapping Module Interface. In other words, Behaviors adopt an ontology
to structure their data in the Knowledge Base, and, in order to interact with
the Knowledge Base they generate an Object-Ontology Mapping Module that
complies with the adopted ontology. This solution guarantees that Behaviors
are decoupled from the technology adopted for the Knowledge Base.

A Behavior can use robot’s convoluted capabilities. The architecture depicted
in Figure 3 shows a single Convoluted Capability Module which has to be
intended as a placeholder for any possible software components implementing a
capability. This module realizes an interface which is required by the
behavior. This interface provides has to expose capability-specific
functionalities that can be used by the Behaviors. A Behavior can also extend
robot’s convoluted capabilities by registering new components using the
Register Module Interface of the Convoluted Capability Manager. The new
Convoluted Capability Module is then deployed by the Hot-Deploy Manager and
becomes available to the other Behaviors.

Since Behaviors communicate with other components either through the Semantic
Bus or via REST APIs, there is no restriction on the technology to realise the
Behaviors. This solution increase the modularity of the architecture and,
since the architecture allows to deploy applications in any technology, it
favors the rapid prototyping of the robot.

Finally, it is worth noticing that the Supervisory Controller (cf. Section 2)
can be seen as a special Behavior that enable the remote control of the robot.

####  5.2.2 Behavior Manager

The Behavior Manager is a special Behavior that actively coordinates other
Behaviors and manages the functional capabilities of the robot. Once started
Behaviors use robot’s computational and sensor/actuator resources granted by
the Behavior manager to achieve their goal. Specifically, the Behavior Manager
is responsible for:

  1. 1.

Processing incoming data/events and reasoning over the actual state and
available knowledge in order to detect situations that require to activate a
Behavior;

  2. 2.

Coordinating, scheduling and prioritizing behavior execution;

  3. 3.

Activating, suspending, resuming and terminating Behaviors, as a result of a
continuous decision making process;

  4. 4.

Monitoring behaviors executions, to detect successful behavior completions as
well as abnormal terminations, failures and exceptions.

It is worth noticing that Behaviors and their manager implement the reflection
pattern where the Behavior Manager is the base level that processes data and
events, detects the situation the robot have to act, and activates the
Behaviors (i.e. meta-objects).

##### Behavior Arbitration Mechanism.

The Behavior Manager implements an hybrid strategy for arbitrating the
Behaviors (i.e. deciding which behavior to execute at each time). It
implements a purely reactive strategy through a collection of pre-programmed
event-condition-action rules. This strategy targets the most simple requests
which do not need to build and reason over a complex, abstract world models.
For example, let the user make a phone call or remembering the user to take
his pills does not require a complex control strategy. The purely reactive
strategy has proven to be effective for a variety of problems that can be
completely specified at design-time with simple rules Mataric1997 (64).
However, it is inflexible at running time due to its inability to store new
information in order to adapt the robot’s behavior on the basis of its
experience. Moreover, the burden of predicting all possible input states and
choosing the corresponding output actions is completely left to the designer.

An extension of this purely reactive strategy is a behavior-based approach
relying on the notion of affordance. The notion of affordance has been
introduced by Gibson Gibson1977 (46) who devised a theory of how animals
perceive opportunities for actions. Gibson called this opportunity affordance.
He suggested that the environment offers the agents (people or animals)
opportunities for actions. For instance, a door can have the affordance of
“openability”. The behavior arbitration strategy implemented by the Behavior
Manager exploits and goes beyond the notion of affordance introduced by
Gibson. This mechanism is based on the assumption that not only physical
objects, but also complex situations (e.g. the user wants to listen to some
music and the robot battery need to be charged) afford actions. More
precisely, in our model situations afford (i.e. contribute to select) robot’s
goals which are then pursued by behaviors which carry out a series of actions
to achieve the desired state of the world.

While a situation can be seen as the fullfilment of certain conditions at a
certain time, a goal can be interpreted as a certain state of the world the
robot desires to achieve. Both may involve temporal aspects (e.g. lunchtime
may afford the task remember the user to take the pills), the perception of
certain physical objects, the reception of a command (e.g. I want to listen to
some music), or, even the existence of certain state-of-affairs (e.g. the
situation the user is sitting on a chair for a long while may afford the task
entertain the user). The Behavior Manager continuously check the current state
of the world, and, whenever a condition is satisfied, it retrieves the goals
afforded by the fulfilled situations, it selects one of these goals and it
then activates a behavior which synthesizes and execute a plan of how to
achieve that goal. The affordance relation connecting world’s situations with
robot’s goals can be stored in the knowledge base by using the Affordance
Ontology Design Pattern Asprino2017e (9). This relation can be personalised,
i.e. each robot may have its own affordances, and it may be adapted over time
to best fit with user preferences.

It is important to note that the arbitration mechanism provides the robot with
practical reasoning capabilities Bratman1987 (18) (intended as the “matter of
weighing conflicting considerations for and against competing options”). In
fact, a parallelism with Bratman’s BDI (Belief-Desire-Intention) model can be
done. The robot believes the facts stored in the knowledge base and the data
received from its sensors. It uses this information to figure out the current
state of the world and to deliberate what goals it desires to achieve. Then
the robot commits to the goal to achieve (i.e. intention) and builds a plan to
this end.

##### Hot-Deployment of Behaviors.

Moreover, the Behavior Manager provides the robot’s designers with the
functionalities for easily hot-deploying Behaviors on the architecture.
Particularly, this component enables the robot’s designers to choose which
Behaviors (possibly taken from a software repository) to equip the robot with.
The chosen Behaviors are then effectively installed on the architecture by the
Hot-Deploy Manager.

It is worth noting that the Behavior Manager guarantees the extensibility,
customizability and predictability of the robot’s behavior. The extensibility
is guaranteed by the fact that the architecture is open to new Behaviors that
can be dynamically added/removed at running time. In order to customize the
robot’s behavior a design just need to modify affordance relations stored in
the Knowledge Base. The robot’s behavior can be predicted from affordance
relations between situations and Behaviors.

###  5.3 Capabilities

We define capabilities as software components that give to robots human-like
abilities such as: listening, speaking, understanding natural language, moving
etc. These capabilities are typically domain independent and therefore such
components can be re-used in different robotic applications. Similarly to
Duffy2000 (35), capabilities we classify into basic (cf. Section 5.3.1) and
convoluted (cf. Section 5.4) capabilities.

####  5.3.1 Basic Capabilities

Basic capabilities include both the robot primitive functionalities (e.g.
reproducing or recording sounds) and basic platform services strictly related
to the robot primitive functionalities (e.g. speech recognition). These
capabilities are used by most of the robot Behaviors. This Section briefly
describes the components providing the basic robot capabilities. The
capabilities enabled by these components are the most significant with respect
to the requirements for a social robot (cf. Section 3.1 and 3.2) and that were
actually deployed on MARIO (cf. Section 6). The Section omits components
providing general purpose services (e.g. network connectivity).

##### Text to Speech and Speech to Text.

The Text to Speech (T2S) component aims at converting natural language text
into speech. The T2T implements an interface that allows Behaviors to
synthesize and to reproduce synthesized speech. The Speech to Text (S2T)
component converts spoken language into digital-encoded text. The Speech to
Text component creates a topic for publishing the converted text and Behaviors
that need to recognize what users say will subscribe to this topic and they
will receive a message whenever the text is converted. Similarly, the
Behaviors that need to make the robot speak have to send a message to Text to
Speech message queue. The asynchronous interaction with these tools avoids the
Behaviors to busy wait until a new utterance is converted to text (or vice
versa) and it decouples the Behaviors from the tools actually used for T2S and
S2T.

##### Human Control Interface Manager.

Most of the social robots are equipped with some control buttons (e.g.
emergency button) and one or more (touch-)screens in order to complete the
message conveyed by verbal communication The joint use of verbal and visual
language for human computer interaction falls into the broader category of
multi-modal human-computer interaction. This architecture supports a bi-modal
interaction involving a both verbal and visual language. The verbal
communication relies on T2S and S2T components, whereas visual communication
is ensured by the Graphical User Interface Manager. The Human Control
Interface (HCI) Manager component aims at providing Behaviors with facilities
for managing the robot’s human control interfaces like buttons or tablets. The
component realizes an interface (i.e. the HCI Manager Interface) that allows
Behaviors to show widgets on the screen or to receive a feedback whenever the
user interact with such widgets or a control button. Similarly to S2T and T2T
components, the Behaviors communicate with the HCI Manager through the
Semantic Bus. The use of a standardized HCI Manager within robotics software
architecture may standardise the interaction between HCIs and behavior thus
increasing the interoperability and the reusability of software components,
and favoring the rapid prototyping.

##### Perception and Motion Controller.

The Perception and Motion Controller provides functional capabilities for
supporting human-robot interactions. It includes a set of software routines
that enable the robot to perform a series of motion routines (e.g.,
approaching the user, following the user, recharging, driving the user to a
destination, etc.). The Perception and Motion Controller Interface also
provides Behaviors with the access to data coming from several sensors such
as:  (i) RFIDin order to detect a list of tagged objects;  (ii) Camerato
detect user using face and posture recognition and extract his relative
position and distance;  (iii) Laserto perceive and identify dynamic
objects/persons that were not included in the static map (SLAM system).
Finally, this component provides Behaviors with high-level functionalities
such as: go to X (where X is a point within the robot’s operating area), give
me user’s position, give me the tagged objects that are located by the RFID
etc. As for the other components providing basic capabilities, the Perception
and Motion Controller communicates with the Behaviors through the Semantic
Bus. This solution would increase modularity and interoperability of the
software components thus favoring the rapid prototyping.

###  5.4 Convoluted Capabilities

Most of the software applications (not only the robotics ones) that have a
natural language interaction with users rely on (general purpose) NLP services
to interpret and to reply to users’ utterances. We call this kind of services
Convoluted Capabilities. These services may require non-negligible
computational resources therefore it is desirable to optimise their use as
much as possible, in other words, the Behaviors should be enabled to share
these services instead of re-instantiating them. To this end we have
replicated at the capability level the same architectural pattern seen at
behavioral level involving a component (i.e. the manager) that use the Hot-
Deploy manager to dynamically deploy a new software component. Specifically,
Convoluted Capabilities are services that can be dynamically included in the
robotic platform at running time. The new capabilities can be installed by the
Behaviors that intend to make available new functionalities for other
Behaviors. The Convoluted Capability Manager is responsible for the dynamic
deployment of new capability components. It realizes an interface (i.e.
“Register Module Interface”) which accepts as input an application module
realizing the new capability to deploy. Once received a module, the Convoluted
Capability Manager uses the Hot-Deploy Manager to install the module.

###  5.5 Knowledge Management Framework

This Section presents the architectural components responsible for the
management of the robot’s knowledge. The Knowledge Management Framework
consists of two components, namely the Knowledge Base and the Object-Ontology
Mapping Module.

##### Knowledge Base.

The Knowledge Base is the component intended to store the robot’s knowledge in
a structured format. The reference data model for the Knowledge Base is
RDF555RDF 1.1 Concepts and Abstract Syntax,
https://www.w3.org/TR/rdf11-concepts/ which is the standard data model adopted
in the Semantic Web. In our architectural model the Knowlede Base provides
facilities that allow to create, read, updated, and delete facts. The
Knowledge Base doesn’t have a predefined and fixed schema, but it is defined
by the Behaviors. Finally, the Knowledge Base component also includes a
reasoning engine that is able to infer logical consequences (i.e. entailed
facts). It is worth noticing that the adoption of RDF as reference data model
increase the interoperability with other Semantic Web compliant systems, and,
since it enables the reuse of Linked Open Data datasets, RDF favors also the
rapid prototyping.

##### Object-Ontology Mapping Module.

An Object-Ontology Mapping Module is a REST service that provides software
components with the access to the Knowledge Base. Given an ontology as input,
Object-Ontology Mapping Manager generates an a module that provides software
components with REST APIs for accessing the RDF facts stored in the Knowledge
Base in a way that:  (i) reflects the semantics of the ontology,  (ii) and,
follows the Object-Oriented paradigm.  It is easy to recognize the Hot-
Deployment pattern already seen for Behaviors and Convoluted Capabilities. The
Object-Ontology Mapping paradigm avoids software components to deal with OWL
and RDF or to interact with a knowledge base by means of SPARQL queries. The
Object-Ontology Mapping solution, rather than a direct access to the Knowledge
Base, aims to increase the decoupling between the Behaviors and the Knowledge
Base.

###  5.6 Semantic Bus

The Semantic Bus is meant to provide the architecture’s components with
message-based asynchronous communication mechanism that follows the publish-
subscribe paradigm. The Message Broker exposes two interfaces, namely:  (i)
the Topic Management Interface which allows software components to create new
topics (also called messages queues);  (ii) the Publish/Subscribe Interface
which allows software components to publish messages on/subscribing to a
topic.  The asynchronous communication mechanism increases the decoupling
among software components.

###  5.7 Hot-Deploy Manager

The Hot-Deploy Manager allows to extend the architecture by dynamically
deploying new software components. The Hot-Deploy Manager aims at providing an
OSGi-like666OSGi, https://www.osgi.org/ platform for the robot’s software
architecture enabling a dynamic component model. In OSGi applications coming
in the form of bundles777Bundle is a term borrowed from Java-based platforms.
A bundle is defined as a group of Java classes and additional resources
equipped with a detailed manifest file. for deployment, can be installed,
started, stopped, updated, and uninstalled without requiring a reboot. These
features ensure the flexibility and the extensibility of the software
architecture.

##  6 Case Study

A case study for this work has been provided by the H2020 European Project
MARIO888MARIO project, http://www.mario-project.eu/portal/ Mannion2019 (63).
This project has investigated the use of autonomous companion robots as
cognitive stimulation tool for people with dementia. The MARIO robot and its
abilities were specifically designed to provide support to people with
dementia, their caregivers, and related healthcare professionals. Among its
abilities, MARIO can help caregivers in the patient assessment process by
autonomously performing Comprehensive Geriatric Assessment (CGA) evaluations,
it is able to deliver reminiscence therapy through personalized interactive
sessions and to entertain its users by playing music or making them reading
newspapers or playing videogames. The overall framework has been deployed on
Kompaï-2 robots (showed in Figure 4), evaluated and validated during
supervised trials in different dementia care environments, including a nursing
home (Galway, Ireland), community groups (Stockport, UK) and a geriatric unit
in hospital settings (San Giovanni Rotondo, Italy).

Figure 4: The Kompaï-2 robot.

The architecture proposed in this article is a generalization of the MARIO
software architecture. Specifically, examples of Behaviors in MARIO’s
architecture are CGA Asprino2017b (6) and Reminiscence Asprino2017d (8)
applications. These applications use MARIO’s Basic Capabilities made available
through the integration of commercially available tools such as Nuance Dragon
Naturally Speaking for the Speech to Text Component, Google Speech to Text
APIs, and Karto999https://wiki.ros.org/karto as motion control system. Other
customised Basic Capabilities were introduced to let Behaviors easily control
the robot’s GUI interface. Behaviors share Convoluted Capabilities providing
common NLP services (e.g. Stanford’s CoreNLP Manning2014 (62)) for dialoguing
with users Russo2019 (73). Behaviors and Capabilities rely on a Knowledge
Management Framework Asprino2019g (4, 7) consisting of a triple store
(accessible through Apache Jena101010https://jena.apache.org/ and initially
populated with Linguistic and Common Sense Knowledge Asprino2018a (5, 45)) and
an Object-Ontology Mapper called
Lizard111111https://github.com/anuzzolese/lizard Asprino2019g (4). Finally,
the Semantic Bus is based on the Event Admin Service provided by Apache
Felix121212https://felix.apache.org/ which also provides the OSGi
implementation that enables the Hot-Deploy mechanism.

##  7 Conclusions and Future Work

This paper has focussed on how a design based on a reference software
architecture can mitigate challenges in social robotics, such as improving
acceptability, trust of robots, and guaranteeing that robots establish a
personalised relationship with their users. We have adopted a bottom-up
approach for defining general architectural requirements starting from
specific use cases defined in the context of MARIO, a Socially Assistive
Robotics project funded by the EU, and then generalizing them. These
requirements led us to the selection of a set of technologies, architectural
styles and patterns, that Social Robotics architectures may benefit from. We
remark that non-functional requirements and principles have guided the design
of the architecture. The reference architecture introduces a series of
standardised software components that are meant to increase the extensibility,
customizability, predicatability, interoperability of the software
architecture as well as to favor the rapid prototying of the Social Robotics
solutions.

The ultimate goal of this work is to establish a common open-ended software
architecture so to encourage the development of standardised software
components whose Social Robots can benefit from. As shown by the use case
presented in Section 6, many of these components can be provided by off-the-
shelf software tools or are available as research prototypes. However, even if
these components are available, they need to be adapted (or wrapped) in order
to be integrated in the architecture (to this end the Adapter Pattern
Gamma1994 (44) can be considered). Others, especially the components
responsible for the hot-deployment mechanism, need to be implemented from
scratch. In addition to the development of new components, it is also
necessary to define a set of standard protocols that let components
communicate. On the basis of the experience in the presented case study we are
implementing a proof-of-concept of the architecture. Particularly, we are
generalising protocols used in the MARIO architecture and we are developing an
affordance-inspired Behavior Manager. Finally, we plan to explore the
possibility of enhancing the autonomy of robot by design. To this end an
autonomic computing solution Kephart2003 (56) is being considered in order to
endow the robot with self-configuration, self-optimization, self-healing and
self-protection capabilities.

###### Acknowledgements.

The research leading to these results has received funding from the European
Union Horizons 2020 the Framework Programme for Research and Innovation
(2014-2020) under grant agreement 643808 Project MARIO “Managing active and
healthy aging with use of caring service robot”.

## References

  * (1) Aakash Ahmad and Muhammad Ali Babar  “Software architectures for robotic systems: A systematic mapping study”  In _Journal of Systems and Software_ 122, 2016, pp. 16–39  DOI: 10.1016/j.jss.2016.08.039
  * (2) Fahad Alaieri and André Vellino  “Ethical Decision Making in Robots: Autonomy, Trust and Responsibility - Autonomy Trust and Responsibility”  In _Proceedings of the 8th International Conference on Social Robotics (ICSR 2016)_ , 2016, pp. 159–168  DOI: 10.1007/978-3-319-47437-3“˙16
  * (3) Ronald C. Arkin  “Behavior-based robotics”  MIT press, 1998
  * (4) Luigi Asprino  “Engineering Background Knowledge for Social Robots”, 2019  URL: http://amsdottorato.unibo.it/9020/
  * (5) Luigi Asprino, Valerio Basile, Paolo Ciancarini and Valentina Presutti  “Empirical Analysis of Foundational Distinctions in Linked Open Data”  In _Proceedings of the 27th International Joint Conference on Artificial Intelligence and the 23rd European Conference on Artificial Intelligence (IJCAI-ECAI 18)_ International Joint Conferences on Artificial Intelligence, 2018, pp. 3962–3969  DOI: 10.24963/ijcai.2018/551
  * (6) Luigi Asprino et al.  “Autonomous Comprehensive Geriatric Assessment”  In _Proceedings of the 1st International Workshop on Application of Semantic Web technologies in Robotics co-located with 14th ESWC (ANSWER 2017)_ , 2017, pp. 41–45
  * (7) Luigi Asprino et al.  “A Knowledge Management System for Assistive Robotics”  In _Proceedings of the 1st International Workshop on Application of Semantic Web technologies in Robotics co-located with 14th ESWC (ANSWER 2017)_ , 2017, pp. 46–50
  * (8) Luigi Asprino et al.  “Knowledge-driven Support for Reminiscence on Companion Robots”  In _Proceedings of the 1st International Workshop on Application of Semantic Web technologies in Robotics co-located with 14th ESWC (ANSWER 2017)_ , 2017, pp. 51–55
  * (9) Luigi Asprino et al.  “An Ontology Design Pattern for supporting behaviour arbitration in cognitive agents”  In _Advances in Ontology Design and Patterns_ IOS Press, 2017, pp. 85–95
  * (10) Rachel Bailey, Kevin Wise and Paul Bolls  “How avatar customizability affects children’s arousal and subjective presence during junk food–sponsored online video games”  In _Cyber Psychology & Behavior_ 12.3, 2009, pp. 277–283
  * (11) Ramon Barber and Miguel A Salichs  “A new human based architecture for intelligent autonomous robots”  In _Proceedings of the Fourth IFAC Symposium on Intelligent Autonomous Vehicles_ , 2001, pp. 85–90
  * (12) Christoph Bartneck and Jodi Forlizzi  “A design-centred framework for social human-robot interaction”  In _Proceedings of the 13th IEEE International Workshop on Robot and Human Interactive Communication (ROMAN 2004)_ , 2004, pp. 591–594  IEEE
  * (13) Christoph Bartneck and Jun Hu  “Rapid prototyping for interactive robots”  In _Proceedings of the 8th Conference on Intelligent Autonomous Systems (IAS-8)_ , 2004, pp. 136–145
  * (14) “Proceedings of the 1st International Workshop on Application of Semantic Web technologies in Robotics co-located with 14th ESWC (ANSWER 2017)”  In _Proceedings of the 1st International Workshop on Application of Semantic Web technologies in Robotics co-located with 14th ESWC (ANSWER 2017)_ , 2017
  * (15) Tim Berners-Lee, James Hendler and Ora Lassila  “The semantic web”  In _Scientific american_ 284.5, 2001, pp. 34–43
  * (16) David L. Bisset  “D1.1 MARIO System Specification for Pilot 1”, 2015  URL: http://www.mario-project.eu/portal/images/deliverables/D1.1-MARIO-System-Specification-for-Pilot%201.pdf
  * (17) Manuele Bonaccorsi et al.  “A Cloud Robotics Solution to Improve Social Assistive Robots for Active and Healthy Aging”  In _International Journal of Social Robotics_ 8.3, 2016, pp. 393–408  DOI: 10.1007/s12369-016-0351-1
  * (18) Michael Bratman  “Intention, plans, and practical reason”  Harvard University Press Cambridge, MA, 1987
  * (19) Cynthia Breazeal  “Toward sociable robots”  In _Robotics and Autonomous Systems_ 42.3, 2003, pp. 167–175  DOI: 10.1016/S0921-8890(02)00373-1
  * (20) Cynthia Lynn Breazeal  “Sociable machines: Expressive social exchange between humans and robots”, 2000
  * (21) Joost Broekens, Marcel Heerink and Henk Rosendal  “Assistive social robots in elderly care: a review”  In _Gerontechnology_ 8.2, 2009, pp. 94–103
  * (22) Lola Canamero and Jakob Fredslund  “I Show You How I Like You: Emotional Human-Robot Interaction through Facial Expression and Tactile Stimulation”  In _IEEE Transactions on Systems, Man, and Cybernetics - Part A: Systems and Humans_ 31.5, 2001, pp. 454–459  DOI: 10.1109/3468.952719
  * (23) Hoang-Long Cao et al.  “A platform-independent robot control architecture for multiple therapeutic scenarios”  In _Proceedings of 5th International Symposium on New Frontiers in Human-Robot Interaction (NF-HRI 2016)_ The Association for Computer Linguistics, 2016
  * (24) Hoang-Long Cao et al.  “A Personalized and Platform-Independent Behavior Control System for Social Robots in Therapy: Development and Applications”  In _IEEE Transactions on Cognitive and Developmental Systems_ 11.3, 2019, pp. 334–346  DOI: 10.1109/TCDS.2018.2795343
  * (25) Jonathan Casas et al.  “Architecture for a social assistive robot in cardiac rehabilitation”  In _Proceedings of the IEEE 2nd Colombian Conference on Robotics and Automation (CCRA 2018)_ , 2018, pp. 1–6
  * (26) Abdelghani Chibani et al.  “Ubiquitous robotics: Recent challenges and future trends”  In _Robotics and Autonomous Systems_ 61.11, 2013, pp. 1162–1172  DOI: 10.1016/j.robot.2013.04.003
  * (27) Daniel D Corkill  “Blackboard systems”  In _AI Expert_ 6.9 Citeseer, 1991, pp. 40–47
  * (28) Serhan Coşar et al.  “ENRICHME: Perception and Interaction of an Assistive Robot for the Elderly at Home”  In _International Journal of Social Robotics_ Springer, 2020, pp. 1–27  DOI: 10.1007/s12369-019-00614-y
  * (29) Kerstin Dautenhahn  “Getting to know each other - Artificial social intelligence for autonomous robots”  In _Robotics and Autonomous Systems_ 16.2-4, 1995, pp. 333–356  DOI: 10.1016/0921-8890(95)00054-2
  * (30) Kerstin Dautenhahn  “The art of designing socially intelligent agents: Science, fiction, and the human in the loop”  In _Applied artificial intelligence_ 12.7-8, 1998, pp. 573–617
  * (31) Kerstin Dautenhahn and Thomas Christaller  “Remembering, rehearsal and empathy-towards a social and embodied cognitive psychology for artifacts”  In _Two sciences of the mind. Readings in cognitive science and consciousness_ North America Inc., 1995, pp. 257–282
  * (32) Kerstin Dautenhahn, Bernard Ogden and Tom Quick  “From embodied to socially embedded agents - Implications for interaction-aware robots”  In _Cognitive Systems Research_ 3.3, 2002, pp. 397–428  DOI: 10.1016/S1389-0417(02)00050-5
  * (33) Pegah Soleimman Dehkordi, Hadi Moradi, Maryam Mahmoudi and Hamid Reza Pouretemad  “The Design, Development, and Deployment of RoboParrot for Screening Autistic Children”  In _Interantional Journal of Social Robotics_ 7.4, 2015, pp. 513–522  DOI: 10.1007/s12369-015-0309-8
  * (34) Andrew Dillon  “User acceptance of information technology”  In _Encyclopedia of human factors and ergonomics_ , 2001
  * (35) Brian R. Duffy  “The Social Robot”, 2000
  * (36) Brian R. Duffy  “Anthropomorphism and the social robot”  In _Robotics and Autonomous Systems_ 42.3, 2003, pp. 177–190  DOI: 10.1016/S0921-8890(02)00374-3
  * (37) Brian R. Duffy, Gina Joue and John Bourke  “Issues in assessing performance of social robots”  In _Proceedings of the 2nd WSEAS International Conference (RODLICS 2002)_ , 2002
  * (38) Brian R. Duffy, Colm Rooney, Greg MP O’Hare and Ruadhan O’Donoghue  “What is a Social Robot?”  In _Proceedings of the 10th Irish Conference on Artificial Intelligence & Cognitive Science_, 1999
  * (39) Jing Fan et al.  “A Robotic Coach Architecture for Elder Care (ROCARE) Based on Multi-User Engagement Models”  In _IEEE Transactions on Neural Systems and Rehabilitation Engineering_ 25.8, 2017, pp. 1153–1163  DOI: 10.1109/TNSRE.2016.2608791
  * (40) Juan Fasola and Maja J. Matarić  “A Socially Assistive Robot Exercise Coach for the Elderly”  In _Journal of Human-Robot Interaction_ 2.2, 2013, pp. 3–32  DOI: 10.5898/JHRI.2.2.Fasola
  * (41) David Fischinger et al.  “Hobbit, a care robot supporting independent living at home: First prototype and lessons learned”  In _Robotics and Autonomous Systems_ 75, 2016, pp. 60–78  DOI: 10.1016/j.robot.2014.09.029
  * (42) Terrence Fong, Illah R. Nourbakhsh and Kerstin Dautenhahn  “A survey of socially interactive robots”  In _Robotics and Autonomous Systems_ 42.3-4, 2003, pp. 143–166  DOI: 10.1016/S0921-8890(02)00372-X
  * (43) Thomas Friese, Matthew Smith and Bernd Freisleben  “Hot service deployment in an ad hoc grid environment”  In _Proceedings of the 2nd International Conference of Service-Oriented Computing (ICSOC 2004)_ , 2004, pp. 75–83  DOI: 10.1145/1035167.1035179
  * (44) Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides  “Design Patterns: Elements of Reusable Object-Oriented Software”  Addison-Wesley
  * (45) Aldo Gangemi et al.  “Framester: A Wide Coverage Linguistic Linked Data Hub”  In _Proceedings of the 20th International Conference on Knowledge Engineering and Knowledge Management (EKAW 2016)_ Springer International Publishing, 2016, pp. 239–254  DOI: 10.1007/978-3-319-49004-5˙16
  * (46) James Gibson  “The theory of affordances”  In _Perceiving, acting, and knowing: Toward an ecological psychology_ Lawrence Erlbaum Associates, 1977, pp. 67–82
  * (47) Víctor González-Pacheco et al.  “Maggie: A Social Robot as a Gaming Platform”  In _Interantional Journal of Social Robotics_ 3.4, 2011, pp. 371–381  DOI: 10.1007/s12369-011-0109-8
  * (48) Goren Gordon et al.  “Affective personalization of a social robot tutor for children’s second language skills”  In _Proceedings of the 30th AAAI Conference on Artificial Intelligence (AAAI 2016)_ , 2016
  * (49) Horst-Michael Gross et al.  “I’ll keep an eye on you: Home robot companion for elderly people with cognitive impairment”  In _Proceedings of the IEEE International Conference on Systems, Man, and Cybernetics_ , 2011, pp. 2481–2488  DOI: 10.1109/ICSMC.2011.6084050
  * (50) Horst-Michael Gross et al.  “Further progress towards a home robot companion for people with mild cognitive impairment”  In _Proceedings of the IEEE International Conference on Systems, Man, and Cybernetics (SMC 2012)_ , 2012  DOI: 10.1109/ICSMC.2012.6377798
  * (51) Jochen Hirth, Norbert Schmitz and Karsten Berns  “Towards Social Robots: Designing an Emotion-Based Architecture”  In _International Journal of Social Robotics_ 3.3, 2011, pp. 273–290  DOI: 10.1007/s12369-010-0087-2
  * (52) “Human–robot interaction: a survey”  In _Foundations and Trends in Human–Computer Interaction_ 1.3, 2008, pp. 203–275  DOI: 10.1561/1100000005
  * (53) Chandimal Jayawardena, I-Han Kuo, Elizabeth Broadbent and Bruce A. MacDonald  “Socially Assistive Robot HealthBot: Design, Implementation, and Field Trials”  In _IEEE Systems Journal_ 10.3, 2016, pp. 1056–1067  DOI: 10.1109/JSYST.2014.2337882
  * (54) John F. Kelley  “An Iterative Design Methodology for User-Friendly Natural Language Office Information Applications”  In _ACM Transactions on Information Systems_ 2.1, 1984, pp. 26–41  DOI: 10.1145/357417.357420
  * (55) James Kennedy, Aditi Ramachandran, Brian Scassellati and Fumihide Tanaka  “Social robots for education: A review”  In _Science Robotics_ 3.21, 2018  DOI: 10.1126/scirobotics.aat5954
  * (56) Jeffrey O. Kephart and David M. Chess  “The Vision of Autonomic Computing”  In _IEEE Computer_ 36.1, 2003, pp. 41–50  DOI: 10.1109/MC.2003.1160055
  * (57) Jong-Hwan Kim, In-Bae Jeong, In-Won Park and Kang-Hee Lee  “Multi-Layer Architecture of Ubiquitous Robot System for Integrated Services”  In _Interantional Journal of Social Robotics_ 1.1, 2009, pp. 19–28  DOI: 10.1007/s12369-008-0005-z
  * (58) Benjamin Kuipers  “How can we trust a robot?”  In _Communications of the ACM_ 61.3, 2018, pp. 86–95  DOI: 10.1145/3173087
  * (59) M.. Lee et al.  “Personalization in HRI: A longitudinal field experiment”  In _Proceedings of the 7th ACM/IEEE International Conference on Human-Robot Interaction (HRI)_ , 2012, pp. 319–326
  * (60) Wing-Yue Geoffrey Louie and Goldie Nejat  “A Social Robot Learning to Facilitate an Assistive Group-Based Activity from Non-expert Caregivers”  In _International Journal of Social Robotics_ Springer, 2020, pp. 1–18  DOI: 10.1007/s12369-020-00621-4
  * (61) Wing-Yue Geoffrey Louie, Tiago Stegun Vaquero, Goldie Nejat and J. Beck  “An autonomous assistive robot for planning, scheduling and facilitating multi-user activities”  In _Proceedings of the IEEE International Conference on Robotics and Automation (ICRA 2014)_ , 2014, pp. 5292–5298  DOI: 10.1109/ICRA.2014.6907637
  * (62) Christopher D. Manning et al.  “The Stanford CoreNLP Natural Language Processing Toolkit”  In _Proceedings of the 52nd Annual Meeting of the Association for Computational Linguistics (ACL 2014)_ , 2014, pp. 55–60  DOI: 10.3115/v1/p14-5010
  * (63) Arlene Mannion et al.  “Introducing the social robot MARIO to people living with dementia in long term residential care: Reflections”  In _International Journal of Social Robotics_ Springer, 2019, pp. 1–13
  * (64) Maja J. Mataric  “Behaviour-based control: examples from navigation, learning, and group behaviour”  In _Journal of Experimental & Theoretical Artificial Intelligence_ 9.2-3, 1997, pp. 323–336  DOI: 10.1080/095281397147149
  * (65) Victor Mayoral et al.  “The shift in the robotics paradigm The Hardware Robot Operating System (H-ROS); an infrastructure to create interoperable robot components”  In _Proceedings of the NASA/ESA Conference on Adaptive Hardware and Systems (AHS 2017)_ , 2017, pp. 229–236
  * (66) Ross Mead et al.  “An architecture for rehabilitation task practice in socially assistive human-robot interaction”  In _Proceedings of 19th IEEE International Conference on Robot and Human Interactive Communication (RO-MAN 2010)_ IEEE, 2010, pp. 404–409  DOI: 10.1109/ROMAN.2010.5598666
  * (67) Tetsuya Ogata and Shigeki Sugano  “Emotional communication robot: WAMOEBA-2R emotion model and evaluation experiments”  In _Proceedings of the International Conference on Humanoid Robots_ , 2000
  * (68) Mike P. Papazoglou  “Service-oriented computing: concepts, characteristics and directions”  In _Proceedings of the 4th International Conference on Web Information Systems Engineering (WISE 2003)_ , 2003, pp. 3–12  DOI: 10.1109/WISE.2003.1254461
  * (69) Kai Petersen, Robert Feldt, Shahid Mujtaba and Michael Mattsson  “Systematic Mapping Studies in Software Engineering”  In _Proceedings of the 12th International Conference on Evaluation and Assessment in Software Engineering (EASE 2008)_ , 2008
  * (70) David Portugal et al.  “A Study on the Deployment of a Service Robot in an Elderly Care Center”  In _International Journal of Social Robotics_ 11.2, 2019, pp. 317–341  DOI: 10.1007/s12369-018-0492-5
  * (71) Morgan Quigley et al.  “ROS: an open-source Robot Operating System”  In _Proceedings of the Workshop on Open Source Software in Robotics co-located with ICRA_ 3.3.2, 2009, pp. 5
  * (72) Laurel D. Riek  “Wizard of Oz Studies in HRI: A Systematic Review and New Reporting Guidelines”  In _Journal of Human-Robot Interaction_ 1.1, 2012, pp. 119–136  DOI: 10.5898/JHRI.1.1.Riek
  * (73) Alessandro Russo et al.  “Dialogue Systems and Conversational Agents for Patients with Dementia: The Human–Robot Interaction”  In _Rejuvenation research_ 22.2, 2019, pp. 109–120  DOI: 10.1089/rej.2018.2075
  * (74) Miguel Sarabia, Raquel Ros and Yiannis Demiris  “Towards an open-source social middleware for humanoid robots”  In _Proceedings of the 11th IEEE-RAS International Conference on Humanoid Robots (Humanoids 2011)_ , 2011, pp. 670–675  DOI: 10.1109/Humanoids.2011.6100883
  * (75) Chao Shi, Satoru Satake, Takayuki Kanda and Hiroshi Ishiguro  “A Robot that Distributes Flyers to Pedestrians in a Shopping Mall”  In _International Journal of Social Robotics_ 10.4, 2018, pp. 421–437  DOI: 10.1007/s12369-017-0442-7
  * (76) Brian Cantwell Smith  “Reflection and semantics in Lisp”  In _Proceedings of the 11th ACM SIGACT-SIGPLAN symposium on Principles of programming languages_ , 1984, pp. 23–35
  * (77) Elena Torta et al.  “Evaluation of a Small Socially-Assistive Humanoid Robot in Intelligent Homes for the Care of the Elderly”  In _Journal of Intelligent and Robotic Systems_ 76.1, 2014, pp. 57–71  DOI: 10.1007/s10846-013-0019-0
  * (78) Pinar Uluer, Neziha Akalin and Hatice Köse  “A New Robotic Platform for Sign Language Tutoring - Humanoid Robots as Assistive Game Companions for Teaching Sign Language”  In _Interantional Journal of Social Robotics_ 7.5, 2015, pp. 571–585  DOI: 10.1007/s12369-015-0307-x
  * (79) Alan Richard Wagner  “The role of trust and relationships in human-robot social interaction”, 2009
  * (80) Peter Wegner  “Interoperability”  In _ACM Computing Surveys (CSUR)_ 28.1 ACM New York, NY, USA, 1996, pp. 285–287
  * (81) Jey Won, Kathryn J. Laurentis and Constantinos Mavroidis  “Rapid Prototyping of Robotic Systems”  In _Proceedings of th IEEE International Conference on Robotics and Automation, (ICRA)_ , 2000, pp. 3077–3082  DOI: 10.1109/ROBOT.2000.845136
  * (82) Luke J Wood, Abolfazl Zaraki, Ben Robins and Kerstin Dautenhahn  “Developing kaspar: a humanoid robot for children with autism”  In _International Journal of Social Robotics_ Springer, 2019, pp. 1–18  DOI: 10.1007/s12369-019-00563-6
  * (83) Haibin Yan, Marcelo H. Jr. and Aun Neow Poo  “A Survey on Perception Methods for Human-Robot Interaction in Social Robots”  In _International Journal of Social Robotics_ 6.1, 2014, pp. 85–119  DOI: 10.1007/s12369-013-0199-6
  * (84) Ahmad Zibafar et al.  “State-of-the-Art Visual Merchandising Using a Fashionable Social Robot: RoMa”  In _International Journal of Social Robotics_ Springer, 2019, pp. 1–15  DOI: 10.1007/s12369-019-00566-3