Non-functional properties play a key role in most software systems. There is a lot of literature on what non-functional properties are but, unfortunately, there is also a lot of disagreement and diferent points of view on how to deal with them. Non-functional properties, such as safety or dependability, become particularly relevant in the context of robotics. In the EU H2020 RobMoSys Project, nonfunctional properties are treated as first-class citizens and considered key added-value services. In this vein, the RoQME Integrated Technical Project, funded by RobMoSys, aims at contributing a component-based and model-driven tool-chain for dealing with system-level non-functional properties, enabling the specification of global Quality of Service (QoS) metrics. The estimation of these metrics at runtime, in terms of the contextual information available, can then be used for diferent purposes, such as robot behavior adaptation or benchmarking.
Component-Based Software Development (CBSD) aims at
promoting software reuse for signicfiantly reducing development time and
cost. Existing solutions are encapsulated in well-defined
components with clear (required and provided) interfaces that enable their
connection to and interoperation with other components. Building
systems out of components requires taking into account both
functional and non-functional properties. Non-functional properties
define how a system performs rather than what it does [
RobMoSys: Composable Models and Software for Robotics [
The main intended goal of RoQME is to provide robotics software engineers with a model-driven tool-chain allowing them to: (1) model relevant system-level non-functional properties in terms of the (internal and external) contextual information available at runtime; and (2) generate a RobMoSys-compliant component, ready to provide other components with QoS metrics defined on the nonfunctional properties, previously specified.
This paper describes the RoQME foundations, laid down during the initial stage of the project, namely: (1) the new role of QoS Engineers and how it integrates with the other roles considered in RobMoSys; (2) the RoQME and the RoQME-to-RobMoSys Mapping meta-models, which gather the main modeling concepts and their relation to those included in the RobMoSys meta-models; and the process (including the relevant roles, models and tools) we propose to enable the modeling (at design-time) and estimation (at runtime) of metrics defined on system-level non-functional properties.
RoQME will run for one year, starting March 2018. Achieving
substantial results in such a short period of time requires building on
previous results. In this vein, the RoQME partners contribute solid
background in Robotics, Component-Based Software Development,
and Model-Driven Engineering [
The rest of the paper is organized as follows. Firstly, Section 2 presents an overview of the RoQME project, introducing its main intended goals and contributions. Secondly, Section 3 introduces the RobMoSys project and outlines how RoQME plans to integrate into its Ecosystem, focusing on the description of the new QoS Engineer role. Then, Section 4 introduces the main modeling concepts gathered in the RoQME meta-models and illustrates them through some practical examples. And, finally, Section 5 draws some conclusions and outlines current and future works. 2
RoQME intends to support the role of QoS Engineers (see Section 3.2), providing them with a specific QoS View that allows them to model system-level non-functional properties according to the RoQME meta-model (see Section 4). This new role, view and metamodel complement and interrelate with those already defined in RobMoSys through the so called RoQME-to-RobMoSys mapping meta-model. This mapping aims at promoting good design principles, such as high cohesion and loose coupling among the diferent RobMoSys views, providing a non-intrusive way of extending the RobMoSys meta-model, i.e., modifying the RoQME meta-model would only imply adapting the mapping but not the RobMoSys meta-model and, vice versa, new versions of the RobMoSys metamodel would imply adapting the mapping, but not the RoQME meta-model.
RoQME will allow QoS Engineers to model context variables
(e.g., battery level) and, from them, relevant context patterns (e.g.,
“the battery level drops more than 1% per minute”). The detection
of a context pattern will be considered an observation associated
with a variable in a belief network. Belief networks will be used
to specify the dynamics of non-functional properties (e.g., power
consumption). The degree of fulfillment of these non-functional
properties will then be used to estimate the QoS metrics, obtained
as real values in the range [
RoQME aims to be application domain agnostic, providing QoS Engineers with a compact set of modeling tools to express systemlevel QoS metrics. However, it is being designed to be as flexible as possible, e.g., supporting extension mechanisms that allow QoS Engineers (or other RobMoSys roles, such as Safety Engineers or Performance Designers) to enrich and customize the RoQME modeling capabilities with domain-specific requirements (e.g., related to safety, dependability, etc.).
The RoQME tool-chain, delivered as an Eclipse plug-in, will
provide both modeling and code generation tools, enabling the creation
of RobMoSys-compliant components, readily usable in
RobMoSysbased solutions as QoS information providers (see Figure 1). This
information could then be used by other components for diferent
purposes, e.g., robot behavior adaptation or benchmarking. In this
line, a preliminary result on how to use the RoQME metrics as an
input in a reinforcement learning problem can be found in [
Internally, the generated component will estimate the value of each non-functional property, specified in the RoQME model, by successively processing the available contextual information, either from internal (e.g., robot sensors) or external (e.g., web services, other robots, etc.) sources. The contextual information received by the component will be sequentially processed by three modules:
RoQME Model • Non-functional properties • Context variables • Observations based on context patterns and rules Mapping model RobMoSys Structures (models) T 2 M
Global QoS Metrics Provider
Abstract non-functional properties
Estimations Probabilistic Reasoning
Observations Event processing
Events Context monitoring
E.g., the robot task sequencer may use the resulting QoS metrics for deciding among alternative tasks, activating or deactivating certain components, or Communication setting component
Objects params within their
Context information allowed range (1) a context monitor that will receive raw contextual data and will produce context events (e.g., changes in the battery level); (2) an event processor that will search for the event patterns specified in the RoQME model and, when found, will produce observations (e.g., battery is draining too fast); and, finally (3) a probabilistic reasoner that will compute a numeric estimation for each metric (i.e., the degree of fulfillment of each non-functional property).
RoQME focuses on the modeling (at design-time), management and measurement (at runtime) of non-functional properties. To achieve it, RoQME extends the core structures, roles and views, laid down by RobMoSys, by defining the RoQME meta-models (later introduced in Section 3.2 and a new QoS Engineer role, which is provided with a new modeling view for describing the non-functional aspects of robotic applications.
Before detailing the activities carried out and the models developed by the QoS Engineers, let us briefly review the main RobMoSys principles, structures and roles, as they define the QoS Engineers working context.
RobMoSys proposes an Ecosystem organized into three tiers, arranged along levels of abstraction (see Figure 2). Tier 1, shaped by few representative Robotics Experts, defines the overall composition structures to which the lower tiers must conform. Tier 2, structures particular robotics sub-domains, such as SLAM, manipulation, object recognition, etc. Tier 2 is shaped by Domain Experts and conforms to the foundations laid down in Tier 1. Finally, Tier 3, conforms to the domain-structures defined in Tier 2, and provides reusable building block (developed by Component Suppliers and Behavior Developers), readily available to be integrated (by System Builders) into diferent robotic systems.
RobMoSys considers a large number of loosely interconnected participants that depend on each other for their mutual efectiveness and individual success. RobMoSys is about managing the interfaces between diferent roles (Domain Experts, System Architects, Component Suppliers, Behavior Developers, System Builders, etc.) and separate concerns in an eficient and systematic way.
According to the information available in the RobMoSys Wiki1, System Architects define the functional requirements of robotic 1https://robmosys.eu/wiki applications in terms of Service Wishes (e.g., navigation, location, handover, etc.) and create Service Links among them when needed. Service Links (specified as uses relationships) identify componentindependent inter-service dependencies (i.e., if a Service Wish A depends on the existence of another Service B, then a relationship "A uses B" needs to be modeled). Each Service Wish, defined by the System Architect in Tier 3, is an instancesOf a Service Definition , previously modeled by a Domain Expert in Tier 2. Service definitions are reusable artifacts (at least within a robotics sub-domain) that can be instantiated as many times and in as many applications as needed.
In order to realize the Service Wishes defined by the System Architect, the System Builder selects applicable components and behaviors (task plots) from the RobMoSys Ecosystem (developed by Component Suppliers and Behavior Developers, respectively) and connects them appropriately to obtain the final application.
This (very briefly) summarizes the typical workflow that needs to be followed to come up with a robotics application according to the RobMoSys structures and guidelines (see Figure 3). The following section introduces the new role of the QoS Engineers, contributed by RoQME, and details how they interact with the other roles within the RobMoSys Ecosystem. 3.2
Both functional and non-functional requirements should respond to customer or business needs, either directly or indirectly. In this sense, RoQME provides the means to support: (1) the evaluation of non-functional requirements, e.g. to check statements such as "the robot should perform at least GOOD with respect to PERFORMANCE"; (2) benchmarking, e.g. to test the impact of diferent robot realizations on SAFETY ; and (3) self-adaptation, e.g., the robot could select, at runtime, its navigation strategy so that PERFORMANCE is maximized. Therefore, non-functional properties and the metrics defined to quantify them, ofer many possibilities, from assessing requirements fulfillment to dynamic adaptation of the robot behavior.
Figure 3 shows an overview of the RoQME and RobMoSys roles, models and relationships. In the following, we describe the process by presenting the actions of the roles involved in relation to RoQME. (1) Domain Experts could define relevant domain-specific nonfunctional 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 automatically generated: • A Service Definition, in order to make the metrics calculated on the diferent non-functional properties available to other components as a service. • A Service Wish (as an instance of the previous Service Definition). 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 adaptation purposes) from some of the Service Wishes previously included in the System Service Architecture Model. Note that the generated Service Wish will be realized by the “QoS Metric Provider” Component, also generated by the RoQME generation engine (in a later step). Thus, this component will be available to the System Builder in order to fulfill the corresponding Service Wish. (4) QoS Engineers select relevant Contexts by searching among the Service Definitions available in the Ecosystem (i.e., context providers). For each of these contexts: • A new element will be created in the RoQME-to-RobMoSys (R2R) Mapping Model with a reference both to the Context and to the corresponding Service Definition. The R2R Mapping Model conforms to the R2R Mapping Meta-Model, which provides a loose coupling mechanism between the RoQME and the RobMoSys modeling concepts (i.e., in case any of the two meta-models is modified or evolves, the other will remain unaltered; only the mapping meta-model will need to be modified accordingly). • A Service Wish will be automatically generated and added to the RoQME Model as an instance of the corresponding Service Definition. This Service Wish will need to be later realized by the System Builder by selecting the appropriate Component/Task Plot (context provider) from the RobMoSys Ecosystem. (5) QoS Engineers define application-specific Observations in terms of one or more of the previous Contexts. An Observation is an evidence reinforcing (or undermining) the belief that the system is optimal in terms of one or more of the non-functional properties previously defined. (6) The QoS Engineer generates the "QoS Metric Provider" Component from the resulting RoQME Model and makes it available to the System Builder. (7) In order to realize the Service Wishes included both in the System Service Architecture Model (developed by the System Architect) and in the RoQME Model (developed by the QoS Engineer), the System Builder selects applicable components and behaviors (task plots) from the RobMoSys Ecosystem (provided by Component Suppliers and Behavior Developers,
Domain Expert
Domain-Specific RoQME model respectively) and connects them appropriately to obtain the ifnal application. (8) The System Builder must also add the "QoS Metric Provider" Component, generated from the RoQME Model, which will provide Global Robot QoS Metrics at runtime; appropriately connect this component to the required context providers (either components, Knowledge Base, ...); and eventually connect the resulting metrics to those components making use of them (if any).
Finally, it is worth noting that the generated component will
provide information about (1) the metric computed for each
nonfunctional property defined in the RoQME model; (2) a ranking of
observations depending on their influence on the metric values;
and (3) when possible, information about the degree of confidence
associated to each metric, depending on the availability, reliability
and uncertainty [
As previously mentioned, RoQME defines two meta-models: (1) the RoQME meta-model, responsible for the definition of Non-Functional Properties, Contexts and Observations; and (2) the RoQME-to-RobMoSys mapping meta-model, responsible for binding each Context defined in a RoQME model with the RobMoSys Service Definition acting as the corresponding context provider.
The RoQME meta-model has been divided into four packages: • The Documentation Package, which provides users with elements to annotate the main RoQME modeling concepts, enabling the later generation of their associated documentation; • The Datatypes Package, which provides users with the foundations of the modeling language, i.e., sentences, data types, typed variables and values; • The Expressions Package, which provides users with the ca
pability of defining logical and arithmetical expressions; and • The Kernel Package, which specifies the main RoQME modeling concepts, such as, context variables, properties and observations, among others.
Figure 4 shows an excerpt of the most relevant concepts included both in the RoQME meta-model (highlighted in green) and in the RoQME-to-RobMoSys mapping meta-model (those highlighted in blue). The later define the mapping between the RoQME and the corresponding RobMoSys elements (highlighted in red).
A RoQME model is mainly composed of Contexts, Properties (derived from TypedVariables), and Observations (derived from Sentences). Contexts represent the contextual information provided by the sensors or by other components included in the robot architecture (PrimitiveContext) or by a combination of these primitive context through a complex expression (DerivedContext). Lines 1– 3 in Figure 5 declare three primitive contexts, whereas Lines 4–7 declare a derived context of type enum, obtained in terms of one of the previous primitive contexts.
A RoQME Property represents the degree of fulfillment of a
non-functional property. They are defined as a particular type of
Belief Variables (i.e., variables that store the output probability of
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 diferent 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 c o n t e x t m o t i o n D e t e c t e d : e v e n t t y p e
properties: usability and efectiveness . Each one takes a belief value 4 c o n t e x t motion : enum { MOTIONLESS , MOVING }
in the range [
Finally, Observations specify relevant context patterns and how 8 they influence ( REINFORCE or UNDERMINE) and to what extent 9 (VERY_HIGH, HIGH, MEDIUM, etc.) in one or more Properties (see 10 Figure 5, lines 16–20). 11
The RoQME-to-RobMoSys mapping models include one Moni- 12
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 o b s 1 :
inition, indicating which AtributeDefinition 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 [
Nowadays, component-based development is a commonly accepted approach to design, build, manage and evolve robotics software. The critical nature of this kind of software systems makes it necessary to deal with diferent non-functional properties at runtime, such as safety, performance or dependability, among others. The RoQME ITP is contributing to the EU H2020 RobMoSys Project with a model-driven tool-chain enabling the specification of system-level non-functional properties by so-called QoS Engineers. This new role whithin RobMoSys is aimed at defining application-specific observations (evidences which reinforce or undermine the non-functional properties previously modeled as relevant for that application) in terms of the contextual information available. The RoQME model then guides a fully automated code generation process that results in a QoS metrics provider component, which may be used by other RobMoSys-compliant components for diferent purposes, such as robot behavior adaptation or benchmarking.
Currently, the RoQME team is working in the support software on which the generated QoS metrics provider will rely, i.e., the software in charge of (1) monitoring the context; (2) identifying relevant context patterns; and (3) estimating the value of each nonfunctional property in terms of the positive or negative influence of the identified context patterns, according to the observations included in the RoQME models.
Future work will focus on validating the RoQME tool-chain with real world complex scenarios involving industrial and social assistive robots. The definition of pertinent non-functional properties for these diferent areas of application in robotics will help us refine the expressiveness of the RoQME modeling language, along with the robustness of the QoS metrics provider and the accuracy of the non-functional properties estimations.
All the RoQME partners are pledged to making the knowledge
generated in the course of the Project as widely and freely
available as possible for subsequent research and development. For this
reason, the Project partners are fully committed to open-access
and open-source. Actually, all the Project results will be
punctually announced through the Project social networks (Twitter:
@RoQME_ITP, LinkedIn: RoQME Group, or ResearchGate: RoQME
Project), and made publicly available through the dedicated project
web page [
The RoQME Integrated Technical Project has received funding from the European Union’s H2020 Research and Innovation Programme under grant agreement No. 732410, in the form of financial support to third parties of the RobMoSys Project.