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 http://www.carroll-research.org ) 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):
-
TCR (Time and Concurrent Resources) is meant to provide the infrastructure notions of logical/discrete and physical/real time, and the basic concurrency and communication models relevant to the profile. It should extend in many ways the corresponding parts of the SPT profile, in particular in adding the notions of synchronous/clocked systems (with synchrony and priorities).
-
SPA (Schedulability and Performance Analysis) should provide with features allowing the non-functional performance evaluation and static or dynamic scheduling policies of systems.
-
RTEM (Real-Time Embedded Modeling) will take these time informations into account to provide for behavioral definitions of hierarchical models, as in state and activity diagrams for instance). It also claims for independent high-level modeling of architectural platforms and the platform-based design methodology using useful feature of the two previous subprofiles to build and model optimized allocation links between application and architectures. It also requires dedicated modeling features for frequently encountered structures in real-time and embedded systems.
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 .
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.
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.
