IEEE Robotics & Automation Magazine - September 2015 - 163

process for the motion control system of the KUKA youBot
mobile manipulator [43]. The algorithm design requires a
model of the system that will be controlled. They used the 20sim toolchain to model the youBot kinematic chain as a bond
graph and the BRIDE model-based toolchain [44] to model
the component-based control system. The control algorithm
design is performed in parallel with the design of the component architecture. These two design phases have mutual dependence and require an iterative approach.
The algorithm is partitioned in blocks of elemental functionalities with well-defined interfaces, in such a way that they
can be modified independently (e.g., for improving their performance) without affecting the design and implementation
of the rest of the system. On the other side, message passing
between components can introduce message losses and time
delays in updates and communication between sensors, controller, and actuators that need to be explicitly represented in
the model of the control algorithm. Unreasonable communication requirements (such as extreme bandwidth or
unachievable small latency) can lead to restructuring the
component architecture. In [45], a criterion for faithful implementation of hybrid-systems models in a concurrent and distributed system is presented.
System Configuration
Current practice in software engineering for robotics consists
of developing fine-grain software components, which implement single robotic functionalities. This approach is embodied by a repeated mantra among ROS developers [9]: "We
don't wrap your main." The strength of this approach is the
possibility to develop a large variety of different control systems by composing in multiple ways reusable software building blocks. Its weakness is the lack of support to the reuse of
effective solutions to recurrent architectural design problems.
Consequently, application developers and system integrators
have to solve architectural design problems always from
scratch. The difficult challenge consists of selecting, integrating, and configuring a coherent set of components that provide the required functionality considering their mutual
dependencies and architectural mismatches.
This challenge is exacerbated by the peculiarity of the
robotics domain: 1) robots can have many purposes, 2) many
forms, and 3) many functions. Consequently, each robotic systems has to be configured with a specific mix of functionalities
and that strongly depends on the robot mechanical structure
(a rover with zero or multiple arms), the task to be performed
(cleaning a floor, rescuing people after a disaster), and the
environmental conditions (indoor, outdoor, underground). In
various application domains, the software product line (SPL)
development has proved to be the most effective approach to
face this kind of challenges. A SPL is a family of applications
(products) that share many (structural, behavioral, and so on)
commonalities and together address a particular domain [46].
Typically, the SPL is a strategic investment for an engineering
company that wants to achieve customer value through large
commercial diversity of its products (e.g., different control sys-

tems for warehouse logistics) with a minimum of technical
diversity at minimal cost.
The core of an SPL is a stable software architecture that
clearly separates common features from the variations
reflected in the products
and prescribes how softThe cost of creating new robotics
ware components can be
assembled to derive indiproducts is significantly related
vidual products. Each
to the complexity of developing
new application is built
by configuring the SPL,
software control systems.
i.e., by selecting the variants (e.g., functionalities,
software resources) that meet specific application requirements. The MDE environments simplify system configuration by providing domain-specific languages to model robot
variability and model-to-model transformations to resolve
the variability in the software control system. The following sections illustrate two MDE approaches for robotic systems configuration. The former focuses on modeling
variability in robot functionality, the latter on modeling variability in robot resources.
Software Product Lines for Robotics
The HyperFlex [47] toolchain is a MDE environment for the
development and configuration of SPL for Robotics. It provides domain-specific languages and graphical editors for the
definition of three types of models. The template architectural
model represents the software architecture (as discussed in
the "System Architecture Modeling and Analysis" section) of
a family of similar software systems. As such, it explicitly represents all the possible components (variants) that implement
a given functionality (variation point). For example, the
obstacle avoidance functionality might be provided by two
alternative components implementing the Vector Histogram
approach or the Dynamic Window approach. The Feature
Model [48] symbolically represents the variant features of a
control system; symbols may indicate individual robot functionality (e.g., marker-based localization) or concepts that are
relevant in the application domain, such as the type of items
that the robot has to transport (e.g., liquid, fragile, and so on),
which affect the configuration of the control system.
The Resolution Model defines model-to-model transformations, which allow users to automatically configure the
architecture and functionality of a control system based on
required features. In this context, architecture configuration
means to resolve the functional variability of a system by
selecting one variant for each variation point. A model-totext transformation generates the configuration file (launch
file) corresponding to the architecture of the configured control system. Currently, the HypeFlex supports the configuration of component-based systems based on the ROS
framework. Let us consider an example of SPL related to the
simple system shown in Figure 1. The LocalNavigator compound component encapsulates the TrajectoryFollower component (see Figure 2), which implements the algorithm for
September 2015

IEEE ROBOTICS & AUTOMATION MAGAZINE

163

Table of Contents for the Digital Edition of IEEE Robotics & Automation Magazine - September 2015