Future Generation Computer Systems 74 (2017) 337348

Contents lists available at ScienceDirect

Future Generation Computer Systems

journal homepage: www.elsevier.com/locate/fgcs

Robot Cloud: Bridging the power of robotics and cloud computing

Zhihui Du a, , Ligang He b , Yinong Chen c , Yu Xiao d , Peng Gao d , Tongzhou Wang d
a
Tsinghua National Laboratory for Information Science and Technology, Department of Computer Science and Technology, Tsinghua University, Beijing
100084, China
b
Department of Computer Science, University of Warwick, United Kingdom
c
School of Computing, Informatics & Decision Systems Eng, Arizona State University, Tempe AZ85287, USA
d
Beijing University of Posts and Telecommunications, Beijing, 100876, China

highlights
The architecture design of a robot cloud is presented.
The simulation results show the advantage of our proposed scheduling algorithm and one big robot center.
The prototype system implementation shows the proposed idea is feasible and more such on-site services will be available in the future.

article info abstract

Article history: Cloud computing is shaping the cyber world and evolves as a key computing and service platform for
Received 16 September 2015 sharing resources including platforms, software applications and everything in the form of services. This
Received in revised form is known X as a Service. Although it brings our age unparalleled computing ability and economic
31 December 2015
benefits, the application of cloud computing is still limited currently in the cyberspace due to the cloud
Accepted 11 January 2016
Available online 21 January 2016
services can only reside in cloud instead of our daily life environment. In fact, there are still a plethora of
physical position based on-site service demands that cloud computing could help little due to the cyber
Keywords:
limitation. In this paper, we aim to integrate the cyber world and the physical world by bringing up
Service-oriented architecture (SOA) the idea of Robot Cloud to bridge the power of robotics and cloud computing. To make it possible, we
Cloud computing design a novel Robot Cloud stack to support our idea and adopt the service-oriented architecture (SOA) to
Robotics make the functional modules in the Robot Cloud more flexible, extensible and reusable. Then we develop
Robot Cloud a prototype of Robot Cloud using the popular Google App Engine to demonstrate our design method.
Robot as a Service (RaaS) Finally, we conduct the simulation experiments with a robot show application scenario to evaluate our
scheduling policy and identify the effect of different request distributions and robot center solutions.
2016 Elsevier B.V. All rights reserved.

1. Introduction
Computing has been viewed as resources by human beings and
used as the medium to build the powerful and versatile cyber
world. To date, the vast majority of the applications in the com-
puter technology are restricted to the interactions between human
beings and cyberspace. The typical exemplar applications of such
interactions include the Internet and the cloud computing technol-
ogy.
Almost all users of the Internet are using a form of cloud com-
puting [1] although they may not realize it. Cloud computing en-
Corresponding author.
E-mail address: duzh@tsinghua.edu.cn (Z. Du).
http://dx.doi.org/10.1016/j.future.2016.01.002
0167-739X/ 2016 Elsevier B.V. All rights reserved.
ables people to store and access personal files, such as music, pic-
tures, videos and bookmarks, to play games, and to use from any-
where the productivity applications deployed on remote servers
instead of physically carrying around a storage medium installed
with the applications.
As the cyber world mainly focuses on virtual applications and
as the requests for application in the real world grow beyond the
cyber domain, the existing cloud computing technology started to
become insufficient to address the richness of the requests from
the reality.
A robot is a mechanical intelligent agent which can perform
tasks on its own, or with guidance. In other words, robots are usu-
ally guided by computer and electronic programs. However, three
characteristics make robots to stand out as one of the best me-
dia that are able to act as the bridge between the virtual (cyber)
world and reality. First, robots are of strong mobility. As robots are
338 Z. Du et al. / Future Generation Computer Systems 74 (2017) 337348
essentially machines, they are not confined to one physical loca-
tion but have the capability to move around in their surroundings.
Second, robots are perceivable. People endow robots the abilities of
perceiving and absorbing data in the environment, processing data,
and responding to various stimuli. The third character involves ac-
curacy and reliability. Robots can perform certain tasks for humans
and complete the work more accurately and efficiently.
Based on the merits of both robots and cloud computing tech-
nologies, in this paper we merge robots and cloud computing tech-
nologies and make the robot as one of the resources in the novel
computing system named Robot Cloud. Our intention is to create
synthetic systems which intensify the interaction between phys-
ical world and virtual world, making the best of both computa-
tion resources and robot resources to serve our human kind. In this
novel architecture, Service-Oriented Architecture (SOA) [2] plays
an important role since a loosely coupled framework cannot only
reuse existing assets easily, but also is conducive to the expansion
and maintenance of the existing robot systems, achieve flexible re-
sponse to customer requirement changes, maximize cost savings,
and improve the efficiency of Robot Cloud.
Unlike James Kuffners cloud-enabled robotics [3], the Robot
Cloud is a system meeting peoples need and owning the ability
to interact with the physical world. Considering the attributes of
robots, it is not likely for Robot Cloud to share the same system
architecture as traditional cloud computing without any change.
We present the novel Robot Cloud architecture in Section 3, partly
learning from the cloud computing architecture.
The rest of the paper is organized as follows. Section 2 intro-
duces related work that supports the design of our system. Sec-
tion 3 proposes the overall design of the Robot Cloud architecture
that characterizes a Cloud framework containing robot resources.
Section 4 presents in detail the most important features of the
Robot Cloud architecture, i.e., how to achieve the Robot as a Service
(RaaS). The feasibility studies on the Robot Cloud are shown in Sec-
tion 5, where we develop a prototype using the popular Google App
Engine platform [4] to testify our idea. The first application of the
Robot Cloud that comes to our minds is the robot show, which
could be exemplified as a scenario of on-site service providing. We
conduct the simulation to evaluate our scheduling algorithm, the
effect of different request distributions and the advantage of one
large robot center, which is elaborated in Section 6. The conclusion
is presented in Section 7.
2. Related works
2.1. Service-Oriented Architecture
Service-Oriented Architecture (SOA) [2] is not a revolutionary
shift of paradigm. It evolves from the distributed object [5] and
component architecture [6]. In an SOA environment, end users
request an IT service (or an integrated collection of such services)
at the desired function, quality, and capacity level, and receive it
either at the time as it is requested or at a later time specified
by the users. Service discovery, interoperability, and reliability are
important functionalities that need to be supported in SOA.
The key idea behind SOA is that different companies offer their
services in the form of modular and loosely coupled software
components, which exchange data among the companies over
HTTP (Hypertext Transfer Protocol) on the Internet with no human
intervention. In other words, services can be replaced on the fly
without the interruption of using the services. SOA has a number
of outstanding characteristics, such as reusability, substitutability,
extensibility, scalability, customizability and composability. Using
SOA, researchers have developed different robots, such as Robotic
Swarm by Vlad M. Trifa et al. [7], security robots designed by
Arizona State University [8].
2.2. Cloud computing
As consumers rely on service providers to supply all their data
or computing resources, the computing industry shifts towards
providing Infrastructure as a Service (IaaS) [914], Platform as a
Service (PaaS) [4,1517], Software as a Service (SaaS) [1820], and
even X as a Service (XaaS) where X can be any item [21].
Cloud computing technologies give the IT professional opportu-
nities and challenges. All major computing companies participate
in cloud computing areas and many platforms emerge, including
Amazon Elastic Compute Cloud (EC2) [22], Google App Engine [23],
Microsoft Azure [24], Sun network.com (Sun Grid) [25] and GRIDS
Lab Aneka [26]. The emergence of cloud computing and the corre-
sponding new products as well as that of the new business model
makes it possible to use computing resources just like accessing
utility services.
From the bottom to the top, the cloud computing stack [27] built
on hardware is commonly recognized as IaaS, PaaS and SaaS.
Zhang et al. [28] has already presented a reusable and customiz-
able cloud computing architecture called Cloud Computing Open
Architecture (CCOA). It also depicts several principles for building
the Cloud Computing systems and applications as well as for adopt-
ing the service-oriented architecture (SOA), that could make the
CCOA more flexible, extensible and reusable.
The main contributions of the CCOA provides two insights that
we can use to develop our own work. First, it is recommend-
able to adopt the way of using a novel architecture to enable
the infrastructure-level resource sharing as cloud offering. Thus,
robots in the Robot Cloud should also be shared as a cloud offer.
Second, we can use the SOA construction method to separate busi-
ness design from infrastructure support.
Mobile Cloud computing becomes a hot topic lately [29,30].
Mobile Cloud and Robot Cloud share similarity to some extent since
Robots typically interact with other services in the Cloud through
wireless communication. But the difference between them is
prominent. Mobile Cloud provides the rich computation and data
resources in the Cloud platform to mobile users. It works by, for
example, offloading the workloads submitted to mobile devices to
run on the Cloud platform. In Robot Cloud, however, the objective
is to integrate the robots into the Cloud platform. By doing so, robot
services become a type of Cloud service and an integral part of the
Cloud platform. Therefore, their objectives, interaction principles
and implementation techniques are very different.
2.3. Cloud-enabled robotics
Googles self-driving automobiles have shown that an un-
manned car equipped with the computer technology can travel
safely from city to city [31]. Also, there are a good number of re-
searchers exploring the idea of using the robots based on the cloud
computing infrastructure, aiming to access vast amount of process-
ing power and data. Professor James Kuffner at Carnegie Mellon
University has described the possibility of embracing the cloud in
robots. CPU-intensive tasks in robots can be offloaded from smaller
and less power-consuming onboard computers to remote cloud
servers [3]. A robot can improve its ability by integrating with
cloud-based services. An example of this is the cloud-enabled robot
with the object recognizing function such as Google Goggles [32].
Imagine a robot finds an object that it never saw or used before, for
instance a box of cornflakes. The robot can be programmed to send
an image of the box to the cloud. The object recognition algorithm
is run in the cloud and returns the robot the objects name, a 3-D
model, and the instructions of how to pour it. Other functions of
a cloud-enabled robot include navigating environments [33] and
operating tools.
 Z. Du et al. / Future Generation Computer Systems 74 (2017) 337348
Professor Kuffner aims to develop the robots as an effective
terminal which is able to offload most of its complex computa-
tional and storage work to the cloud, rather than intensify the
ability of the robots themselves. In the robotics level, robots are
isolated, which means that there are little direct interactions be-
tween robots. This is because in this architecture a cloud-enabled
robot depends on, therefore interacts with, the cloud rather than
its peers.
J.P Laumond has pointed out the drawbacks of the cloud-
enabled robotics in [34]. Achieving good real-time performance
depending on strong onboard processing ability would be a
forbidden territory for cloud robotics. For instance, controlling a
robots motioning which relies heavily on sensors and feedback
will not benefit much from the cloud. Moreover, the cloud
robotics paradigm which severely relies on the networks may
weaken the robotics autonomy and reliability. It is possible that
once the networks paralyze, all cloud robotics would become
brainless.
However, different from professor J. Kuffners intention to make
robots lighter, cheaper and smarter, Robot Cloud aims to shape
the robots as a part of the cloud computing service which leads to
the conception Robot as a Service elaborated in Section 4. On one
hand, in the Robot Cloud, service-oriented architecture does not
have to be implemented over the Web. Thus, the standard interface
can be simpler and faster. Services can also be migrated onto a
local machine to reduce the communication cost [35]. Besides, the
Robot Cloud is not the simple extension of the cloud computing
technologies or the robotics. It has the features of both cloud
computing and robotics as well as its own distinctive features of
the Robot Cloud itself. Especially, on the robotics level, robots in
Robot Cloud can contact each other rather than act as isolated units
that are only allowed to exchange data with the remote servers. As
a result, the Robot Cloud will make the best use of most excellent
existing scientific achievements in the realm of robotics.
Usually, when we develop a new system, it is necessary to
develop the framework that is able to explain various architec-
tural concepts and specification in the system. The purpose of
developing such a framework is to allow the improvement and
integration of development methodologies and tools and also to
establish the credibility and confidence in investing the required
systems resources. However, the analytical results of the cur-
rently accepted cloud stack and the architecture of cloud-enabled
robotics indicate that these architectures cannot meet all the needs
of the proposed Robot Cloud. Mismatches between original design
and current usage will definitely hamper the application potential
of Robot Clouds. Therefore, it is essential to design a new architec-
ture for the Robot Cloud.
3. Robot as a service
As SOA becomes more and more popular, this new architecture
style has been applied to the development of robotics application.
Chen applied the SOA concepts to develop re-composable embed-
ded systems and robotics applications, and implemented a proto-
type of the system [36]. Researchers encapsulate the functions of
every part of robot and the robotics applications as well-defined
services. Programmers are then able to assemble new robotics ap-
plications using these services. In this way, the whole systems are
loosely coupled, more flexible to adjust. More importantly, new ap-
plications can be developed more efficiently just by composing ev-
ery useful component and customizing them.
Chen et al. also implemented these ideas with an easy-to-
learn programming language, Visual Programming Language (VPL),
successfully, and applied it to develop a high school computing
course [37].
The SOA-based robot architecture relies on extending cloud
computing to the field of roboticsRaaS (Robot as a Service in
339
Cloud Computing). There are a large number of robot units in a RaaS
system. All these robot units provide services to the consumers. A
RaaS system also has complete functions of SOA, that is, as service
provider, as a service broker, and as a service client [38].
A RaaS cloud unit is a service provider: Each unit hosts a repos-
itory of preloaded services. A developer or a client can deploy new
services into, or remove services from, a robot. The services can be
used by this robot and can also be shared with other robots.
A RaaS cloud contains a set of deployed applications: A devel-
oper or client can compose a new application (functionality) based
on the services available in and outside the unit.
A RaaS unit is a service broker: A client can look up the services
and applications available in the units directory. A client can
search and discover the applications and services deployed in the
robot by browsing the directory. The services and applications can
be organized in a hierarchy or classes to facilitate the discovery.
Fig. 1 illustrates the service layers and the hierarchy of ser-
vice registry and discovery. There are three types of elementary
services, which are also called low-level service, including Ba-
sic Hardware Services, Application Services and Common Ser-
vices (represented by different shapes at the low level services
layer in Fig. 1). These low-level can be composed to provide high
level services (the second layer in Fig. 1). All services, no matter
high-level or low-level, are published through the service registry
and repository (the top component in Fig. 1).
Basic Hardware Services: This type of services plays a role of
basic hardware resources. The following are some exemplar basic
hardware services: a Core Processor Service runs as the core of the
system, performs basic diagnosis and controls various services in
order to finish specific tasks; a Sonar Sensor Service initializes the
sonar sensor driver and calculates the distance of the sonar senor
from an obstacle in front of it; a Touch Sensor Service generates
an event when the touch sensor is touched or has encountered
an obstacle; a Motor Driver Service keeps reading a managed
command pool and retrieves the command from the command list
and executes it; a Compass Sensor Service keeps reading incoming
data from the corresponding port, calculates the compass value,
and turns around according to the compass value; a Video Camera
Service pops up a window displaying a real-time video captured by
the camera mounted on the robot.
Application Services: Application services registered in the
service broker are mainly task-related services, such as Patrol
Service (driving the robot to perform the patrolling and object
detection task autonomously), Intruder Detection Service (helping
the robot detect the presence of intruders), Bomb Detection Service
(assisting the robot to detect potential bombs in a dangerous
environment), and so on.
Common Services: Common Services represent several classic
algorithms and commonly used functions. For example, a maze
navigation algorithm is required by most mobile robots, and a
human face recognition algorithm is also used by various robotics
applications which need to recognize different people from their
faces.
Since the service broker provides a method for robotics appli-
cation developers to retrieve existing usable services, developers
are able to reuse the appropriate components and combine them
according to the requirements, which greatly facilitates the appli-
cation development.
4. The robot cloud architecture
4.1. Target business model
A good understanding of the target business model greatly
helps us design the architecture of the Robot Cloud. Generally,
there are four parties in the target business model of Robot
340 Z. Du et al. / Future Generation Computer Systems 74 (2017) 337348
Fig. 1. Illustration of service layers and service registry and repository.
Fig. 2. The target business model.
Cloud, which are Robot Cloud Service Provider, Cloud Computing
/Robotics Provider, Value-added Service Provider, and also the
Consumer. The relationship among all the roles can be illustrated
by Fig. 2.
The Robot Cloud is owned by the Robot Cloud Service Provider,
who is responsible for the management, government, execution
and maintenance of the Robot Cloud. Acting as a one stop shop in
front of the consumers, the Robot Cloud Service Provider receives
consumers requests and provides the Robot-Cloud services to the
consumers. Cloud Computing Provider and Robotics Provider act as
the Infrastructure Provider in the Robot Cloud, who provides cloud
services primarily or various types of robotics. The Value-added
Service Provider offers services that existing cloud does not own.
4.2. System architecture overview
Designing a novel architecture is a very complex project, which
needs to consider many factors including reliability, scalability,
modularity, interoperability, interface, QoS, etc.
Figs. 3 and 4 give the system architecture and topology
overview. As a whole, the architecture of Robot Cloud includes
three parties, which are the Robot Cloud Center, Cloud Robot Host
and Service Robot, from top to bottom. Robot Cloud Center is the
core of the Robot Cloud which is in charge of performing all the
computing or storage intensive tasks. A Robot Cloud Center con-
tains a number of Cloud Robot Hosts which are deployed in dif-
ferent physical environments that could be different geographical
places in a city. Robot Hosts meet the requirement of interacting
with the physical world in Robot Cloud. A Robot Host may con-
tain several Service Robots, which form the Perception/Interaction
Layer of the Robot Cloud.
From another perspective, the Robot Cloud is also a six-layer
architecture system consisting of the Perception/Interaction Layer,
the Transport Layer, the Mapping Layer, the Processing Layer, the
Application Layer, and the Business Layer.
The Perception/Interaction Layer is like the facial skin and the
five senses of the Robot Cloud, which is designed to perceive
the physical properties of the objects (such as the location,
surrounding environments, etc.) by various sensors (such as sonar
sensors, GPS, 2-D barcode, etc.), and to convert the information
to digital signals so that it can be transmitted over network
more conveniently. Moreover, the Perception/Interaction Layer
is responsible for the interaction between human and robots,
through interactive devices.
The Transport Layer is responsible for transmitting data re-
ceived from the Perception/Interaction Layer to the upper layer
mostly through wireless networks (such as WiFi, 3G networks,
etc.).
Both the Mapping Layer and the Processing Layer rely on com-
puting and storing abilities. The former focuses on the tasks such as
robots scheduling and brings the great convenience to robot man-
agement. The later processes large quantities of tasks and the huge
amount of information that the Robot Cloud carries through the
cloud computing technologies.
Based on the Processing Layer, we build the Application Layer
which is formed by diverse application services (such as Robots
Authentication and Access, Location service, etc.). As a result, the
Robot Cloud can provide different clients with different applica-
tions.
Finally, the Business Layer acts like the manager of the Robot
Cloud, whose functions include managing the applications, rele-
vant business models and other businesses. The business Layer
manages not only the release of various applications and the charg-
ing for using them, but also the research on business models and
profit models, which benefit the long-term development of the
Robot Cloud. The reason why we build the Robot Cloud based on
the service-oriented architecture is partly because of the require-
ment of the business model.
4.3. Robot Cloud Center
4.3.1. Robot Cloud Center architecture
Robot Cloud Center is the core of the Robot Cloud which is
in charge of performing all the computing or storage intensive
tasks. It can be a data center built with a large number of
devices in a specified physical location. Cloud computing is the
primary technology of the Robot Cloud Center. Employing the
cloud computing technology in the robotics is still challenging.
Three objectives help address the challenges of defining an open
Robot Cloud Center architecture.
(1) Articulating a reusable way of creating scalable and config-
urable provisioning platform for Cloud Computing.
(2) Proposing a set of common and shared services to build the
Robot Cloud services (or other Cloud offerings) for Cloud
customers in a unified approach.
 Z. Du et al. / Future Generation Computer Systems 74 (2017) 337348
Fig. 3. System architecture overview.
Fig. 4. System topology architecture.
Fig. 5. The architecture of a Robot Cloud Center.
(3) Maximizing the potential business value of a Robot Cloud
based on an extensible infrastructure and management sys-
tem. This will attribute to the value added services of business
cloud, through combining the power of SOA and cloud com-
puting.
Thus, we propose a reference model of the Robot Cloud Center,
which is shown in Fig. 5.
Here, we have to clarify three points:
First, the Robot Cloud Client Panel is the interface through
which the customers access the Robot Cloud and request the
services that satisfy their needs. In other words, the Robot Cloud
Client Panel is the interaction platform between the service
provider and the customers of a Robot Cloud. Technically, the
Robot Cloud Client Panel can be a front-end for web access.
Second, since most Cloud vendors do not work alone anymore,
they need to collaborate with their partners [28], it is helpful
to design a Cloud Computing Provider Panel to integrate the
management of the Robot Cloud.
Third, even though X as a Service (XaaS) is not a strange concept
to IT professionals, the new concept of Robot as a Service (RaaS) is
discussed in detail in Section 3.
341
4.3.2. Robot Cloud Panels
People (i.e. customers, Robot Cloud provider, and also cloud
computing provider) access the Robot Cloud through three
separate Robot Cloud Panels. However, according to the life cycle
reference of SOA, the functions of all these Panels can be classified
into four categories, i.e., modeling, assembling, deploying, and
managing and analyzing the robotics applications.
1. Modeling: It enables the platform to gather and analyze user re-
quirements. The developers of robotics applications will design,
stimulate and optimize them according to user requirements
recorded by the system.
2. Assembling: It is used to compose new robotics applications
using existing services published in the service broker. MRDS
(Microsoft Robotics Developer Studio) [39] is a windows-based
environment for developers to easily create robotics applica-
tions. Because MRDS with various useful toolkits provides pow-
erful functionalities, we have ported MRDS and its graphic
language, VPL (Visual Programming Language) into our model
and assembled the development phases of robotics applica-
tions.
3. Deploying: If robotics applications are deployed and invoked
on a Robot Cloud Panel, applications can be replaced and up-
dated without stopping the robots. However, it requires fre-
quent communication between the Robot Cloud Panel and
robots. As the result, it is difficult to guarantee the real-time re-
sponse. In our work, we implement a service auto-installer to
synchronize newly developed services or applications and tar-
get robots through wireless network.
4. Managing & Analyzing: this function is composed of four im-
portant sub-components: scheduler (scheduling all requests re-
ceived by the robots), robot manager (adding new robots or
substituting existing ones, managing the robot mapping, etc.),
robot monitor (monitoring the robot status, service running sta-
tus and analyzing the logs), and service broker manager (the
CRUD operation of the service broker).
4.3.3. Cloud Robot Host
A Cloud Robot Host is like a manager of a collection of Service
Robots. It can be deployed in a fixed physical place as a gathering
station for Service Robots. The Cloud Robot Host is a party linking
Robot Cloud Center and numerous Service Robots. It consists of
three parts (showed in Fig. 6): the Robot Host Core, the Robots
Maintenance Module, and the Robots Storing Module.
Just as its name suggests, the Robot Host Core is the kernel of
a Cloud Robot Host, which contains an authentication and access
component, a graphical user interface (GUI) component, a moni-
toring component, a communication module, the QoS module, the
Safety module, the computation module, and also a Service Broker.
The functionality of the authentication and access component
is to manage the Service Robots registration. It possesses the
methods to authenticate the Service Robot and grant a Service
342 Z. Du et al. / Future Generation Computer Systems 74 (2017) 337348

Fig. 6. A robot host architecture. Fig. 7. A Service Robot architecture.

Robot the proper authority to use all other resources in the Robot
Host. The GUI component provides the manager of the Robot Host
a friendly interface to manipulate the system. The monitoring
module is related to the Robot Hosts polling function, through
which the Robot Host Core polls all its Service Robots and obtains
their status at certain time intervals. The monitoring module
can be inquired when deploying different scheduling methods to
minimize the overall cost of the Robot Cloud (further discussion
on the scheduling issue is conducted in Section 4.4.3). The module
can also be used to detect abnormal status. Once an abnormal
status is detected, a warning message will be sent to GUI, and
the information related to the abnormality will be saved in the Fig. 8. A Service Robot architecture (SOA view).

database.
We design a Service Broker in the Robot Host Core so as to
avoid developing the application-specific components. Instead,
the requirements of the components are published in the Service
Broker. In other words, the Service Broker will provide a great
convenience to the service providers: the service providers can
develop the services and publish them in the broker, and the
application developers then look up the services available in the
Cloud and incorporate the services into the application to be
developed.
The Robots Maintenance Module maintains the Service Robot,
i.e., conducts the maintenance routine and the common trouble
shooting. Also, this module recharges the Robots battery.
The Robots Storing module is like a robot warehouse. Once a
robot has entered into the Sleep or Ready state (these concepts
will be discussed in detail in Section 4.4.2), it will find its way to the
Storing Module and stay there.
4.4. Service Robot
4.4.1. Service Robot architecture
Generally speaking, Service Robots in the Robot Cloud are
robotics provided by Robotics Providers, but are built with spe-
cially designed architecture in order to integrate with the cloud
computing resources. Indeed, Service Robots play the most funda-
mental role in the Robot Cloud system because they are the entities
which provide services for the end users. Service Robots need to
communicate with other parts of the system (i.e. the Robot Host),
and they are also required to interact with each other.
As we have discussed in the previous section, Service Robots
form the Perception/Interaction Layer of the Robot Cloud. Service
Robots are able to perceive information in the surrounding world
and also provide different services directly to customers.
The physical architecture of a Service Robot is shown in Fig. 7. A
typical Service Robots components should include (but not limited
to) a position module, a mechanical module, a communication
module, the computation module and battery. To improve the
service quality of the robotics, Providers may add other modules
onto the robot including Alert system, QoS module and Safety
mechanism. Note that the controlling function is not implemented
in a single module in the architecture. The controlling function
consists of two parts. One part performs certain physical actions.
This function is implemented in the mechanical module, which
needs the assistance of other modules, such as position modules.
The other verifies who is authorized to issue the instructions. This
function is implemented in the safety module.
We build Service Robots in the fashion complying with the
service-oriented architecture. This is the reason why these mod-
ules can be easily added onto or removed from robots. In general,
the Service Robot architecture can be divided into two parts: WSDL
Interface and Infrastructure (see Fig. 8).
The infrastructure of Robots in the Robot Cloud is composed
of the hardware devices of robot and the operating system, as
well as device drivers. There are heterogeneous robots in the robot
cloud that provide different services, so they may have different
hardware devices and device drivers.
Service Robots must also interact with other parts of the sys-
tem or interact with other robots. We use web services as the com-
munication interface in our system. To make the system work, the
application server must be installed on the onboard computer of
the robots, which is responsible for receiving requests and send-
ing responses. Robotics applications and web services that wrap
hardware drivers (Basic hardware services) are deployed on the
server. Besides, a service directory of Robot Cloud unit is necessary
to record all the services deployed on it.
4.4.2. Service Robot finite-state machine
Each of the Service Robots has a human user interface which can
turn the robot into an autonomous mode or a manual controlled
mode. Once a robot is initialized and put in the working order,
it will run in the autonomous mode without the need of human
intervention. Fig. 9 shows all statuses of a Service Robot.
We consider three states in the autonomous mode: Sleep, Ready
and Busy. All states change dynamically in order to achieve rela-
tively low energy consumptions. When a robot is initialized, its de-
fault state is set to be Sleep, the most energy-saving state. There
can be a number of Sleep Robots in a Robot Host. When the QoS is
below a certain threshold, the state of a certain number of Sleep
Robots will translate it to Ready, which means that the robots are
ready to load tasks. A Ready robot consumes more energy than A
 Z. Du et al. / Future Generation Computer Systems 74 (2017) 337348 343

Table 2
Final state of robots.
Rid RSid State

1 A 0
1 B 0
2 A 0
2 B 0
3 B 0

Table 3
Final state of robots.
Fig. 9. Service Robot finite-state machine.
Rid RSid State

Table 1
Robot variables and definitions.
Notations Meaning
Rno Request identity number
Sid Requested service identity number
Cpb The total capacity of robots that the users request needs
Rid Robot identity number
RSid Robot provided service
State Running state of robot
Sleep robot. When the QoS is above the threshold, some Ready
robots may fall back to the Sleep state.
Only Ready or Busy robots can perform consumers re-
quests. An incoming customer request (i.e. a task) can put a
Ready robot into operation. The robot then becomes a Busy
robot. Note that not every newly arriving task will change a
Ready robot into a Busy one. A Busy robot can also take the
task that possesses a long deadline. If the deadline is long enough,
a Busy robot may finish its current task first, and then perform
the task with a relatively long deadline.
4.4.3. Service Robots mapping and scheduling algorithm
As stated above, a Service Robot has various states. This raises
the problems as to whether Robot Host should use a Busy Robot
or another Ready Robot to perform a new task. When the re-
quirements in terms of both functionality and quality-of-service
(QoS) are satisfied, how to minimize the overall cost of the robots
becomes more complex. In such cases, the scheduling strategies
should be enacted by the Robot Host. There are a number of ex-
isting works which also investigate the task scheduling strategies
[40,41] and the service mapping problems [42]. However, their
works are designed for generic tasks and services. In this section,
we propose a mapping and scheduling method targeted towards
robot services.
We design a mapping layer in our system to realize the task as-
signment function of the system. Fig. 10 presents the specific map-
ping mechanism from a high-level perspective. It is necessary to
point out that this mapping is not unalterable. It is a configuration
file in XML that can be dynamically modified by the robot man-
ager in Robot Host, which means that we can manage the robots
flexibly.
We apply the robot selecting and scheduling algorithms in the
mapping layer to achieve the overall robot management of the
Robot Cloud.
Firstly, the robot selecting algorithm is built on the assumption
that the Robot Cloud Center has sufficient robot resources. The
algorithm checks if the residual energy of robots is sufficient for
completing the tasks to be assigned.
The variables of user request can be abstracted as Table 1.
A robot can provide multiple services, i.e., one Rid can be asso-
ciated with many RSids. The initial state of the robot is 0, i.e., the
idle state. When the robot executes a service, its state is changed
to1, which represents the running state.
Table 2 shows a case study that illustrates our model.
1 A 1
1 B 1
2 A 1
2 B 1
3 B 0
When the Sid of a user request is A, we select the robot based on
the following rule: the state of robot is 0 and the robot whose RSid
is A. Consequently, the robots that can be selected must be in the
set {1, 2}. Namely, we can only assign the task to robots whose Rid
is either 1 or 2. We change the states of robot 1 and 21, as shown
in Table 3.
Then, if a new request demands service B, the set of candidate
robots that can be selected is {3}. Therefore, the task will be
assigned to robot 3.
We now consider how to distribute the tasks to certain robots
within the set of candidate robots. The task distribution aims to
(1) satisfy the users demands and (2) minimize the overall cost of
the robot cloud.
Assume the number of robots available in Robot Cloud Center
is n. The capability of each robot is denoted by Ai (1 i n) and
the cost of each robot by Ci (1 i n). Xi (1 i n) denotes
the final solution of robot selection. (Xi = 1) means that ith robot
is selected, while (Xi = 0) means that ith robot is not selected. The
capability of a robot is expressed as a vector Ai = s1 s2 , . . . , sm
(the total number of robot services that can be provided is m). If a
robot can provide service sj then the value of its element sj = 1.
Otherwise sj = 0. We can remove, add or replace a particular
service on a robot dynamically, and therefore the value of Ai may
vary over time. Cpb is also expressed as a vector similar as Ai and its
value is set based on users requests for different kinds of services.
Cpb [j] = 1 means that the user needs the jth service. Otherwise
Cpb [j] = 0 (1 j m). The optimal scheduling in the sense of
minimizing the cost can be formulated by
n
min Ci Xi
i=1
n
s.t. S [j] Cpb [j] , 1 j m, S = Ai Xi , Xi {0, 1} . (1)
i=1
Since the value of Xi is 0 or 1, the problem proposed above is
a classic integer linear programming problem. Finding a feasible
solution to this problem is NP-hard and there are not known
algorithms for solving the integer linear programming problem
with polynomial time. Therefore, we propose a heuristic algorithm,
LPS (Location-based Packing Scheduling), to schedule the tasks.
Algorithm 1 shows the details of the LPS algorithm. The algorithm
tries to pack multiple requests and assign them together to one
robot. LPS at most check K Busy robots and one Ready robot. It will
assign the request to the robot with the lowest cost or reject the
request if the selected (K + 1) robots cannot satisfy the request
or the constraint. The time complexity of the LPS algorithm is
O(K + 1), where K + 1 is the number of the robots to be checked.
Because we only need to check a few robots, the algorithm can
process the requests with high performance.
344 Z. Du et al. / Future Generation Computer Systems 74 (2017) 337348
Fig. 10. Robot objects and physical robots mapping.
5. The cloud robot prototype
A robot is a good combination of the digital cyber world and the
real world. Most of the robots controlling programs are written in
object oriented languages such as Java and C++. The libraries that
most robot manufacturer used to program the robot actions are
similar. With these libraries, it is easy for the users to develop their
own controlling algorithms and make the robots perform desired
actions.
We have implemented a prototype of the robot cloud based on
the infrastructure and components described in previous sections.
An Application Programming Interface (API) is implemented using
the object oriented programming languages (detailed in the
subsections below) in the PaaS layer. The API describes a set of
robot actions provided by the Robot Cloud in the behavior level.
5.1. Accessing robots from the cloud programs
Although programming a robot is easy nowadays, the interop-
erability is still poor compared to the highly developed software
industry. With the development of SOA (Service Oriented Archi-
tecture) and related technologies, the interoperability of software,
especially those based on Internet, have advanced to a very high
level. For example, a program can now access another programs
data or functions through some common programs called middle-
ware. The cloud computing technology has one of the many ways
to implement a SOA software, which draws more and more atten-
tion in the industry Cloud service providers have also made a lot of
efforts to improve the interoperability between the cloud comput-
ing platform and the software running on top. A typical solution is
to build up a library which makes it easy for the programmers to ac-
cess the platforms features. Software on the platform can also have
access to the public data (e.g. user information, contact, schedule
etc.).
The advantage of the Software industry in interoperability can
be introduced to the robots, if we can merge the robots into
the modern software architecture such as cloud computing. The
robots can be regarded as another resource in the cloud computing
infrastructure, just like computing capacity and storage. A library
should also be developed to provide an entry to control all different
types of robots, just as what cloud computing servers do to provide
the uniform entry for operating different types of computer. Such
library should be an extension to the PaaS layer as shown in Fig. 11.
The extension takes the advantage of the Google App Engine
(GAE), which stores and analyzes the data through the interface
Fig. 11. System architecture of the prototype system.
Fig. 12. Inheritance-layered class diagram of the GAE robot extension.
provided by the Cloud platform. The extension provides the
developers the extra classes that can access the robots. The
inheritance-layered class diagram is shown in Fig. 12. All classes
in the extension are extended from the Robot class, in which some
common functions, such as hiring or releasing a robot from the
robots pool (a place where all robots park). Robots with special
functions can be extended from the top level classRobot or the
classes extended from it. In this way, the prototype offers the
methods to implement both basic function and special functions.
The robot cloud panels mentioned in Section 4.3.2 is imple-
mented as an application base on the Google App Engine and the
RaaS extension. Users can open the application in their Internet
browsers and send the requests to the robots.
5.2. Controlling robots from the cloud server
All the data generated by or related to the robots are stored
as persistent objects in the Google App Engine Platform. Robot
instances can share these data through the scheduling service to
cooperate and provide more excellent services.
The Scheduling service is a standard SOA programming inter-
face, which is implemented in Java and hosted by the Google App
Engine. The service contains two main functions: Upload the data
submitted by the robots to the cloud storage and accept the re-
quests committed by the applications. The Scheduling service is
tightly coupled with the Google App Engine. When new data ar-
rive from the working robots, it will be transformed immediately
into the instances of the corresponding data type and stored per-
sistently through the JDO (Java Data Object) interface provided by
the Google App Engine. The data in the cloud storage is clearly clas-
sified so that both applications and working robots can access the
data by certain search requests. On the other hand, when users sub-
mit new requests to the system through the application, they will
be placed in the command queue located in the cloud storage. The
scheduling service then rearranges the commands and sends them
to certain robots for execution. Since the robot resource is also lim-
ited, the rearranging procedure is very important in optimizing the
 Z. Du et al. / Future Generation Computer Systems 74 (2017) 337348
Fig. 13. The full overview of the robot cloud prototype system.
allocation of robot resources, just as how the operation system ar-
ranges the processes to make full use of the computing and storage
capacity.
The controlling system of each robot is implemented in an Intel
Atom process based x86 embedded system. Since the robot system
shares the same architecture with the widely used PC platform, the
system can get full support of the PC software and hardware. In
this prototype, a Microsoft Windows XP is installed in each robot
as the operation system and a WIFI adaptor is installed in the
system to provide IEEE 802.11 g wireless Internet connection to
the system. Some motion control units (PhidgetMotorControl HC,
Phidget, Calgary, Canada) are connected to the universal serial bus
(USB) to control the movement of the robots. A local controlling
service is also implemented by the C# programming language. The
API provided by the manufacturer of the USB motion controller
makes it possible for the local controlling service to control the
robot programmatically. The service obtains the latest commands
by sending the HTTP requests periodically to the scheduling service
and receiving their commands in the XML format as the response,
in a similar way as what most SOA applications do.
The full overview of the robot cloud prototype system is shown
in Fig. 13. Application developers can control the robot simply by
invoking the methods provided by the RaaS Application Program-
ming Interface in the level of behavior instead of in the low level of
motion control. This makes it much easier for the robots to interact
with other robots or even with people.
6. Simulation results
6.1. Simulation model and setup
In this section we consider a simple scenario that a robot center
can only provide one service, robot show, for a given physical
area. The families or organizations (such as kindergartens) can
request the robot center at certain time to play the on-site robot
show at any location of the given area. The customers will be
charged only based on the service time. The longer the show is,
more fee will be charged.
The customers request is formulated as a 4-tuple req =
R, P , S , D, where R is the release time of the request; P is the
location of the request, expressed as the coordinate x, y; S is the
requested service demand, i.e., how long the requested show lasts
in this case; D = R + S + L is the deadline of this request, i.e., the
345
time point before which the show must end. The value of x, y, S
and L can be set to follow certain probability distribution (here the
normal distribution is adopted).
We set the longest working (including traveling) time (denoted
by Tmax ) for a robot to be 5400 s, which means that each robot must
meet the following constraint before recharging its battery.
(total service time) + (total moving time) Tmax . (2)
After that period, a robot must be recharged and maintained in
the robot center. We must ensure a robot is in the robot center by
its longest working time. After the maintenance stage, a robot can
provide the service again.
The utilization function of the robot center can be defined as
follows.
Profit = (total service time) Price
(total traveling time) TravelCost . (3)
6.2. Simulation results for one big robot cloud center
In the experiments, we simulate a big robot cloud center which
serves an area of 20 km by 14 km and the robot cloud center
is located at the coordinate of 10 km, 7 km. The four request
parameters expressed in the 4-tuple follow the following normal
distribution. x N (1000, 2502 ), y N (700, 1802 ), S
N (600, 1502 ), L N (1200, 5002 ).
First, we compare the performance of the LPS (Location-based
Packing Scheduling) algorithm with another nave scheduling
algorithm, the ES (Exclusive Scheduling) algorithm. The ES
algorithm is very simple. It just assign the request to one Ready
robot in the robot cloud center so we do not present the detailed
algorithm description here.
Fig. 14(a) clearly shows that for the same amount of requests,
the LPS algorithm needs fewer active robots than the ES algorithm.
This is because LPS packs multiple requests and assigns them
together to one robot (the different requests can share one robot)
while ES does not. It is to be expected that total traveling cost of ES
is greater than that of LPS, as shown in Fig. 14(b). The simulation
results show that more profit can be gained by virtualizing one
physical robot into multiple ones. In the following experiments,
we will only present the results of the LPS algorithm since LPS is
superior to ES.
346 Z. Du et al. / Future Generation Computer Systems 74 (2017) 337348
Fig. 14. Simulation results of the LPS algorithm and the ES algorithm. (a) The number of active robots changes over time; (b) The total traveling cost changes over time.
Fig. 15. The impact of the deadline on scheduling results. (a) The impact of deadline changes on the number of active robots and the reject ratio; (b) the impact of deadline
changes on the gained profit of the robot cloud center.
We also conducted the experiments to evaluate the impact of
the deadline distribution on scheduling results. The results are
shown in Fig. 15.
Fig. 15(a) shows that when the requests have longer deadline
(the consumers can tolerate longer waiting time), the number of
active robots increases first and then decrease. The reject ratio
decreases monotonously. This is because when the deadline of a
given request is shorter, it is more likely that the robot cannot move
to the specified location to provide the service and therefore the
request has to be rejected. In this case, we do not need a large
number of active robots to provide services. When the deadline
of the request become longer, it is more likely that the robot
cloud center has enough time to send the robots over to serve
the requests. Therefore, the reject ratio decreases and more active
robots are needed. When the deadline of the request become even
longer, our LPS algorithm are able to pack more requests together
and assign them to one instead of multiple robots. This is why
the number of active robots decreases as the deadline increases
further in Fig. 15(a). The reject ratio continues to decrease because
even more requests can be served by the robot cloud center.
Fig. 15(b) shows that the profit of the robot cloud center increases
as the requests deadlines become larger. The increase in profit
comes from two aspects: (1) more requests can be served, and
(2) the traveling cost decreases when one robot is able to meet
the deadlines of multiple requests and therefore serve multiple
requests.
Finally, we investigate how the service demand affects the
scheduling results.
Fig. 16(a) shows that when we increase the service demand
of each request from low to high, the reject ratio remains almost
the same and the number of active robots increases before service
demands are less than some threshold values. This is because the
robot cloud center can wake up more sleeping robots to meet
the increasing service demand if the requests cannot be packed
together and assigned to the existing active robots. When the
service demand is too high (close to the maximum working time
Tmax of the robot), the system cannot schedule any more robot
to meet the requests. Consequently, the requests with very high
service demand have to be rejected and there is no need more
robots to provide service. This is why the number of active robots
dips when service demand increases further in Fig. 16(a).
Fig. 16(b) shows that the profit of the robot cloud center keeps
increasing until the service demand becomes too high. This is
because when service demand increases the robot cloud center
can gain profit by serving more requests. When service demand
increases further beyond the threshold, the profit decreases
because the requests with very high service demand have to be
rejected.
6.3. One big center or multiple smaller centers?
Given a service area and a total number of requests, a question
arises as to whether we should build multiple smaller robot
centers, each serving a smaller and separate area independently,
or build one big center to serve the entire area. We also conduct
the experiments to investigate the difference between the two
solutions.
We assume the entire area is 20 km 20 km and it is divided
into three separate areas, each being served by three independent
robot centers: A, B and C. Three synthetic request traces are used
 Z. Du et al. / Future Generation Computer Systems 74 (2017) 337348
Fig. 16. Impact of service demand on scheduling results. (a) Impact on the number of active robots and the reject ratio. (b) Impact on the profit of the robot cloud center.
Fig. 17. The impact of the variance ( ) of request locations on scheduling results. (a) The impact on the number of active robots and the reject ratio. (b) The impact on the
profit of different solutions.
by these three centers, respectively. Each robot center can only
schedule its own robots and cannot assign the requests to the
robots managed by other robot centers.
We also simulate the scenario where a single robot center is
used to serve all requests from the three request Traces. We set
the locations of three smaller robot centers to be (1000, 750), (750,
1250) and (1250, 1250), and the location of the single big center be
(1000, 1000).
A greater means that the requests are distributed more
sparsely in the given area. Fig. 17(a) shows that the solution of
a single big center needs fewer active robots to serve all the
requests than the solution of three separate smaller centers. Since
one robot center cannot assign its requests to the robots in other
robot centers, the multi-center solution needs more robots to serve
the same amount of requests. At the same time, the single-center
solution has lower reject ratio compared with the multi-center
solution. For both solutions, greater always leads to more active
robots and higher reject ratio because the robot center cannot
schedule a robot to meet the service demand by the given time.
However, there is an exception for the single-center solution:
when increases from 250 to 300, the number of active robots
decreases. A possible explanation is as follows. When more robots
are providing service at different locations of a given area, it is more
likely that more requests fall into such proximity of a robot that all
these requests can be served by the robot, which give the system
the chance of packing these requests and assign them to the active
robot.
Fig. 17(b) shows that the single-center solution have much
more profit than the multi-center solution. However, the absolute
profit decreases under both solutions as the value of increases.
This is because given the same total requests, greater leads to
347
more traveling cost, which causes the decrease in profit based on
Eq. (3).
The above results indicate that in our scenario and scheduling
policy, the solution of building one big center (sharing all the
robots) is much better than that of multiple smaller centers (each
sharing a subset of robots).
7. Conclusion and future work
We have developed a way of building a Robot Cloud in order
to combine the cyber (virtual) world and the physical world. The
Robot Cloud has the great potential to serve the diverse and
large amount of location-based on-site demands, which cannot be
handled by the existing cloud systems.
The prototype implemented in this work and the simulation
results show that (1) the virtualization of robot resources is
feasible, (2) the virtualization can improve the profit of the robot
center, and (3) one large robot center is better than multiple
independent small centers.
There are still some open issues for robot cloud research. First, in
order to reduce the total cost of robot cloud, we need a clever strat-
egy to select the position of the robot center. A promising solution
could take into account the distribution of requests and the trav-
eling cost, and maintaining cost of different positions to build the
optimization model. Second, How to design flexible collaboration
mechanism to fully utilize the robot resources to tackle more chal-
lenging tasks? For example, a robot game may need many robots
to work together as a team. Finally, the implementation and de-
ployment of robot services may need to be tailored or adapted in
different application domains in order to achieve the optimal per-
formance. It is critical to investigate the conditions and factors that
have biggest impact on the performance of Robot Cloud.
348 Z. Du et al. / Future Generation Computer Systems 74 (2017) 337348
Unmanned aerial vehicles, which have been employed to pro-
vide different services at specific locations for people, can be re-
garded as a special kind of robot. Ubers ice cream is a good
example of this kind of application. We expect to see more of such
applications in the future.
Acknowledgments
This research is supported in part by National Natural Science
Foundation of China (Nos. 61440057, 61272087, 61363019 and
61073008), Beijing Natural Science Foundation (Nos. 4082016
and 4122039), the Sci-Tech Interdisciplinary Innovation and
Cooperation Team Program of the Chinese Academy of Sciences,
the Specialized Research Fund for State Key Laboratories.
References
[1] Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Randy Katz,
Andy Konwinski, Gunho Lee, et al., A view of cloud computing, Commun. ACM
53 (4) (2010) 5058.
[2] Thomas Erl, Service-oriented Architecture: Concepts, Technology, and Design,
Pearson Education India, 2005.
[3] J. Kuffner, Cloud enabled humanoid robots, Humanoids 2010 Workshop
Talks, http://i61www.ira.uka.de/users/asfour/Workshop-Humanoids2010/
talks/James-Kuffner-Humanoids2010.pdfWorkshop-Humanoids2010/talks/
James-Kuffner-Humanoids2010.pdf.
[4] Google Inc. Google apps engine. http://www.google.com/apps.
[5] K. Ostrowski, K. Birman, D. Dolev, J. Ahnn, Programming with live distributed
objects, in: J. Vitek (Ed.), Proceedings of the 22nd European Conference on
Object-Oriented Programming, Paphos, Cyprus, July 0711, 2008, in: Lecture
Notes in Computer Science, vol. 5142, Springer-Verlag, Berlin, Heidelberg,
2008, pp. 463489. http://portal.acm.org/citation.cfm?id=1428508.1428536.
[6] Rob Armstrong, Dennis Gannon, Al Geist, Katarzyna Keahey, Scott Kohn,
Lois McInnes, Steve Parker, Brent Smolinski, Toward a common component
architecture for high-performance scientific computing, in: The Eighth
International Symposium on High Performance Distributed Computing, 1999,
Proceedings, IEEE, 1999, pp. 115124.
[7] Vlad M. Trifa, Christopher M. Cianci, Dominique Guinard, Dynamic control of
a robotic swarm using a serviced-oriented architecture, in: The Proceedings of
the 13th International Symposium on Artificial Life and Robotics, AROB 2008,
Beppu, Japan, January 31February 2, 2008.
[8] Yinong Chen, S. Abhyankar, L. Xu, W.T. Tsai, Marcos Garcia-Acosta: Developing
a security robot in service-oriented architecture, in: The Proceedings of 12th
IEEE International Workshop on Future Trends of Distributed Computing
Systems, FTDCS08, Kunming, China. October, 2008, pp. 106111.
[9] Amazon Web Services. Amazon web services homepage. http://aws.amazon.
com.
[10] K. Lai, L. Rasmusson, E. Adar, S. Sorkin, L. Zhang, B.A. Huberman, Tycoon: an
implementation of a distributed market-based resource allocation system,
Multiagent Grid Syst. 1 (3) (2005) 169182.
[11] Hewlett-Packard, HP Integrated Lights-Out 2 User Guide, Technical Report, HP,
2009.
[12] Sanjay Ghemawat, Howard Gobioff, Shun-Tak Leung, The Google file system,
in: ACM Symposium on Operating Systems Principles, 2003.
[13] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford,
S. Shenker, J. Turner, Openflow: Enabling innovation in college networks, 2008.
[14] Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A.
Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes, Robert E. Gruber,
Bigtable: A distributed storage system for structured data, in: Symposium on
Operating System Design and Implementation, 2006.
[15] PaaS. http://en.wikipedia.org/wiki/Platform_as_a_service.
[16] S. Microsystems, Project caroline. http://research.sun.com/projects/caroline.
[17] Microsoft, Azure Services Platform. http://www.microsoft.com/azure.
[18] M.H. Weier, L. Smith, Businesses get serious about software as a service,
Informat. Week (2007) 4648.
[19] Google Inc. Google docs. http://docs.google.com.
[20] P.A. Laplante, Jia Zhang, J. Voas, Whats in a name? Distinguishing between
SaaS and SOA, IT Prof. 10 (3) (2008) 4650.
[21] Henry E. Schaffer, X as a service, cloud computing, and the need for good
judgment, IT Prof. 11 (5) (2009) 45.
[22] Amazon Elastic Compute Cloud (EC2). http://www.amazon.com/ec2/.
[23] Google App Engine. http://appengine.google.com.
[24] Microsoft Azure. http://www.microsoft.com/windowsazure/.
[25] Sun network.com (Sun Grid). http://www.network.com.
[26] Xingchen Chu, Krishna Nadiminti, Chao Jin, Srikumar Venugopal, Rajkumar
Buyya, Aneka: Next-generation enterprise grid platform for e-science and
e-business applications, in: Proceedings of the 3th IEEE International
Conference on e-Science and Grid Computing, e-Science 2007, Bangalore,
India, December, 2007.
[27] J. Dean, S. Ghemawat, MapReduce: Simplified data processing on large
clusters, in: Symposium on Operating System Design and Implementation,
2004.
[28] L. Zhang, Q. Zhou, CCOA: Cloud computing open architecture, in: Proceedings
of the 2009 IEEE International Conference on Web Services, Los Angeles, CA,
July 06July 10, pp. 607616.
[29] B. Gao, L. He, L. Liu, K. Li, S. Jarvis, From mobiles to clouds: Developing
energy-aware offloading strategies for workflows, in: The 13th IEEE/ACM
International Conference on Grid Computing, Grid, 2012.
[30] B. Gao, L. He, C. Chen, Modelling the bandwidth allocation problem in
mobile service-oriented networks, in: The 18th ACM International Conference
on Modeling, Analysis and Simulation of Wireless and Mobile Systems,
MSWiM15, Cancun, Mexico, November 26, 2015.
[31] J. Markoff, Google cars drive themselves, in Traffic, New York Times,
October 10, 2010. http://www.nytimes.com/2010/10/10/science/10google.
html?pagewanted=1.
[32] Google Goggles. http://en.wikipedia.org/wiki/Google_Goggles.
[33] R. Arumugam, V. Enti, L. Bingbing, et al. DAvinCi: A cloud computing
framework for Service Robots, in: Proceedings of 2010 IEEE International
Conference on Robotics and Automation, Anchorage, AK, USA, May, pp.
30843089.
[34] E. Guizzo, Robots with their heads in the clouds, IEEE Spectr. (2011).
[35] W. Hao, T. Gao, I. Yen, Y. Chen, R. Paul, An infrastructure for web services
migration for real-time applications, in: 2nd IEEE International Symposium on
Service-Oriented System Engineering, Shanghai, 2006, pp. 4148.
[36] Y. Chen, Service-oriented computing in recomposable embedded systems, in:
Joint IARP/IEEERAS/EURON/IFIP 10.4 Workshop on Dependability in Robotics
and Autonomous Systems, Tucson, AZ, February 1519, 2006.
[37] Yinong Chen, Xiaoying Bai, On robotics applications in service-oriented
architecture, in: The 28th International Conference on Distributed Computing
Systems Workshops.
[38] Yinong Chen, Zhihui Du, Marcos Garca-Acosta, Robot as a service in cloud
computing, in: 2010 Fifth IEEE International Symposium on Service Oriented
System Engineering, SOSE, IEEE, 2010, pp. 151158.
[39] MRDS. http://en.wikipedia.org/wiki/Microsoft_Robotics_Developer_Studio.
[40] B. Simion, C. Leordeanu, F. Pop, V. Cristea, A hybrid algorithm for scheduling
workflow applications in grid environments, in: Proceedings of International
Conferences CoopIS, DOA, ODBASE, GADA, and IS, Portugal, 2007, pp.
13311348, http://dx.doi.org/10.1007/978-3-540-76843-2_15.
[41] M. Vasilea, F. Popa, R. Tutueanua, V. Cristeaa, J. Koodziejb, Resource-aware
hybrid scheduling algorithm in heterogeneous distributed computing, Future
Gener. Comput. Syst. 51 (2015) 6171. http://dx.doi.org/10.1016/j.future.
2014.11.019.
[42] L. He, D. Zou, Z. Zhang, C. Chen, H. Jin, S.A. Jarvis, Developing resource
consolidation frameworks for moldable virtual machines in clouds, Future
Gener. Comput. Syst. 32 (2014) 6981.
Zhihui Du received the B.E. degree from the Computer
Department, Tianjin University, in 1992, and the M.S.
and Ph.D. degrees in computer science from Peking
University, in 1995 and 1998, respectively. From 1998 to
2000, he worked at Tsinghua University as a postdoctoral
researcher. Since 2001, he has been an associate professor
at the Department of Computer Science and Technology,
Tsinghua University. His research interests include high
performance computing and grid computing. He is a
member of the IEEE.
Ligang He is an associate professor of University of War-
wick. His research interests include Cloud Computing, Grid
Computing, Cluster Computing, Parallel and Distributed
Processing, High Performance Computing, Performance
Modeling and Evaluation, Real-time Processing. He has
served for many conferences and journals. He has pub-
lished many top level journal and conference papers.
Yinong Chen is a Senior Lecturer of Arizona State
University. He got his Ph.D. degree from University of
Karlsruhe/KIT, Germany. He has published more than 100
conferences and journal papers. He is the Area Editor of the
Elsevier Journal: Simulation Modeling Practice and Theory,
since Jan 2006 and Associate Editor of the International
Journal of Simulation and Process Modelling (IJSPM), since
Jan. 2004.