IEEE Robotics & Automation Magazine - September 2015 - 158

view and serve as a vessel for communication between the varied worlds of often nonsoftware-technical stakeholders on one
hand and software engineers on the other hand. Such a documentation promotes software reuse by exhibiting
Other approaches are based
stable structures recurrent
in many systems and facilon robotics-specific languages.
itates maintenance by clarifying the impact of
changes [13]. A large variety of UML-compliant software tools
support diagram editing, differencing, merging for system design, and documentation (see [14] for a survey).
Unfortunately, the UML diagrams are not effective in
capturing and representing nonfunctional properties of
embedded, concurrent, and real-time software systems,
such as the timing constraints of system functionalities, the
capabilities of the (often distributed) communication infrastructure, and the allocation of threads and processes to different processors.
Researchers have faced the limitations of the semiformal
notation of the UML by defining specific extensions of the
UML standard (called profiles) or specialized architectural
modeling languages. These approaches are exemplified in
the next two sections. A comparison of several modeling
languages for embedded and real-time systems can be
found in [15].

UML profile for Embedded and Real-Time Systems
The UML profiles are an extension mechanism provided to
allow adaptation and customization of the UML notation by
adding ad hoc semantic and constraints and introducing terminology that is specific to a particular domain, platform, or method. In particular, the OMG has developed the modeling and
analysis of real-time embedded systems (MARTE) [16] profile,
which focuses on performance and schedulability analysis and
provides stereotypes for annotating architectural models and
map them into corresponding analysis domain concepts.
The high-level application modeling subprofile defines a
set of stereotypes to annotate the functional model with
real-time features. For example, Figure 2 shows a use of the
<> stereotype to annotate two computing units
(i.e., ObstacleAvoider and TrajectoryFollower) of the LocalNavigator component, which perform concurrent activities,
i.e., adapting the rover trajectory when an obstacle is
detected and computing the twist to let the rover follow the
trajectory. An annotation specifies that the former activity is
aperiodic and that its relative deadline is equal to 10 ms.
The software resource modeling subprofile provides modeling artifacts to describe software multitasking application
programming interfaces (API). For example, Figure 2 shows a
use of the <> stereotype to annotate
two concurrent tasks (i.e., FollowerTask and ObstacleTask)
with the specification of their priority. The stereotype <> indicates the routine (i.e., operation) executed in the context of each task.
The schedulability analysis modeling
subprofile defines the stereotypes to anno%component& LocalNavogator
tate the elements of the platform model (e.g.,
a CPU or other device, which executes funcocckind
=
aperiodic
%rtUnit&
value = { reIDI = (10, ms) }
tional steps) with nonfunctional properties,
ObstacleAvoider
such as schedulability metrics, interrupt
adaptTrajectory ()
overheads, and utilization of scheduling
processing. In particular, in Figure 2, the ste%rtUnit&
reotype <> represents
TrajectoryFollower
any kind of processing resource (e.g., POSIX
computeTwist()
threads) and contains a property ISRswitchTime that can be used to represent the worst
%entryPoint&
%entryPoint&
context switching time.
Once the application model has been
%gaResourcePlatform&
annotated with MARTE stereotypes for realRoverPlatform
time features, it needs to be converted in a
software model that can be processed by tools
%schedulableResourse&
%schedulableResourse&
for schedulability and performance analysis.
ObstacleTask
FollowerTask
In [17], the author proposes an automatic
{
fp
(priority
=
5)
}
{ fp (priority = 6) }
translation technique from MARTE models
into input for modeling and analysis suite for
%allocate&
%allocate&
real-time applications, which is a state-of-theart schedulability analysis tool used in the
%saExecHost&
academia. A list of tools related to MARTE
Controller
{ ISRswitchTime (5, ms) }
can be found in [18].
A robotic example of using the MARTE
for schedulability and performance analysis
can be found in [19].
Figure 2. An example of using the MARTE stereotypes for schedulability analysis.

158

*

IEEE ROBOTICS & AUTOMATION MAGAZINE

*

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