Team Espresso

Overall Objectives
Scientific Foundations
Application Domains
New Results
Contracts and Grants with Industry
Other Grants and Activities

Section: New Results

The UML profile MARTE for Real-Time and Embedded Systems Design

Participants : Jean-Pierre Talpin, Thierry Gautier, Christian Brunette.

The collaboration between the AOSTE, DART, ESPRESSO teams from INRIA, CEA and THALES Research and Technology, in the context of the CARROLL Research Programme (see ) aims at the standardization of a UML 2.0 profile for real-time embedded systems (MARTE) before the Object Management Group (OMG). The main objectives of MARTE are the following : defining time, concurrency and communication models, mixing control-flow and intensive computational data-paths, modeling architectural platforms and adopting Y-chart approaches for allocation of application functions onto architectural resources). It bears strong connections with other OMG standardization attempts (some accepted already, some only proposed) such as the SysML (System Engineering in UML) standard, or AADL and UML4SoC current RFC proposals. The MARTE profile is divided in three subparts (some would say subprofiles):

A first contribution of Espresso to MARTE, Figure 12 , is to propose a model of the APEX-ARINC 653 operating system services, based on related work reported in Section  6.4 .

Figure 12. Part of the ARINC 653 Library in the MARTE profile

In the MARTE profile for UML, Espresso proposes a Chapter on real-time and embedded application modeling (RTEAM). The Chapter is concerned with the association of a timing model with behavioral description diagrams such as activities or state-machines. The main features of this combination appear in Figure 13 , which depicts the model of an alarm clock using timed activity diagrams.

Figure 13. Timed Activity Diagram for an Alarm

It is composed of the timed activity Count which counts the number of ticks comprised between a start and a stop event. It is composed of the timed activity Check which emits an alarm when the count becomes 0. A causality dependency schedules the execution of Count before (or at the same time as) Check. Upon completion, Check either terminates the activity (if the Alarm is raised) or loops back with a clock unit delay until the next event occurs. All control and object flows in red denote an implicit "immediate" stereotype that indicate branches that can be executed immediately. no buffer is provided). All control and object flows with a delay stereotype are executed at the next unit of the parent activity clock.

The activity Count is complemented with a clock relation which defines its clock CountClk by the union of the canonical clocks of its start, stop and tick input events. The clock of the Check activity is defined by the canonical clock of the timed event tick. Additionally, a dependency specifies a scheduling relation that enforces the execution of Count to happen before or at the same time as Check. By looking into the definition of Count and Check, one indeed notices that Count computes the count value that is tested against 0 in the Check activity. An explicit causality stereotypes helps getting one aware of that constraint. Another clock relation is depicted by the OCL constraint of the Select activity of the Count diagram. While the events start, stop and the guard [last >= 0] have no explicit clock relation, it is necessary to deterministically choose one of these events in order to deterministically set one of the init, default or last values to count. This is done by making a priority relation between start, stop and last explicit.


Logo Inria