Synthesis of Real-Time Implementation from UML-RT Models
Z. Gu and K. G. Shin
Real-Time Computing Laboratory
Department of Electrical Engineering and Computer Science
University of Michigan
Ann Arbor, MI 48109-2122, USA
[email protected]
Abstract
ROOM (Real-Time Object-Oriented Modeling) is an ar-
chitecture description language widely used in the telecom-
munications industry to develop embedded software. The
concepts of ROOM have been incorporated into the CASE
tool Rational Rose Real-Time (RoseRT) in the form of a
UML profile, commonly called UML-RT. However, UML-
RT itself does not provide any support for performing real-
time scheduling analysis and generating an implementation
that meets timing constraints. It is the job of the engineer Figure 1. The basic model of computation for
to map the software functional model to RTOS threads and UML-RT.
choose a scheduling discipline to satisfy timing constraints.
In this paper, we summarize existing approaches for imple-
mentation synthesis of UML-RT models, and describe real- Instead, concurrent state machines are modeled as sep-
time schedulability analysis technique for the native imple- arate capsules communicating with buffered asyn-
mentation model of the RoseRT CASE tool. chronous message passing. A capsule may contain
other capsules to form a structural hierarchy.
• Explicit representation of ports, protocols and connec-
1. Introduction tors enables construction of architectural models from
a collection of capsules.
ROOM (Real-Time Object-Oriented Modeling) [10] is
an architecture description language widely used in the • A runtime framework called TargetRTS (Target Run-
telecommunications industry to develop embedded soft- time System) that serves as a virtual machine support-
ware. The concepts of ROOM have been incorporated into ing the model of computation defined by the UML-RT
the CASE tool Rational Rose Real-Time (RoseRT) in the modeling language. It runs on top of a RTOS to hide
form of a UML profile, commonly called UML-RT. As the vendor-specific details of execution platform and
shown in Figure 1, UML-RT has the following key con- present a uniform set of APIs to the engineer.
cepts: The runtime model of UML-RT follows the Run-To-
• A capsule is an active object with its own logi- Completion (RTC) semantics for each capsule. Once trig-
cal thread of control, typically representing an active gered by a message at its input port, the capsule must ex-
unit of computation.. A capsule typically has a be- ecute the triggered action to completion before processing
havior description in the form of an object-oriented the next message. Messages can be assigned priorities and
version of Statechart called ROOMChart, which dif- queued in priority order instead of FIFO order. This means
fers from conventional Statecharts by removing cer- that each capsule is a mutually-exclusive shared resource,
tain features that are difficult to implement in an and scheduled with the priority-based non-preemptive dis-
object-oriented framework, like instantaneous broad- cipline. One or more capsules can be grouped together and
cast of data among parallel/concurrent state machines. assigned to OS threads. Each OS thread processes incom-
ing messages in a non-preemptive manner, consistent with
the RTC semantics of capsules assigned to it. However,
there can be preemptions between different threads/tasks in
a multi-threaded system. (We use the words thread and task
interchangeably in this paper.) A capsule executing in the
context of a higher-priority thread can preempt another cap-
sule executing in a lower-priority thread.
The main target application domain of UML-RT is
telecommunication systems, which are generally soft
real-time in nature. Perhaps due to this reason, the de-
signers of the RoseRT CASE tool have not put much
emphasis on real-time issues when implementing a
UML-RT model on the target platform. The default ex-
ecution model is single-threaded, that is, all capsules
are mapped into the same thread of execution. Mes-
sages are queued and scheduled non-preemptively in Figure 2. An example application scenario.
priority-order. It is desirable to introduce more paral- The system consists of three objects O1 , O2
lelism and concurrency into the system to improve pre- and O3 , and two end-to-end scenarios t1 and
dictability by adopting a multi-threaded execution archi- t2 . Each scenario consists of multiple sub-
tecture. It is important to distinguish between the concepts tasks, which are actions triggered at the ob-
of design-level concurrency and implementation-level con- jects. Scenario t1 consists of subtasks t11 , t12
currency [7, 8, 9]. At the design level, each capsule and t13 , and scenario t2 consists of subtasks
conceptually contains its own logical thread of execu- t21 and t23 .
tion, but each logical thread does not necessarily have to be
mapped into an OS thread at the implementation level. Al-
though it is possible for each capsule to have its own OS O2 sends a message to O3 and triggers action t13 . We can
thread, it may incur too much context-switching over- view this scenario as a logical end-to-end task t1 consist-
head if there are a large number of capsules, perhaps thou- ing of three precedence-constrained subtasks t11 , t12 and
sands or more in a realistic application. A number of al- t13 . Similarly, the scenario t2 is an end-to-end task consist-
ternatives have been proposed for mapping a UML-RT ing of two subtasks t21 and t23 triggered by a 100ms pe-
design model into a multi-threaded executable. In this pa- riodic timeout message. There are multiple ways of imple-
per, we discuss these alternatives, and our own approach to menting this model on a multi-tasking RTOS, as discussed
schedulability analysis of the implementation model of the in the following sections.
RoseRT CASE tool. Note that the interaction style of ac-
tive objects communicating through asynchronous message 2.1. Capsule-Based Multi-threading, Capsule-
passing is very prevalent in real-time software, for exam- Based Priority-Assignment
ple, the Quantum Framework [6] advocates this program-
ming style without using expensive CASE tools. It makes This is the default implementation approach of RoseRT
a lot of sense in terms of good software engineering prin- CASE tool. As shown in Figure 3, one or more cap-
ciples such as modularity, encapsulation, decoupling of sules are grouped into threads with fixed priorities. Two ex-
interactions, etc. Therefore, the issues discussed in this pa- treme cases are mapping all capsules into a single thread, or
per has much wider applicability than just the RoseRT mapping each capsule into its own thread. We call this ap-
CASE tool. proach Capsule-based Multi-threading, Capsule-based
Priority-assignment (CMCP). In addition to applica-
2. Implementation Alternatives for UML-RT tion threads, additional system threads may be used to im-
Models plement framework services such as a periodic timer. We
do not consider system threads in this paper.
Suppose we have a logical UML-RT model as shown in
Figure 2, consisting of three capsules O1 , O2 , O3 and two 2.2. Capsule-Based Multi-threading, Scenario-
application scenarios t1 , t2 . Scenario t1 is initially triggered Based Priority-Assignment
by a periodic timeout message with period 10m that trig-
gers an action t11 in capsule O1 , which in turn sends a mes- This is proposed by Saksena in [7]. As shown in Figure 4,
sage to capsule O2 and triggers action t12 in O2 . Finally, similar to the RoseRT CASE tool, one or more capsules are
Figure 3. Capsule-Based Multi-threading, Figure 4. Capsule-Based Multi-threading,
Capsule-Based Priority-Assignment(CMCP), Scenario-Based Priority-Assignment
as implemented in the RoseRT CASE tool. (CMSP), proposed by Saksena [7]. One
One or more capsules are grouped into a or more capsules are grouped into the same
thread with uniform priority. The figure only thread. Thread priority is adjusted dynam-
shows one of many possibilities for grouping ically to maintain a uniform priority across
capsules into threads. The classic rate mono- each application scenario.
tonic analysis technique [4] is not applicable,
and the algorithm described in this paper is
needed to perform schedulability analysis. propriate. This is the case for Avionics Mission Comput-
ing software discussed in [2]. However, if there is intensive
interaction among different scenarios, then Capsule-Based
grouped together into threads. However, priorities are as- Multi-Threading is more appropriate in order to avoid ex-
sociated with the end-to-end scenarios, and the task priori- cessive locking and unlocking of shared capsules.
ties are adjusted dynamically to maintain the scenario prior- Saksena’s approach requires the engineer to stick to a
ities. We call this approach Capsule-based Multi-threading, programming discipline of dynamically adjusting capsule
Scenario-based Priority-assignment (CMSP). priorities to reflect the priority of the currently executing
end-to-end transaction. This approach hurts the encapsu-
2.3. Scenario-Based Multi-Threading, Scenario- lation of capsules by mixing system-level concerns (sce-
Based Priority-Assignment narios) with component-level concerns (capsules). It also
involves runtime system-call overheads that may or may
This is proposed by Saehwa Kim in [5]. As shown not be acceptable to certain resource-constrained embed-
in Figure 5, each application scenario is mapped into a ded systems. Certain small RTOSes may not even pro-
thread. Priorities are associated with the end-to-end threads, vide APIs to dynamically change thread priorities. Kim’s
with statically-assigned priorities. We call this approach approach involves modifying the RoseRT runtime kernel
Scenario-based Multi-threading, Scenario-based Priority- TargetRTS to have scenario-based instead of capsule-based
assignment (SMSP). multi-threading. It creates shared data when multiple sce-
narios cut through the same capsule, and necessitates error-
2.4. Discussions prone concurrency control mechanisms, such as mutex,
semaphore and monitor. This breaks a key advantage of
Saksena’s and Kim’s approaches associate priorities with UML-RT, which is to use buffered asynchronous message
application scenarios instead of capsules, which may be passing as the main communication mechanism among cap-
more intuitive from the perspective of the application. How- sules instead of shared data in order to minimize the need
ever, depending on application characteristics, it may be for concurrency control. Note that even in the native UML-
appropriate to adopt different implementation alternatives. RT model, there are passive objects, protected by mutexes,
If there is very little interaction between different applica- that are used to encapsulate shared data in addition to the
tion scenarios, then Scenario-Based Multi-Threading is ap- capsules/active objects. The number of such passive objects
3. Schedulability Analysis Techniques for
Capsule-Based Multi-Threading, Capsule-
Based Priority-Assignment
The task model of CMCP is very similar to the end-to-
end tasks with subtasks with varying priority as described
by Harbour, Klein, Lehoczky [3]. We call the schedulabil-
ity analysis algorithm introduced in [3] the HKL algorithm.
Due to space limitations, we do not provide the full details
of HKL algorithm, and refer the interested readers to [3]
for details. We only describe our adaptation of HKL algo-
rithm to fit the computational model of UML-RT by taking
into account extra blocking time caused by RTC semantics
and shared data objects.
Consider a UML-RT model consisting of m capsules or
Figure 5. Scenario-Based Multi-Threading, active objects O1 , O2 , . . . , Om , and n end-to-end scenarios
Scenario-Based Priority-Assignment or transactions, where each scenario is mapped into an end-
(SMSP), proposed by S. Kim [5]. Each to-end virtual thread, forming the taskset τ1 , τ2 , . . . , τn .
application scenario is mapped into a sep- Each end-to-end virtual thread τi , i = 1, . . . , n cuts through
arate thread with uniform priority. This one or more capsules, and triggers an action within each
eliminates the need for dynamic priority ad- capsule, forming a chain of subtasks τi1 , . . . , τim(i) . We use
justments, but creates shared data and O(τij ) to denote the capsule that the subtask τij belongs to,
necessitates error-prone concurrency con- and O(τij ) to denote the set of passive objects that τij ac-
trol mechanisms. cesses. Each subtask τij is actually an event-triggered ac-
tion within a capsule O(τij ). We use the word virtual thread
because each transaction actually consists of multiple seg-
ments of event/action pairs distributed over different oper-
should be minimized in relation to the number of capsules. ating system threads. Due to run-to-completion semantics,
a subtask may suffer a blocking time equal to the largest ex-
Even if Saksena’s or Kim’s approach were widely ecution time of other subtasks sharing the same capsule. A
adopted, there would still be a lot of legacy applica- capsule may also be involved in multiple sub-tasks within
tions that are not likely to be changed. Therefore, in- one end-to-end virtual thread. Each subtask τij is character-
stead of modifying the computational model of UML-RT ized by a set of parameters (Cij , Dij , Pij ), where
design tools to fit real-time scheduling theory, we be-
• Cij is the worst-case execution time.
lieve a better alternative is to adapt real-time schedul-
ing theory to fit the computational model of UML-RT • Dij is deadline of τij relative to the arrival time of task
design tools. Specifically, we describe a schedulabil- τi , taking 0 to be its arrival time.
ity analysis technique tailored for the computational • Pij is the fixed priority level of τij , equal to the prior-
model of Capsule-Based Multi-Threading, Capsule-based ity level of the capsule that τij belongs to.
Priority-Assignment (CMCP) shown in Figure 3. This tech- In order to adapt the HKL algorithm to the UML-RT
nique can be used as a subroutine when assigning prior- model, we need to take into account additional blocking
ities to capsules in order to achieve schedulability, or to time B(i) caused by the RTC semantics of capsules and mu-
meet other design objectives while guaranteeing schedula- tually exclusive access to passive objects, as shown in Equa-
bility. tion (1). We can add this term in the HKL analysis equations
For the CMCP aproach, the number of threads needs to derive the Worst-Case Response Time (WCRT) for each
to be carefully managed in order to strike a balance be- end-to-end task, and compare it against the deadline (typi-
tween context-switching overheads due to a large num- cally the same as task period) to determine schedulability.
ber of threads and blocking time due to insufficient paral-
lelism. We do not deal with the issue of grouping capsules 4. The Elevator Control Application Example
into threads or assigning priorities to threads in this paper;
rather, we focus on the problem of schedulability analysis We use the elevator control system as an application ex-
given a set of capsule-to-thread groupings and priority as- ample, taken from [1]1 . Figure 6 shows the 8 capsules and 1
signments.
X X
B(i) = Ckl + Cmn (1)
k,l,j,k!=i,Pkl <Pij ,O(τkl )=O(τij ) m,n,j,m!=i,Pmn <Pij ,P O(τmn )∩P O(τij )6=φ
data object involved in a single-processor implementation. mations for periods assigned to each task. For example, the
According to the CMCP approach, each capsule is assigned Request Elevator scenario is assigned a period of 200 ms
a fixed priority. There are three end-to-end scenarios con- by assuming that all 18 floor buttons (up and down buttons
sisting of subtasks of varying priorities: for each floor, except the top and bottom floors) are pressed
1. Stop Elevator at Floor. The elevator is equipped with within 3.6 seconds, which is likely to be the worst-case ar-
arrival sensors that trigger an interrupt to the capsule rival rate.
arrival sensors interface when the elevator approaches We can calculate Worst-Case Response Times (WCRT)
a floor, which in turn sends a message approaching using the schedulability analysis algorithm in Section 3 for
floor to the capsule elevator controller. The elevator the end-to-end tasks, as shown in the WCRT column of Ta-
controller invokes a synchronous method call on the ble 1. Note that we associate the WCRT of the end-to-end
passive data object elevator status and plan object to task with the last segment of the task in the table. No dead-
determine whether the elevator should stop or not. We lines are missed, and the system is schedulable.
do not model method invocations to passive data ob-
jects as separate subtasks, since the passive object in- 5. Conclusions and Future Work
herits the thread and priority from the invoking cap-
sule, and can be viewed as an extension of the invok- The RoseRT CASE tool provides a code generator that
ing capsule. But we do need to take into account block- generates functional code in C++ from UML-RT mod-
ing time caused by sharing of passive objects by mul- els, but does not take into account timing and schedul-
tiple threads. ing issues. Previous work has proposed to modify the run-
2. Select Destination. The user presses a button in the time model of UML-RT to make the classic Rate Mono-
elevator to choose his/her destination, which triggers tonic Analysis [4] applicable. Instead of modifying the run-
an interrupt to the capsule elevator buttons interface, time model of UML-RT to fit the schedulability analy-
which in turn sends a message elevator request to the sis algorithm, we modify the schedulability analysis al-
capsule elevator manager. The elevator manager re- gorithm to fit the native runtime model of UML-RT, i.e.,
ceives the message and records destination in the pas- Capsule-Based Multi-threading, Capsule-Based Priority-
sive object elevator status and plan, which is a shared Assignment (CMCP). This should make our approach more
object protected by the priority ceiling protocol, and acceptable to industry than previous work in the literature.
causes blocking time to the higher priority subtask. However, depending on application characteristics, it may
3. Request Elevator. The user presses the up or down be appropriate to adopt different implementation alterna-
button at a floor, which triggers an interrupt to the cap- tives.
sule floor buttons interface, which in turn sends a mes- We believe our work bridges the gap between a logical
sage service request to the capsule scheduler. The cap- UML-RT model and its real-time implementation on the tar-
sule scheduler receives message and interrogates the get platform by giving the engineer algorithms and tools for
passive object elevator status and plan to determine if assessing real-time properties of different ways of grouping
an elevator is on its way to this floor. If not, the sched- capsules into threads. It focuses on the nonfunctional/real-
uler selects an elevator and sends a message elevator time aspect of implementation synthesis, and is comple-
request to the capsule elevator manager. The rest of mentary to the existing code generator from UML-RT into
the sequence is identical to the select destination sce- C++ code, which focuses on the functional aspect of imple-
nario. mentation synthesis. As part of our future work, we plan to
implement the algorithm discussed in this paper, either as a
Consider a building with 10 floors and 3 elevators. All plug-in to RoseRT, or as a stand-alone tool that exchanges
end-to-end tasks are interrupt driven, not periodic. In order data with RoseRT through the XMI interface.
to perform schedulability analysis, we estimate the worst- One limitation of our approach is that it can only handle
case arrival rate of the interrupts and use them as approxi- linear task-chains, but not more general task-trees or task-
graphs. It is an open research issue as to how to extend the
1 Note that the analysis technique described in [1] is not entirely accu-
rate, since it does not take into account precedence relationship among HKL algorithm to deal with task-trees or graphs.
subtasks. Also the original example is not based on UML-RT, but the This paper has considered the problem of schedulability
concepts are similar enough to be viewed as a UML-RT model. analysis given a system configuration of capsule-to-thread
t5
t1:Stop Elevator at Floor
DirectionLamps t51
Monitor
t11 ArrivalSensors t12 Elevator
Interface Controller
t4
FloorLamps t41
ElevatorStatusPlan Monitor
t2:Select Destination
t3:Request Elevator
t21 ElevatorButtons t22 Elevator t33 t32 FloorButtons t31
Scheduler
Interface Manager Interface
Figure 6. The event sequence diagram for the single-processor elevator control system.
Task Period WCET Priority WCRT
t1 : Stop elevator at floor
t11 : Arrival Sensors Interface 50 2 9 -
t12 : Elevator Controller 50 5 6 15
t2 : Select Destination
t21 : Elevator Buttons Interface 100 3 8 -
t22 : Elevator Manager 100 6 5 22
t3 : Request Elevator
t31 : Floor Buttons Interface 200 4 7 -
t32 : Scheduler 200 20 4 -
t33 : Elevator Manager 200 6 4 46
t4 , t5 : Other Tasks
t41 : Floor Lamps Monitor 500 5 3 58
t51 : Direction Lamps Monitor 500 5 2 63
Table 1. The taskset of the single-processor elevator control system. Not shown in the table, is block-
ing time caused by the shared object ElevatorStatusPlan, which we assume to be 1ms. Also note that
it is a common practice to assign a higher priority to the interrupt handler task [4], that is, the Inter-
face subtasks here, in order to avoid losing any interrupts.
grouping and thread priority assignment, but it is still an References
open issue as to how to arrive at such a configuration. Ex-
haustive search is not feasible in general because the size of [1] B. Selic, G. Gullekson, and P. T. Ward, Real-Time Object
design space grows exponentially with the number of cap- Oriented Modeling. Addison Wesley, 1994.
[2] M. Saksena and P. Karvelas, “Designing for schedulability:
sules or priorities. There may be some guidelines to follow,
integrating schedulability analysis with object-oriented de-
such as “assign higher priority to interrupt service routines
sign,” in Proc. IEEE Euro-Micro Conference on Real-Time
to avoid losing interrupts”. We plan to investigate applica- Systems, 2000, pp. 101–108.
bility of optimization techniques such as branch-and-bound, [3] M. Saksena, P. Karvelas, and Y. Wang, “Automatic synthe-
simulated annealing and genetic algorithms to exploration sis of multi-tasking implementations from real-time object-
of the design space in order to achieve a close-to-optimal oriented models,” in Proc. IEEE International Symposium on
design in terms of objectives such as minimized number of Object-Oriented Real-Time Distributed Computing, 200, pp.
threads or minimized response time for critical application 360 – 367.
scenarios. The schedulability analysis algorithm discussed [4] M. Saksena, A. Ptak, P. Freedman, and P. Rodziewicz,
in this paper can be used as a subroutine during the design “Schedulability analysis for automated implementations of
space exploration process for priority assignment and im- real-time object-oriented models,” in Proc. IEEE Real-Time
plementation synthesis of UML-RT models. Systems Symposium, 1998, pp. 92 – 102.
[5] (2004) The Quantum Framework website. [Online]. Avail-
able: http://www.quantum-leaps.com/qf.htm
[6] M. H. Klein, T. Ralya, B. Pollak, and R. Obenza, A Prac-
titioner’s Handbook for Real-Time Analysis: Guide to Rate
Monotonic Analysis for Real-Time Systems. Kluwer Aca-
demic Publishers, 1993.
[7] J. Masse, S. Kim, and S. Hong, “Tool set implementation for
scenario-based multithreading of uml-rt models and experi-
mental validation,” in Proc. IEEE Real-Time and Embedded
Technology and Applications Symposium, 2003, pp. 70–77.
[8] Z. Gu, S. Kodase, S. Wang, and K. G. Shin, “A model-based
approach to system-level dependency and real-time analysis
of embedded software,” in Proc. IEEE Real-Time Technol-
ogy and Applications Symposium, 2003, pp. 78–85.
[9] M. Harbour, M. H. Klein, and J. Lehoczky, “Timing analy-
sis for fixed-priority scheduling of hard real-time systems,”
IEEE Trans. Software Eng., vol. 20, no. 2, pp. 13–28, 1994.
[10] H. Gomaa, Designing Concurrent, Distributed, and Real-
Time Applications with UML. Addison-Wesley, 2000.
