IEEE Robotics & Automation Magazine - September 2015 - 162

an existing software library. The components interconnections are specified at design-time in the PIM, but can be
modified at runtime to
adapt the robot behavior
to the actual operational
Autonomous robots are versatile
conditions. For example,
machines equipped with a rich
the ObstacleAvoider task
requires sensory informaset of software functionalities.
tion (e.g., a point cloud)
to detect obstacles. At
run-time different sensors can provide the point cloud based
on environment illumination (e.g., a laser scanner or a stereo
vision system).
The SmartSoft MDE includes the task coordination language (SmartTCL) for specifying the high-level application
tasks (e.g., fetch coffee to visitors) that the robot is able to carry
out and how these tasks are refined during task execution in
terms of services provided by individual components (e.g.,
navigate towards the coffee machine). The SmartSoft framework provides the SmartTCL engine that is in charge of
orchestrating the control system by activating, deactivating,
and interconnecting components according to the action plan.
Proteus
The Proteus [36] project (platform for RObotic Modeling and
Transformation for End-Users and Scientific communities) is
an initiative of the French robotic community (GDR Robotique) that has developed a MDE toolkit for robotic system
design and implementation. The distinctive feature of the
Proteus Toolkit is the use of a set of ontologies [37] for representing knowledge about robotic systems, operational environments, and applications. The Proteus ontologies are an
attempt to formalize the vocabulary of robotic system engineers, to allow them to model robot control architectures
directly in terms of domain concepts (e.g., sensor, motion

%Stereotype&
SensorSystem
+ frequency: Float32 [1]
+ identifier: String [1]

%Stereotype&
ImageSensorSystem

%Stereotype&
ObjectTrackingSensorSystem

%Stereotype&
CameraSystem

%Stereotype&
LidarSystem
+ angle_min: Float32 [1]
+ angle_max: Float32 [1]
+ scan_time: Float32 [1]
+ range_min: Float32 [1]
+ range_max: Float32 [1]

+ width: UInt32 [1]
+ height: UInt32 [1]
+ color_format: String [1]
+ translate: Point32 [1]
+ rotate: Point32 [1]

Figure 4. The RobotML profile for robot sensors.

162

IEEE ROBOTICS & AUTOMATION MAGAZINE

September 2015

planner, rover, and so on) and not only in terms of software
concepts (e.g., component, port, algorithm, and so on). Similar initiatives are sponsored by the IEEE Standard Association, which has established the Ontologies for Robotics and
Automation working group.
The Proteus ontologies are the basis of the Proteus DSL
(RobotML) [38], which includes modeling entities for specific architectural elements (e.g., Robot, SensorSystem,
ActuatorSystem, LocalizationSystem) and architectural
styles (e.g., reactive, deliberative, hybrid). Similar to SmartSoft (see the "SmartSoft" section), the Proteus toolchain is
based on an UML profile for defining the PIM of the robot
functional architecture. As an example, Figure 4 shows an
excerpt of the RobotML profile for robot sensors, where the
modeling entities CameraSystem and LidarSystem are
defined as stereotypes that can be used to annotate the components of the robot control architecture. For code generation, the elements of the PIM model need to be allocated to
an execution platform, such as a middleware and a simulator.
For example, the element representing robot functionality
and control activities are allocated to a component-based
middleware, while the element representing the robotic
equipment is allocated to a simulator.
Modeling the Components Behavior
Code generation from behavior models is a growing area of
interest due to its benefits of verifying models by simulation
and reducing error-prone hand-coding efforts. Several tools
generate source code form the UML specifications to mainstream languages such as C, C+, and Java and to simulation
languages such as SystemC. Typically, the MDE environments
supporting component-based architectural modeling (see the
"System Architecture Modeling and Analysis" section) also
provide languages for modeling the discrete behavior of individual components, such as UML state charts and petri nets.
When developing embedded control software, control systems engineers model both the control algorithm and the system to be controlled, the so-called plant, together to ensure the
optimal performance of processes with continuous dynamics.
[39]. Typically, the robot control functionalities are conveniently modeled as hybrid systems, since they can specify continuous change of the system state as well as discrete transition
of states. Continuous behavior can be specified using differential as well as algebraic equations. Code generation from
hybrid-systems models eventually involves simulating continuous change of a variable by step-wise update of the variable
based on numerical methods. This requires the model designer to assign a rate by which the continuous state evolves.
Several modeling and simulation environments for embedded systems (e.g., MATLAB/Simulink [40] and 20-sim [41])
support code generation from continuous and hybrid models,
defined with DSLs, such as Bond Graphs, Block Diagrams,
and Modelica. These tools allow users to define custom templates for code generation to simplify the integration of behavioral code with component frameworks. Brodskiy et al. [42]
exemplify the modeling, code generation, and integration

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