Towards An Architecture-Centric Approach to Manage Variability of Cloud Robotics

1.6 MB·

by  Lei Zhang

Towards An Architecture-Centric Approach to Manage Variability of
Cloud Robotics
Lei Zhang1, Huaxi (Yulin) Zhang2, Zheng Fang3, Xianbo Xiang4, Marianne Huchard5 and Rene´ Zapata6
Abstract—Cloud robotics is a field of robotics that attempts computation and storage limitation, asynchronization com-
to invoke Cloud technologies such as Cloud computing, Cloud munication,compatibilityproblemofmulti-robotsystems[2],
storage, and other Internet technologies centered around the
but also makes possibility of different directions or en-
7 benefits of converged infrastructure and shared services for
1 robotics. In a few short years, Cloud robotics as a newly hancestheirperformance,suchasremotebrain,bigdataand
0 emergedfieldhasalreadyreceivedmuchresearchandindustrial shared knowledge-base, collective learning and intelligent
2 attention. The use of the Cloud for robotics and automation behavior[3].
n brings some potential benefits largely ameliorating the per- However, beyond these advantages, Cloud robotics also
a formance of robotic systems. However, there are also some brings us many challenges. For example, from the view of
J challenges. First of all, from the viewpoint of architecture, architectures, how to construct the architectures of Cloud
how to model and describe the architectures of Cloud robotic
3 systems? How to manage the variability of Cloud robotic robotic systems? How to model these architectures? How
1
systems? How to maximize the reuse of their architectures? to deploy these architectures in Clouds? How to reuse

In this paper, we present an architecture approach to easily these architectures? How to manage the variability of these
]
O designandunderstandCloudroboticsystemsandmanagetheir architectures?
variability.
R In this paper, we propose a domain specific language –
CRALA trying to response the above questions. Our main
s. I. INTRODUCTION
contributions are to propose:
c
Cloud robotics is a field of robotics that attempts to
[ • anarchitecture-centricdesignprocessforCloudrobotic
invoke Cloud technologies such as Cloud computing, Cloud systems,
1
storage, and other Internet technologies centered around the
v • a domain specific language for architecture-centric
benefits of converged infrastructure and shared services for
8 Cloud robotic systems named CRALA.
0 robotics[1].CloudRoboticswasfirstlyintroducedbyJames The rest of the paper is organized as follows: We begin
6 Kuffner [1]. In a few short years, Cloud robotics as a
with an introduction of related concepts, background and
3 newlyemergedfieldhasalreadyreceivedmuchresearchand
relatedworkofArchitecture-centricCloudrobotics.Wethen
0
industrial attention.
. presentanoverviewofthearchitecture-centricdesignprocess
1 The use of Cloud computing for robotics and automation
for Cloud robotic systems. Then we describe the metamodel
0
brings some potential benefits largely ameliorating the per-
7 of CRALA with examples and how CRALA manages the
formanceofroboticsystems.Duetothelimitedcapacitiesof
1 variability of Cloud robotic systems. Afterwards, we present
: on-board processing, storage and battery capacities, robotic the implementation of CRALA. Finally, we finish with a
v
devices are constrained to numerous limitations. It not only
i discussion and future work.
X solves the problems of robotic systems, such as on-board
II. BACKGROUNDANDRELATEDWORK
r
a *This work was supported by the National Natural Science Foundation A. Related concepts
of China under Grant No. 61300020, the Scientific Research Funds for
IntroducedTalentsofNortheasternUniversityunderGrantNo.28720524. Architecture-centric Cloud robotics is a methodology of
1Lei Zhang is with State Key Laboratory of Synthetical Automa- developing robotics systems on Clouds using architecture-
tion for Process Industries, Northeastern University, Shenyang, China,
centric development techniques.
[email protected]
2Huaxi (Yulin) Zhang is with MIS and INSSET, Universite´ de Cloud computing Cloud computing is defined by the
Picardie Jules Verne, 33, rue Saint Leu, 80039 Amiens, France, National Institute of Standards and Technology (NIST) as:
[email protected]
”Cloudcomputingasamodelforenablingubiquitous,conve-
3Zheng Fang is with State Key Laboratory of Synthetical Automa-
nient, on-demand network access to a shared pool of config-
tion for Process Industries, Northeastern University, Shenyang, China,
[email protected] urable computing resources (e.g., networks, servers, storage,
4XianboXiangiswithSchoolofNavalArchitectureandOceanEngineer- applications, and services) that can be rapidly provisioned
ing, Huazhong University of Science and Technology, 1037, Luoyu Road,
430074,Wuhan,China,[email protected] and released with minimal management effort or service
5Marianne Huchard is with LIRMM, UMR 5506, CNRS et Uni- provider interaction [4]”.
versite´ Montpellier 2, 161 rue Ada, 34392 Montpellier, France, Clouds offer services that can be grouped into three
[email protected]
categories:softwareasaservice(SaaS),platformasaservice
6Rene´ Zapata is with LIRMM, UMR 5506, CNRS et Universite´ Mont-
pellier2,161rueAda,34392Montpellier,France,[email protected] (PaaS), and infrastructure as a service (IaaS) [5].
1) Infrastructure as a Service: IaaS refers to on-demand
provisioning of infrastructural resources, usually in
terms of VMs (Virtual Machines). The cloud owner
who offers IaaS is called an IaaS provider.
2) Platform as a Service: PaaS refers to providing plat-
form layer resources, including operating system sup-
port and software development frameworks.
3) Software as a Service: SaaS refers to providing on-
demand applications over the Internet.
An explicit architecture of Cloud robotic system should
cover these three design services in its architecture.
System/Software architectures. Traditionally, software
architecture is a collection of models that capture a software
systems principal design decisions in the form of compo-
nents (foci of system computation and data management),
connectors (foci of component interaction), and configura-
tions (specific arrangements of components and connectors Fig.1. Cloudroboticsystemarchitecturedesign
intendedtosolvespecificproblems)[6].Generallyspeaking,
a software system architecture [7] gathers design decisions
of the system. As the development of computer science, Many work try to develop an OWL (Web Ontology
nowadays, a system is much more complex than before Language)ontologytodescriberobots,suchas [13],[14]in
such as with the integration of ”Internet of Things”, ”Cloud specific domains or [15], [16] focusing on sensor ontology.
Computing” and ”Robotics” etc. Web service description. Web service description in
robotics often serves to match the capabilities with robot
Architectures Modeling language. Architecture models
components,suchasPHOSPHORUS[17],Larks[18],OWL-
are often expressed using ADLs (Architecture Description
S[19]andSRDL[12].Ingeneral,thetermcapabilitymatch-
Language) that, in most cases, provides information on
making refers to the process of matching an advertisement
the structure of the software system listing the compo-
of a capability with a request.
nents/services and connectors that the system is composed
Cloud Robotic description. All above work cover a
of. A system architecture could cover different abstraction
part description of Cloud robotic systems, referring to robot
levels, such as specification, configuration and assembly [8]
description or web service description. However, it misses a
andfromdifferentviewpoints[9].ForCloudroboticsystem,
language that fully covers all necessary aspects of Cloud
architecture model also needs to capture Cloud and robot
robotic architecture, including the description of Clouds,
design decisions.
robots and components/web services.
B. Related Work III. ARCHITECTUREDESIGNFORCLOUDROBOTICS
The description of Cloud robotic systems should cover The architecture design for Cloud robotic system is dif-
robot description, web services/component description and ferent from traditional software design, as it concerns two
cloud robotic system global architecture description. special aspects: Cloud-based systems and robotic systems.
Robot description. Robot description languages provide We identify the architecture-centric development process for
modelsofarobotandthendesignandimplementedsoftware Cloud robotic systems into three main phases, as shown in
components that work on the model components rather than Figure 1.
the particular robot instance. 1) Specification design. Architect or robotics engineers
The representative example of robot description language should choose a robotic architecture pattern for the
istheUnifiedRobotDescriptionFormat(URDF)[10],which system according the models of robots (hardware) and
can be used to specify the kinematics and dynamics, the its functional tasks (objective), for example, a pioneer
visual representation and the collision model of a robot. robot with a task of path planning.
However, URDF is not designed for specifying robot com- 2) Configuration design.
ponents such as sensors, actuators, and control programs. • First of all, architect should consider how to dis-
COLLADA [11] is an XML Schema designed for de- tribute intelligence among robots and Cloud. That
scribing 3D objects including their kinematics. It mainly means,whichcomponentsshouldbeplacedonthe
focuses on modeling information about scenes, geometry, robotitselfandwhichservicesshouldbeplacedon
physics, animations, and effects. But similar to URDF, it Cloud.Howtochoosetheappropriatecomponents
lacks elements for describing sensors, actuators and soft- or services from component or service repository.
ware. SRDL [12] focuses on modeling robot components, This design decision refers to different factors,
i.e. sensors, actuators and control programs, especially via including robot capacities, system non-functional
capabilities to actions. properties such as real-time, security etc.
TABLEI
DECISIONDECISIONSMADEINEACHARCHITECTUREABSTRACTION
MODEL
Architecture DefinedAspects
Architecturespecification 1)Functionalitiesofthesystem,2)
systemnon-functionalproperties
Architectureconfiguration 1)Component/serviceselection(for
reuse)orimplementation(forfrom
scratch),2)Component/servicegroup,
and3)Operatingsystemselection
Systemassembly 1)Clouddeployment,2)Runningstate
supplied by robotic systems. All the constituents of
this architectural models are abstract and without any
consideration of Cloud etc.
2) Configurationdefinesthesetsofcomponentorservice
Fig.2. Cloudroboticsystemarchitecturedesign implementations (classes) by searching and selecting
fromthecomponent/servicerepositoryanddefineshow
to group services and components in different virtual
• Secondly, architect should choose operating sys- or physical machines by consideration of system re-
temfortheirservices,asinroboticsdomain,there
quirements.
exists some operating systems that are widely
3) Assembly depicts how configuration is deployed on
used, such as ROS[20]. Then, how to distribute
Clouds. This architecture model exactly depicts the
these services in different virtual machines.
current state of Cloud robotic system on Cloud.
3) Assemblydeployment.Lastly,howtodeploythisarchi-
Table I presents the design decisions that should be made
tecturemodelinClouds,automaticallyornot?Howto
in each architecture level.
reflect and supervise a runtime model to prevent VMs
failure etc.?
A. Architecture Specification
During the process, five factors affect architecture design
Architecture specification is composed by component
decisions robot models, tasks, intelligence, non-functional
roles, connections and Concept robots. The metamodel1 of
properties, and Clouds, as shown in Figure 2.
specification is illustrated in Fig. 3(a).
• Robotmodeldescribesthehardwaremodeloftherobots
consisting of sensors and actuators etc. • Component roles describe the roles that components
should play in the system. In Cloud robotic systems,
• Task is the objective realized by robots.
a roles could be a function (such as algorithm), a
• Intelligence distribution defines how to distribute the
database, or a driver etc. A component role lists the
intelligence to robots and Clouds.
minimumlistofinterfaces(bothrequiredandprovided)
• Non-functional properties are non-functional require-
thecomponent/service(willbeselectedorimplemented
mentsrequiredtobeexposedbyCloudroboticsystems,
inconfigurationlevel)shouldexpose.Ontheonehad,as
such as security, realtime, safety etc.
they define the requirements of the architect (its ideal
• Clouds represent Cloud infrastructures (IaaS) used to
view) to guide the search for corresponding concrete
deploy robotics services. Clouds can be mono-cloud or
components (or service) in component (or service)
multi-Cloud.
repository, component roles are abstract and partial
IV. CRALA:ADOMAINSPECIFICLANGUAGE component (or service) representations. On the other
hand, they can be used as the design specification for
CRALA is a domain specific language for architecture-
implementingnewcomponentsorservicesfromscratch.
centric Cloud robotics, and it is also an architecture descrip-
ForexampleinFig.3(b),Spec1definesthreecomponent
tionlanguage.CRALAmodelsarchitecturesatthreeseparate
roles to fulfill three different functionalities.
abstraction levels, each designed in a different development
• Concept robots define the robots that will be included
phase as shown in Fig. 1. For now, the first version of
inthesystemwithcertainsensorsoractuatorstorealize
CRALApresentedinthispapermainlyfocusesonmodeling
the functionalities of the system. At this level, concept
essentialelementsofarchitecturesandtheirbasicproperties,
robot is totally abstract, and it only defines the types of
as the design concept of CRALA is to auto-develop and
sensorandactuators.Inspecification,wedonotprecise
enrich the language by experimentation and real use cases.
themodelofrobotused.AsshowninFig.3(b),Robot1
The three levels are as follows:
1) Specification defines the abstract architecture spec-
1Inthispaper,weignoreinterfacesaspectsandallattributesinmetamodel
ification. It defines which functionality should be forsakeofsimplicity.
Fig.4. ArchitectureConfigurationMetamodel
2) Component roles will be implemented by component
classes or web services by selection or implementa-
tions according to different system requirements or
used robot models.
• Componentclass:Acomponentclassoftencanbe
characterized as: attributes, component interface,
behaviors and properties.
Fig.3. ArchitecturespecificationMetamodelandexample
• Web service: A more formal and extended defini-
tion is the one offered by the W3C Web Services
could be any robot with an camera, such as pionner, working group[21]:A Web service is a software
NAO etc. systemdesignedtosupportinteroperablemachine-
• Connections2 define the communication between archi- to-machine interaction over a network. It has an
tecture elements including roles, robots, actuators and interface described in a machine-processable for-
sensors.WithCRALAconnectionconstraints,thecom- mat (specifically WSDL). Other systems interact
municationallowedcouldbecategorizedinthreetypes: with the Web service in a manner prescribed by
(1) the communication between component roles, (2) its description using SOAP-messages, typically
the communication between component roles (drivers) conveyed using HTTP with an XML serialization
and sensors and (3) the communication between com- in conjunction with other Web-related standards.
ponent roles (drivers) and actuators. However at spec- 3) Then,componentsandserviceswillbeplacedinrobots
ification level, we define also one kind of ”abstract” or virtual machines3.
connection between robots and component roles. The 4) Lastly, the connections should be established, for ex-
connection signifies the connected component roles ample which kind of communication protocols will
must communicate with robots at next configuration be used in different situations. We could find the
level (components could locate directly in robots or connection between robots and components are not
connect with robots from Cloud.). permitted at this level (the same for next assembly
level).
B. Architecture Configuration
According to the selection of different component classes
Architecture configurations are the second level of system and services and the distribution of these components in
architecture descriptions. They result from the search and robots and VMs, it could lead to different configuration
selection of real component classes (or web services) in a architectures, which implement the same specification archi-
component (or service) repository. The metamodel is shown tecture.
in Fig. 4. Figure 5(a) and 5(b) represent two different possible
1) Weprecisewhichrobots(RobotModel)willbeusedin configurationarchitecturesofspecificationSpec1inFig.3(a).
configuration. Robot models should expose all sensors In Config1, two services LocalisationService and PathPlan-
and actuators specified in concept robot of Specifica- ningService locate in two separated VMs, and in Config2,
tion.
3In the first version of CRALA, we ignore the possibility that besides
2For sake’s simplicity, the details of connection and its constraints are virtualmachines,forwebservicescouldalsobeplacedinphysicalmachines
notdiscussedinthispaper. directly.
Fig.6. AssemblyMetamodel
– Network: For example, if Cloud is an Open-
Stack [22] nova-network (FLAT) Cloud. The net-
work of this kind of Cloud is linux-bridge, so
all the VMs locate in the same network. If we
want two VMs located in two subnets, it’s im-
possible. However, with OpenStack neutron (SDN:
Fig.5. ArchitectureConfigurationExampleConfig1andConfig2 Software-Defined Network) Cloud, it’s possible.
– Scheduling: Scheduling in Clouds is complicated
and it’s extremely important for Cloud robotic sys-
they are located in the same VM. The reliability of Config1 tems.SomeNFPssuchasreliability,securitycould
is better than Config2, as if the VM of Config2 is broken, bedirectlyappliedbyusingdifferentschedulingal-
both two services are lost at the same time. However, in gorithms.OneCloudcouldapplymultipleschedul-
Config1, two services use more calculating resource, as they ing algorithms with different priorities. Normally
are located in two VMs compared to one. different Clouds use different scheduling algo-
rithmsaccordingtodifferentrequirements.Accord-
C. System assembly ing to different scheduling algorithms of Cloud,
architecture configuration could be deployed in
System assemblies are the third level of system architec-
different ways, as shown in Fig. 7(a) and 7(b). For
turedescriptions.Atthemacroscopiclevel,Theyresultfrom
the first example, two VMs are located in different
the deployment of VMs of configuration in Clouds. At the
physicalmachines,andforthesecondexample,two
microscopic level, they result from the instantiation of the
VMs are located in the same physical machine. In
component classes and the deployment of the web services
Ass2, two VMs communicate faster than Ass1, as
fromaconfiguration.Theimportantthingisthattheyshould
theylocateinthesamephysicalmachine.However,
provide a description of runtime software systems including
inAss1,twoVMscouldprofitthemaximizeRAM,
Cloud deployment description.
as they are the only VM in each physical machine.
The metamodel of Cloud is illustrated in Fig. 6. Each
component or service are defined clearly which VMs or • Physical machine: Normally in one Cloud, clients (ten-
robots they are deployed and each VM is illustrated with ants) could not see which physical machines locate
which physical machine of which Cloud it is deployed. theirVMs.Onlyadministratorscouldknowthiskindof
System assemblies are the most related level to Cloud. information for security. In order to raise the clarity of
• Cloud: Different Clouds directly affect the deployment Cloud, we add this information to assembly level. This
results of configurations. could make easier to control Cloud robotic systems.
Fig.7. AssemblyMetamodelandexamples
Fig.9. TheLocalizationcomponentrole,somepossibleconcreterealiza-
tionsandsomeoftheirinstantiations
Fig.8. Thevariabilityofexamplearchitectures
ponents in three levels. It shows the relationship of different
D. The variability
component forms in three levels: component roles (specifi-
The variability of software architecture often cites SPL cation),component/service(configuration)andcomponentor
(Software Product Line). In SPL, the variability is inside service instance (assembly).
in configuration level. A reference architecture could be In our viewpoint, if we could combine these two kinds of
implementedbydifferentpossibleconfigurationswithcertain variability: horizontal and vertical in our future work, it will
limit choices. In CRALA, variability is horizontal, which is greatly increase the feasibility and reusability of CRALA.
reflected in the relationships between three levels. We use
illustrating examples to explain how CRALA manages the
variability of Cloud robotic systems from microscopic and V. IMPLEMENTATION
macroscopic views.
Firstly,frommacroscopicview,thevariabilityofarchitec- We used the Ecore framework [23] and Sirius [24] for
tures could be captured by their relationships between dif- CRALA.EcoreallowscreateatreeeditorforaDSLaccord-
ferent architecture levels, as shown in Fig. 8 (a). Figure 8(b) ingtoitsmetamodel,asshowinFig.10.SiriusisanEclipse
illustrates the relationships of example architectures Arch1 projectwhichallowsyoutoeasilycreateyourowngraphical
presented earlier in this section and it’s generated automat- modeling workbench including generating graph of models
ically by CRALA toolsuite according to the relationships oreditinggraphicalmodels.ThemodelscreatedbyCRALA
defined in architecture models (Fig. 3(b), 5(a,b) and 7(a,b)). Ecore plugins could be automatically expressed in graphs.
Secondly from microscopic view, the variability is re- Figures 3(b), 5(a,b), 6(a,b) and 8 are graphs generated from
flected by components. Fig. 9 presents an example of com- CRALA models.
[8] H. Y. Zhang, C. Urtado, and S. Vauttier, “Architecture-centric
component-based development needs a three-level adl,” in Software
Architecture. Springer,2010,pp.295–310.
[9] P. Clements, D. Garlan, L. Bass, J. Stafford, R. Nord, J. Ivers, and
R. Little, Documenting software architectures: views and beyond.
PearsonEducation,2002.
[10] Unified robot description format. [Online]. Available:
http://www.ros.org/wiki/urdf
[11] R. Diankov, R. Ueda, K. Okada, and H. Saito, “Collada: An open
standard for robot file formats,” in Proceedings of the 29th Annual
ConferenceoftheRoboticsSocietyofJapan,AC2Q1–5,2011.
[12] L. Kunze, T. Roehm, and M. Beetz, “Towards semantic robot de-
scriptionlanguages,”inRoboticsandAutomation(ICRA),2011IEEE
InternationalConferenceon. IEEE,2011,pp.5589–5595.
[13] C.SchlenoffandE.Messina,“Arobotontologyforurbansearchand
rescue,” in Proceedings of the 2005 ACM workshop on Research in
knowledgerepresentationforautonomoussystems. ACM,2005,pp.
27–34.
[14] R.ChatterjeeandF.Matsuno,“Robotdescriptionontologyanddisaster
scenedescriptionontology:analysisofnecessityandscopeinrescue
infrastructure context,” Advanced Robotics, vol. 19, no. 8, pp. 839–
859,2005.
[15] M.Compton,C.Henson,L.Lefort,H.Neuhaus,andA.P.Sheth,“A
surveyofthesemanticspecificationofsensors,”2009.
[16] M. Compton, H. Neuhaus, K. Taylor, and K.-N. Tran, “Reasoning
Fig.10. AsampleofCRALAEcoreeditor
aboutsensorsandcompositions.”inSSN. Citeseer,2009,pp.33–48.
[17] Y. Gil and S. Ramachandran, “Phosphorus: A task-based agent
matchmaker,” in Proceedings of the fifth international conference on
VI. CONCLUSIONANDFUTUREWORK Autonomousagents. ACM,2001,pp.110–111.
[18] K. Sycara, S. Widoff, M. Klusch, and J. Lu, “Larks: Dynamic
Inthispaperweinvestigatearchitecturedesignprocessfor matchmaking among heterogeneous software agents in cyberspace,”
Cloud robotic systems and propose a domain-specific archi- Autonomous agents and multi-agent systems, vol. 5, no. 2, pp. 173–
203,2002.
tecture description language for architecture-centric Cloud
[19] D. Martin, M. Burstein, D. Mcdermott, S. Mcilraith, M. Paolucci,
robotics. We present CRALA for describing Cloud robotic K.Sycara,D.L.Mcguinness,E.Sirin,andN.Srinivasan,“Bringing
architectures, and show that linking architecture descrip- semanticstowebserviceswithowl-s,”WorldWideWeb,vol.10,no.3,
pp.243–277,2007.
tions with Cloud deployment aspect allows mastering and
[20] Robotoperatingsystem.[Online].Available:http://www.ros.org/
controlling Cloud robotic systems and their variability. The [21] Webservicesglossary.[Online].Available:http://www.w3.org/TR/ws-
proposed language is implemented by EMF and Sirius and gloss/
[22] Openstackcloudsoftware.[Online].Available:http://openstack.org
we use a use case to illustrate CRALA. [23] D.Steinberg,F.Budinsky,E.Merks,andM.Paternostro,EMF:eclipse
In future work, we aim to extend CRALA in several modelingframework. PearsonEducation,2008.
[24] V. Viyovic, M. Maksimovic, and B. Perisic, “Sirius: A rapid devel-
ways. We would like to develop some mechanisms to sup-
opment of dsm graphical editor,” in Intelligent Engineering Systems
port the automatically developing process of architecture- (INES), 2014 18th International Conference on. IEEE, 2014, pp.
centric Cloud robotic systems. First of all, how to search 233–238.
the correspondent and appropriate components or services
in repository to construct architecture configuration auto-
matically. Secondly, how to deploy the configuration on
Cloud automatically. Then how to reorganize the system on
Clouds when service failure. Our overall goal is to construct
an intelligent development environment to construct Cloud
robotic systems.
REFERENCES
[1] J. J. Kuffner, “Cloud-enabled robots,” in IEEE-RAS International
ConferenceonHumanoidRobotics,Nashville,TN,2010.
[2] G.Mohanarajah,D.Hunziker,R.D’Andrea,andM.Waibel,“Rapyuta:
Acloudroboticsplatform,”2014.
[3] B.QureshiandA.Koubaˆa,“Fivetraitsofperformanceenhancement
usingcloudrobotics:Asurvey,”ProcediaComputerScience,vol.37,
pp.220–227,2014.
[4] P.MellandT.Grance,“Thenistdefinitionofcloudcomputing,”2011.
[5] Q. Zhang, L. Cheng, and R. Boutaba, “Cloud computing: state-of-
the-art and research challenges,” Journal of internet services and
applications,vol.1,no.1,pp.7–18,2010.
[6] D. E. Perry and A. L. Wolf, “Foundations for the study of software
architecture,” ACM SIGSOFT Software Engineering Notes, vol. 17,
no.4,pp.40–52,1992.
[7] R.N.Taylor,N.Medvidovic,andE.M.Dashofy,Softwarearchitec-
ture:foundations,theory,andpractice. WileyPublishing,2009.