=Paper=
{{Paper
|id=Vol-2245/modcomp_paper_6
|storemode=property
|title=A Component-Based and Model-Driven Approach to Deal with Non-Functional Properties Through Global QoS Metrics
|pdfUrl=https://ceur-ws.org/Vol-2245/modcomp_paper_6.pdf
|volume=Vol-2245
|authors=Cristina Vicente-Chicote,Juan F. Ingles-Romero,Jesus Martinez,Dennis Stampfer,Alex Lotz,Matthias Lutz,Christian Schlegel
|dblpUrl=https://dblp.org/rec/conf/models/Vicente-Chicote18
}}
==A Component-Based and Model-Driven Approach to Deal with Non-Functional Properties Through Global QoS Metrics==
https://ceur-ws.org/Vol-2245/modcomp_paper_6.pdf
A Component-Based and Model-Driven Approach to Deal with
Non-Functional Properties through Global QoS Metrics
Cristina Juan F. Inglés-Romero Jesús Martínez Dennis Stampfer
Vicente-Chicote Biometric Vox, S.L. Universidad de Málaga Alex Lotz
Universidad de Murcia, Spain Málaga, Spain Matthias Lutz
Extremadura juanfran.ingles@ jmcruz@lcc.uma.es
biometricvox.com
Christian Schlegel
Cáceres, Spain Hochschule Ulm
cristinav@unex.es Ulm, Germany
@hs-ulm.de
ABSTRACT better software, which then allow building better robotic systems.
Non-functional properties play a key role in most software systems. RobMoSys aims at creating an open, sustainable, agile and multi-
There is a lot of literature on what non-functional properties are domain European robotics software ecosystem. RobMoSys seeks to
but, unfortunately, there is also a lot of disagreement and different enable the composition of robotics applications with managed, as-
points of view on how to deal with them. Non-functional proper- sured, and maintained system-level properties using Model-Driven
ties, such as safety or dependability, become particularly relevant Engineering (MDE) techniques from a CBSD perspective. To achieve
in the context of robotics. In the EU H2020 RobMoSys Project, non- its goals, RobMoSys establishes structures that enable the manage-
functional properties are treated as first-class citizens and consid- ment of the interfaces between different robotics-related domains,
ered key added-value services. In this vein, the RoQME Integrated different roles in the ecosystem, and different levels of abstraction.
Technical Project, funded by RobMoSys, aims at contributing a RobMoSys financially supports, through a cascade funding scheme
component-based and model-driven tool-chain for dealing with scheduled in two open calls, third party contributions as means
system-level non-functional properties, enabling the specification to achieve its own objectives. RoQME: Dealing with non-functional
of global Quality of Service (QoS) metrics. The estimation of these properties through global Robot Quality-of- Service Metrics [21] has
metrics at runtime, in terms of the contextual information available, been one of the six selected Integrated Technical Project (ITP) to
can then be used for different purposes, such as robot behavior be funded in the context of the first RobMoSys open call (out of the
adaptation or benchmarking. thirty four proposals submitted).
The main intended goal of RoQME is to provide robotics soft-
KEYWORDS ware engineers with a model-driven tool-chain allowing them to:
(1) model relevant system-level non-functional properties in terms
Non-Functional Properties, QoS Metrics, Model-Driven Engineer-
of the (internal and external) contextual information available at
ing, Component-Based Software Development, Robotics, RoQME.
runtime; and (2) generate a RobMoSys-compliant component, ready
to provide other components with QoS metrics defined on the non-
1 INTRODUCTION
functional properties, previously specified.
Component-Based Software Development (CBSD) aims at promot- This paper describes the RoQME foundations, laid down during
ing software reuse for significantly reducing development time and the initial stage of the project, namely: (1) the new role of QoS
cost. Existing solutions are encapsulated in well-defined compo- Engineers and how it integrates with the other roles considered in
nents with clear (required and provided) interfaces that enable their RobMoSys; (2) the RoQME and the RoQME-to-RobMoSys Mapping
connection to and interoperation with other components. Building meta-models, which gather the main modeling concepts and their
systems out of components requires taking into account both func- relation to those included in the RobMoSys meta-models; and the
tional and non-functional properties. Non-functional properties process (including the relevant roles, models and tools) we propose
define how a system performs rather than what it does [25]. Ex- to enable the modeling (at design-time) and estimation (at runtime)
amples of non-functional properties include timing, dependability, of metrics defined on system-level non-functional properties.
safety or resource consumption, among others. Despite the impor- RoQME will run for one year, starting March 2018. Achieving
tance of non-functional properties, there are just a few component substantial results in such a short period of time requires building on
models explicitly supporting their specification and management previous results. In this vein, the RoQME partners contribute solid
throughout the development process. In most cases, this support background in Robotics, Component-Based Software Development,
is limited and, unlike the well-established solution of embodying and Model-Driven Engineering [1, 2, 6, 10–14, 18, 19, 23]. Apart
functional properties into interfaces, no consensus has emerged on from the fruitful relationship existing among the RoQME partners,
how to handle non-functional properties both at a component and which already resulted in some preliminary results [5, 9, 17, 22],
at a system level [25]. it is worth mentioning our close collaboration with some of the
RobMoSys: Composable Models and Software for Robotics [20] is a RobMoSys partners in line with the current goals of the Project [8,
4-year Project (2017-2020), funded by the EU H2020 Research and In- 15–17, 24]. This will undoubtedly contribute to align RoQME to the
novation Program under grant agreement No. 732410. The vision of RobMoSys vision, guiding principles, and structures.
RobMoSys is to create better models, as the basis for better tools and
ModComp’18. Copenhagen (Denmark), 2018 C. Vicente-Chicote et al.
The rest of the paper is organized as follows. Firstly, Section 2 DESIGN-TIME RUN-TIME
RoQME Model Global QoS Metrics Provider
presents an overview of the RoQME project, introducing its main
Abstract non-functional properties
• Non-functional properties
intended goals and contributions. Secondly, Section 3 introduces the • Context variables Estimations
RobMoSys project and outlines how RoQME plans to integrate into • Observations based on Probabilistic Reasoning E.g., the robot task
M2T
context patterns and rules sequencer may
its Ecosystem, focusing on the description of the new QoS Engineer Observations use the resulting
Event processing QoS metrics for
role. Then, Section 4 introduces the main modeling concepts gath- deciding among
Events alternative tasks,
ered in the RoQME meta-models and illustrates them through some Mapping model
Context monitoring activating or de-
practical examples. And, finally, Section 5 draws some conclusions activating certain
components, or
Communication
and outlines current and future works. Objects
setting component
RobMoSys Structures params within their
(models) Context information allowed range
2 ROQME OVERVIEW
Figure 1: Main RoQME elements, models and tools.
RoQME intends to support the role of QoS Engineers (see Sec-
tion 3.2), providing them with a specific QoS View that allows them
to model system-level non-functional properties according to the (1) a context monitor that will receive raw contextual data and will
RoQME meta-model (see Section 4). This new role, view and meta- produce context events (e.g., changes in the battery level); (2) an
model complement and interrelate with those already defined in event processor that will search for the event patterns specified in
RobMoSys through the so called RoQME-to-RobMoSys mapping the RoQME model and, when found, will produce observations (e.g.,
meta-model. This mapping aims at promoting good design princi- battery is draining too fast); and, finally (3) a probabilistic reasoner
ples, such as high cohesion and loose coupling among the different that will compute a numeric estimation for each metric (i.e., the
RobMoSys views, providing a non-intrusive way of extending the degree of fulfillment of each non-functional property).
RobMoSys meta-model, i.e., modifying the RoQME meta-model
would only imply adapting the mapping but not the RobMoSys 3 ROQME IN THE CONTEXT OF ROBMOSYS
meta-model and, vice versa, new versions of the RobMoSys meta-
RoQME focuses on the modeling (at design-time), management and
model would imply adapting the mapping, but not the RoQME
measurement (at runtime) of non-functional properties. To achieve
meta-model.
it, RoQME extends the core structures, roles and views, laid down by
RoQME will allow QoS Engineers to model context variables
RobMoSys, by defining the RoQME meta-models (later introduced
(e.g., battery level) and, from them, relevant context patterns (e.g.,
in Section 3.2 and a new QoS Engineer role, which is provided with
“the battery level drops more than 1% per minute”). The detection
a new modeling view for describing the non-functional aspects of
of a context pattern will be considered an observation associated
robotic applications.
with a variable in a belief network. Belief networks will be used
Before detailing the activities carried out and the models devel-
to specify the dynamics of non-functional properties (e.g., power
oped by the QoS Engineers, let us briefly review the main RobMoSys
consumption). The degree of fulfillment of these non-functional
principles, structures and roles, as they define the QoS Engineers
properties will then be used to estimate the QoS metrics, obtained
working context.
as real values in the range [0, 1].
RoQME aims to be application domain agnostic, providing QoS
3.1 Main RobMoSys Tiers, Structures and Roles
Engineers with a compact set of modeling tools to express system-
level QoS metrics. However, it is being designed to be as flexible RobMoSys proposes an Ecosystem organized into three tiers, ar-
as possible, e.g., supporting extension mechanisms that allow QoS ranged along levels of abstraction (see Figure 2). Tier 1, shaped
Engineers (or other RobMoSys roles, such as Safety Engineers or by few representative Robotics Experts, defines the overall com-
Performance Designers) to enrich and customize the RoQME mod- position structures to which the lower tiers must conform. Tier 2,
eling capabilities with domain-specific requirements (e.g., related structures particular robotics sub-domains, such as SLAM, manipu-
to safety, dependability, etc.). lation, object recognition, etc. Tier 2 is shaped by Domain Experts
The RoQME tool-chain, delivered as an Eclipse plug-in, will pro- and conforms to the foundations laid down in Tier 1. Finally, Tier 3,
vide both modeling and code generation tools, enabling the creation conforms to the domain-structures defined in Tier 2, and provides
of RobMoSys-compliant components, readily usable in RobMoSys- reusable building block (developed by Component Suppliers and
based solutions as QoS information providers (see Figure 1). This Behavior Developers), readily available to be integrated (by System
information could then be used by other components for different Builders) into different robotic systems.
purposes, e.g., robot behavior adaptation or benchmarking. In this RobMoSys considers a large number of loosely interconnected
line, a preliminary result on how to use the RoQME metrics as an participants that depend on each other for their mutual effectiveness
input in a reinforcement learning problem can be found in [7]. and individual success. RobMoSys is about managing the interfaces
Internally, the generated component will estimate the value of between different roles (Domain Experts, System Architects, Com-
each non-functional property, specified in the RoQME model, by ponent Suppliers, Behavior Developers, System Builders, etc.) and
successively processing the available contextual information, either separate concerns in an efficient and systematic way.
from internal (e.g., robot sensors) or external (e.g., web services, According to the information available in the RobMoSys Wiki1 ,
other robots, etc.) sources. The contextual information received by System Architects define the functional requirements of robotic
the component will be sequentially processed by three modules: 1 https://robmosys.eu/wiki
A Component-Based and Model-Driven Approach to Deal with Non-Functional Properties (...) C. Vicente-Chicote et al.
(1) Domain Experts could define relevant domain-specific non-
functional properties specifications in terms of reusable RoQME
models.
(2) QoS Engineers can search and select (one or more) existing
non-functional properties specifications from the Ecosystem.
The selected properties will be added to their RoQME models,
together with their associated Contexts and Observations.
(3) QoS Engineers model application-specific non-functional
properties. From them, the following artifacts will be auto-
matically generated:
• A Service Definition, in order to make the metrics calcu-
lated on the different non-functional properties available
Figure 2: The RobMoSys Ecosystem: tiers, roles and ele- to other components as a service.
ments [20] • A Service Wish (as an instance of the previous Service Def-
inition). This Service Wish will be available to the System
Architect in case he/she wants to create a Service Link
(i.e., a use dependency, for example, for benchmarking or
applications in terms of Service Wishes (e.g., navigation, location, adaptation purposes) from some of the Service Wishes pre-
handover, etc.) and create Service Links among them when needed. viously included in the System Service Architecture Model.
Service Links (specified as uses relationships) identify component- Note that the generated Service Wish will be realized by
independent inter-service dependencies (i.e., if a Service Wish A the “QoS Metric Provider” Component, also generated by
depends on the existence of another Service B, then a relationship the RoQME generation engine (in a later step). Thus, this
"A uses B" needs to be modeled). Each Service Wish, defined by the component will be available to the System Builder in order
System Architect in Tier 3, is an instancesOf a Service Definition, to fulfill the corresponding Service Wish.
previously modeled by a Domain Expert in Tier 2. Service defini- (4) QoS Engineers select relevant Contexts by searching among
tions are reusable artifacts (at least within a robotics sub-domain) the Service Definitions available in the Ecosystem (i.e., con-
that can be instantiated as many times and in as many applications text providers). For each of these contexts:
as needed. • A new element will be created in the RoQME-to-RobMoSys
In order to realize the Service Wishes defined by the System (R2R) Mapping Model with a reference both to the Context
Architect, the System Builder selects applicable components and and to the corresponding Service Definition. The R2R Map-
behaviors (task plots) from the RobMoSys Ecosystem (developed ping Model conforms to the R2R Mapping Meta-Model,
by Component Suppliers and Behavior Developers, respectively) which provides a loose coupling mechanism between the
and connects them appropriately to obtain the final application. RoQME and the RobMoSys modeling concepts (i.e., in case
This (very briefly) summarizes the typical workflow that needs to any of the two meta-models is modified or evolves, the
be followed to come up with a robotics application according to the other will remain unaltered; only the mapping meta-model
RobMoSys structures and guidelines (see Figure 3). The following will need to be modified accordingly).
section introduces the new role of the QoS Engineers, contributed • A Service Wish will be automatically generated and added
by RoQME, and details how they interact with the other roles within to the RoQME Model as an instance of the correspond-
the RobMoSys Ecosystem. ing Service Definition. This Service Wish will need to be
later realized by the System Builder by selecting the ap-
propriate Component/Task Plot (context provider) from
3.2 QoS Engineers in Action the RobMoSys Ecosystem.
Both functional and non-functional requirements should respond (5) QoS Engineers define application-specific Observations in
to customer or business needs, either directly or indirectly. In this terms of one or more of the previous Contexts. An Observa-
sense, RoQME provides the means to support: (1) the evaluation of tion is an evidence reinforcing (or undermining) the belief
non-functional requirements, e.g. to check statements such as "the that the system is optimal in terms of one or more of the
robot should perform at least GOOD with respect to PERFORMANCE"; non-functional properties previously defined.
(2) benchmarking, e.g. to test the impact of different robot real- (6) The QoS Engineer generates the "QoS Metric Provider" Com-
izations on SAFETY ; and (3) self-adaptation, e.g., the robot could ponent from the resulting RoQME Model and makes it avail-
select, at runtime, its navigation strategy so that PERFORMANCE is able to the System Builder.
maximized. Therefore, non-functional properties and the metrics (7) In order to realize the Service Wishes included both in the
defined to quantify them, offer many possibilities, from assessing System Service Architecture Model (developed by the System
requirements fulfillment to dynamic adaptation of the robot behav- Architect) and in the RoQME Model (developed by the QoS
ior. Engineer), the System Builder selects applicable components
Figure 3 shows an overview of the RoQME and RobMoSys roles, and behaviors (task plots) from the RobMoSys Ecosystem
models and relationships. In the following, we describe the process (provided by Component Suppliers and Behavior Developers,
by presenting the actions of the roles involved in relation to RoQME.
ModComp’18. Copenhagen (Denmark), 2018 C. Vicente-Chicote et al.
Domain-Specific Service [1..1] instanceOf
RoQME model Definition
Domain Expert
[1..*] reuses [1..1] serviceDef Tier 2
Tier 3
R2R Mapping
Model
Context
Mapping
C
Provider
System Builder
[1..1] context realizes
Service RoQME QoS Metrics
Context Wish Generator Provider
(Context)
Application-Specific
[1..*] uses
RoQME Model
QoS Engineer
Observation
[1..*] impacts realizes
Service
NFP Wish
(NFP)
[1..*] uses [0..1] uses
System Service
Arch Model
Service
System Architect Wish
Component Behavior
Components Task Plots
realizes Supplier Developer
Figure 3: The RoQME models and the role of QoS Engineers in the context of RobMoSys.
respectively) and connects them appropriately to obtain the enabling the later generation of their associated documenta-
final application. tion;
(8) The System Builder must also add the "QoS Metric Provider" • The Datatypes Package, which provides users with the foun-
Component, generated from the RoQME Model, which will dations of the modeling language, i.e., sentences, data types,
provide Global Robot QoS Metrics at runtime; appropriately typed variables and values;
connect this component to the required context providers • The Expressions Package, which provides users with the ca-
(either components, Knowledge Base, ...); and eventually pability of defining logical and arithmetical expressions; and
connect the resulting metrics to those components making • The Kernel Package, which specifies the main RoQME mod-
use of them (if any). eling concepts, such as, context variables, properties and
Finally, it is worth noting that the generated component will observations, among others.
provide information about (1) the metric computed for each non- Figure 4 shows an excerpt of the most relevant concepts included
functional property defined in the RoQME model; (2) a ranking of both in the RoQME meta-model (highlighted in green) and in the
observations depending on their influence on the metric values; RoQME-to-RobMoSys mapping meta-model (those highlighted in
and (3) when possible, information about the degree of confidence blue). The later define the mapping between the RoQME and the
associated to each metric, depending on the availability, reliability corresponding RobMoSys elements (highlighted in red).
and uncertainty [4] of the context sources. A RoQME model is mainly composed of Contexts, Properties
(derived from TypedVariables), and Observations (derived from Sen-
4 THE ROQME META-MODELS tences). Contexts represent the contextual information provided
As previously mentioned, RoQME defines two meta-models: (1) the by the sensors or by other components included in the robot archi-
RoQME meta-model, responsible for the definition of Non-Functional tecture (PrimitiveContext) or by a combination of these primitive
Properties, Contexts and Observations; and (2) the RoQME-to-RobMoSys context through a complex expression (DerivedContext). Lines 1–
mapping meta-model, responsible for binding each Context defined 3 in Figure 5 declare three primitive contexts, whereas Lines 4–7
in a RoQME model with the RobMoSys Service Definition acting as declare a derived context of type enum, obtained in terms of one of
the corresponding context provider. the previous primitive contexts.
The RoQME meta-model has been divided into four packages: A RoQME Property represents the degree of fulfillment of a
• The Documentation Package, which provides users with el- non-functional property. They are defined as a particular type of
ements to annotate the main RoQME modeling concepts, BeliefVariables (i.e., variables that store the output probability of
A Component-Based and Model-Driven Approach to Deal with Non-Functional Properties (...) C. Vicente-Chicote et al.
Figure 4: Excerpt of the RoQME Meta-Model (elements highlighted in green) and RoQME-to-RobMoSys Mapping Meta-Model
(elements highlighted in blue). The elements highlighted in red belong to the RobMoSys meta-model.
a belief network). The value of a property changes at runtime in re- 1 c o n t e x t t e m p e r a t u r e : number
sponse to different Actions, namely: SetVariable, ClearEvidence 2 c o n t e x t s t a t e : enum { TOO_HOT , FINE , TOO_COLD }
and SetEvidence actions. Lines 9–14 in Figure 5 show two example 3 context motionDetected : eventtype
properties: usability and effectiveness. Each one takes a belief value 4 c o n t e x t motion : enum { MOTIONLESS , MOVING }
in the range [0, 1]. However, the value of the later is transformed 5 : = c o u n t ( m o t i o n D e t e c t e d , 1 min ) > 5 ?
into an enumerated value (LOW, MEDIUM or HIGH ) according to 6 motion : : MOVING : motion : : MOTIONLESS
the OutputTransformation included its definition. 7
Finally, Observations specify relevant context patterns and how 8 property u s a b i l i t y
they influence (REINFORCE or UNDERMINE) and to what extent 9 p r o p e r t y e f f e c t i v e n e s s : enum {LOW, MEDIUM , HIGH } : =
(VERY_HIGH, HIGH, MEDIUM, etc.) in one or more Properties (see 10 b e l i e f > 0 . 7 ? HIGH :
Figure 5, lines 16–20). 11 b e l i e f > 0 . 3 ? MEDIUM :
The RoQME-to-RobMoSys mapping models include one Moni- 12 LOW
tor per Context defined in the RoQME model. Each of these context 13
is then bound to the corresponding RobMoSys CommServiceDef- 14 o b s e r v a t i o n obs1 :
inition, indicating which AttributeDefinition of its Communi- 15 motion = MOVING r e i n f o r c e s e f f e c t i v e n e s s
cationObject will provide the required contextual information. It is 16 o b s e r v a t i o n o b s 2 : t e m p e r a t u r e > 40 {
worth noting that RobMoSys AttributeDefinitions are not annotated 17 s e t s s t a t e = TOO_HOT ,
with information about the units or the precision of the information 18 undermines u s a b i l i t y }
they store. In order to cope with this, RoQME is considering the
approach proposed in [3].
Figure 5: RoQME syntax examples
5 CONCLUSIONS AND FUTURE WORK
The critical nature of this kind of software systems makes it nec-
Nowadays, component-based development is a commonly accepted essary to deal with different non-functional properties at runtime,
approach to design, build, manage and evolve robotics software. such as safety, performance or dependability, among others. The
ModComp’18. Copenhagen (Denmark), 2018 C. Vicente-Chicote et al.
RoQME ITP is contributing to the EU H2020 RobMoSys Project with [6] M. A. Gutiérrez, A. Romero-Garcés, and P. Bustos. 2013. Progress in RoboComp.
a model-driven tool-chain enabling the specification of system-level Journal of Physical Agents 7, 1 (2013), 39–48. https://doi.org/10.14198/JoPha.2013.
7.1.06
non-functional properties by so-called QoS Engineers. This new role [7] J. F. Inglés-Romero, J. M. Espín, R. Jiménez-Andreu, R. Font, and C. Vicente-
whithin RobMoSys is aimed at defining application-specific observa- Chicote. 2018. Towards the use of Quality-of-Service Metrics in Reinforcement
Learning: A robotics example. In Proc. 5th International Workshop on Model-driven
tions (evidences which reinforce or undermine the non-functional Robot Software Engineering (MORSE’18), in conjunction with MODELS 2018.
properties previously modeled as relevant for that application) in [8] J. F. Inglés-Romero, A. Lotz, C. Vicente-Chicote, and C. Schlegel. 2012. Dealing
terms of the contextual information available. The RoQME model with Run-Time Variability in Service Robotics: Towards a DSL for Non-Functional
Properties. In Proc. 3rd International Workshop on Domain-Specific Languages and
then guides a fully automated code generation process that results models for ROBotic systems (DSLRob-12). https://arxiv.org/pdf/1303.4296.pdf
in a QoS metrics provider component, which may be used by other [9] J. F. Inglés-Romero, A. Romero-Garcés, C. Vicente-Chicote, and J. Martínez. 2017.
RobMoSys-compliant components for different purposes, such as A Model-Driven Approach to Enable Adaptive QoS in DDS-Based Middleware.
IEEE Transactions on Emerging Topics in Computational Intelligence 1, 3 (June
robot behavior adaptation or benchmarking. 2017), 176–187. https://doi.org/10.1109/TETCI.2017.2669187
Currently, the RoQME team is working in the support software [10] J. F. Inglés-Romero and C. Vicente-Chicote. 2011. A Component-Based Architec-
ture Template for Adaptive System Design. In Proc. XVI Jornadas de Ingeniería
on which the generated QoS metrics provider will rely, i.e., the del Software y Bases de Datos (JISBD’11). SISTEDES.
software in charge of (1) monitoring the context; (2) identifying [11] J. F. Inglés-Romero and C. Vicente-Chicote. 2013. Towards a Formal Approach
relevant context patterns; and (3) estimating the value of each non- for Prototyping and Verifying Self-Adaptive Systems. In Advanced Information
Systems Engineering Workshops. CAiSE 2013, Soffer P. Franch X. (Ed.). Lecture
functional property in terms of the positive or negative influence Notes in Business Information Processing, Vol. 148. Springer, Berlin, Heidelberg,
of the identified context patterns, according to the observations 432–446. https://doi.org/10.1007/978-3-642-38490-5_39
included in the RoQME models. [12] J. F. Inglés-Romero, C. Vicente-Chicote, B. Morin, and O. Barais. 2010. Using
Models@Runtime for Designing Adaptive Robotics Software: an Experience
Future work will focus on validating the RoQME tool-chain with Report. In Proc. 1st International Workshop on Model-Based Engineering for Robotics
real world complex scenarios involving industrial and social assis- (RoSym’10), in conjunction with MODELS 2010.
[13] J. F. Inglés-Romero, C. Vicente-Chicote, B. Morin, and O. Barais. 2011. Towards the
tive robots. The definition of pertinent non-functional properties Automatic Generation of Self-Adaptive Robotics Software: An Experience Report.
for these different areas of application in robotics will help us refine In 2011 IEEE 20th International Workshops on Enabling Technologies: Infrastructure
the expressiveness of the RoQME modeling language, along with for Collaborative Enterprises. 79–86. https://doi.org/10.1109/WETICE.2011.54
[14] J. F. Inglés-Romero, C. Vicente-Chicote, J. Troya, and A. Vallecillo. 2012. Prototyp-
the robustness of the QoS metrics provider and the accuracy of the ing component-based self-adaptive systems with Maude. In Proc. XVII Jornadas
non-functional properties estimations. de Ingeniería del Software y Bases de Datos (JISBD’12). SISTEDES.
All the RoQME partners are pledged to making the knowledge [15] A. Lotz, J. F. Inglés-Romero, D. Stampfer, M. Lutz, C. Vicente-Chicote, and C.
Schlegel. 2014. Towards a Stepwise Variability Management Process for Complex
generated in the course of the Project as widely and freely avail- Systems: A Robotics Perspective. International Journal of Information System
able as possible for subsequent research and development. For this Modeling and Design 5, 3 (2014). https://doi.org/10.4018/ijismd.2014070103
[16] A. Lotz, J. F. Inglés-Romero, C. Vicente-Chicote, and C. Schlegel. 2013. Man-
reason, the Project partners are fully committed to open-access aging Run-Time Variability in Robotics Software by Modeling Functional and
and open-source. Actually, all the Project results will be punc- Non-functional Behavior. In Enterprise, Business-Process and Information Systems
tually announced through the Project social networks (Twitter: Modeling, Nurcan S. et al. (Ed.). Lecture Notes in Business Information Process-
ing, Vol. 147. Springer, Berlin, Heidelberg, 441–455. https://doi.org/10.1007/
@RoQME_ITP, LinkedIn: RoQME Group, or ResearchGate: RoQME 978-3-642-38484-4_31
Project), and made publicly available through the dedicated project [17] M. Lutz, J. F. Inglés-Romero, D. Stampfer, A. Lotz, C. Vicente-Chicote, and C.
web page [21], allocated within the RobMoSys website [20]. Schlegel. In press. Managing Variability as a Means to Promote Composability:
A Robotics Perspective. In New Perspectives on Information Systems Modeling and
Design, A. M. Rosado da Cruz and M. E. Ferreira da Cruz (Eds.). IGI-Global.
ACKNOWLEDGMENTS [18] J. Martínez, A. Romero-Garcés, J. P. Bandera, and A. Bandera. 2011. Nerve: a
lightweight middleware for quality-of-service networked robotics. In Proc. 8th
The RoQME Integrated Technical Project has received funding from International Conference on Information Technology: New Generations (ITNG).
the European Union’s H2020 Research and Innovation Programme 655–660. https://doi.org/10.1109/ITNG.2011.116
[19] J. Martínez, A. Romero-Garcés, J. P. Bandera, R. Marfil, and A. Bandera. 2012. A
under grant agreement No. 732410, in the form of financial support DDS-based middleware for quality-of-service and high-performance networked
to third parties of the RobMoSys Project. robotics. Concurrency and Computation: Practice and Experience 24, 16 (2012),
1940–1952. https://doi.org/10.1002/cpe.2816
[20] RobMoSys EU H2020 Project. (2017-2020). RobMoSys: Composable Models and
REFERENCES Software for Robtics Systems - Towards an EU Digital Industrial Platform for
[1] D. Alonso, J. A. Pastor, P. Sánchez, B. Álvarez, and C. Vicente-Chicote. 2012. Robotics. Retrieved July 2, 2018 from http://robmosys.eu
Automatic Code Generation for Real–Time Systems: a Development Approach [21] RoQME Integrated Technical Project. (2018-2019). RoQME: Dealing with non-
based on Components, Models, and Frameworks. Revista Iberoamericana de functional properties through global Robot Quality-of- Service Metrics. Retrieved
Automática e Informática Industrial (RIAI) 9, 2 (2012), 170–181. https://doi.org/ July 2, 2018 from http://robmosys.eu/roqme/
10.1016/j.riai.2012.02.010 [22] A. Romero-Garcés, J. F. Inglés-Romero, J. Martínez, and C. Vicente-Chicote. 2013.
[2] D. Alonso, C. Vicente-Chicote, F. Ortiz, J. A. Pastor, and B. Álvarez. 2010. V3CMM: Self-adaptive quality-of-service in distributed middleware for robotics. In Proc.
a 3-View Component Meta-Model for Model-Driven Robotic Software. Journal 2nd International Workshop on Recognition and Action for Scene Understanding
of Software Engineering for Robotics 1, 1 (2010), 3–17. http://joser.unibg.it/index. (REACTS 2013).
php/joser/article/view/18 [23] A. Romero-Garcés, L. Manso, M. A. Gutiérrez, R. Cintas, and P. Bustos. 2011.
[3] L. Burgueño, T. Mayerhofer, M. Wimmer, and A. Vallecillo. 2018. Using Physical Improving the life cycle of robotics components using Domain Specific Languages.
Quantities in Robot Software Models. In Proc. 1st ACM/IEEE International Work- In Proc. 2nd International Workshop on Domain-Specific Languages and models for
shop on Robotics Software Engineering. 23–28. https://doi.org/10.1145/3196558. ROBotic systems (DSLRob’11). https://arxiv.org/pdf/1301.6022.pdf
3196562 [24] C. Schlegel, A. Lotz, M. Lutz, D. Stampfer, J. F. Inglés-Romero, and C. Vicente-
[4] J. Cámara, W. Peng, D. Garlan, and B. Schmerl. 2018. Reasoning about sensing Chicote. 2015. Model-driven software systems engineering in robotics: Covering
uncertainty and its reduction in decision-making for self-adaptation. Science of the complete life-cycle of a robot. it - Information Technology 57, 2 (March 2015).
Computer Programming 167 (2018), 51–69. https://doi.org/10.1016/j.scico.2018. https://doi.org/10.1515/itit-2014-1069
07.002 [25] S. Sentilles. 2012. Managing extra-functional properties in component-based devel-
[5] C. Vicente-Chicote et al. 2018. RoQME: Dealing with Non-Functional Properties opment of embedded systems. Ph.D. Dissertation. Mälardalen University. ISBN:
through Global Robot QoS Metrics. In Proc. XXIII Jornadas de Ingeniería del 978-91-7485-067-3.
Software y Bases de Datos (JISBD’18). SISTEDES.