13th IEEE International Conference on Engineering of Complex Computer Systems
An Execution Framework for MARTE-based Models Chokri Mraidha, Yann Tanguy, Christophe Jouvray, François Terrier, Sébastien Gérard CEA LIST, F-91191 Gif sur Yvette, France
[email protected] application. A way to achieve this goal is to make application models executable. A model is deemed executable when it can be operated on a hardware execution unit. A model can be operated if its behavior is clearly and completely specified. Hence, in order to enable a real-time application model executability, that model has to be specified in a language that provides on the one hand all the concepts needed with a precise semantics and on the other hand the concepts to ensure completeness of behavioral models. UML [1] is the most used modeling language for design of systems in MDE approaches. UML is a general purpose language that provides concepts to ensure behavioral models completeness thanks to its StateMachine, Interaction, Action and Activity packages. UML also offers concepts for time modeling but those are limited and not sufficient to capture realtime qualitative features of real-time applications. Moreover, in order to guarantee UML’s general purpose language characteristic, the UML specification gives an openness aspect to its semantic by leaving some points not precisely defined and by providing some semantic variation points. To handle domain specificities, UML provides a specialization mechanism called profiles. Profiles provide the capability to tailor the UML metamodel for different domains. This tailoring is operated by the extension of the metamodel metaclasses to adapt them for the targeted domain. These extensions introduce new semantics that is precisely defined for the domain. The UML profile for MARTE is a specialization of UML that provides concepts dedicated to real-time modeling for design and analysis of real-time applications and platforms. On the one hand, MARTE profile provides concepts that support modeling of qualitative and quantitative features of real-time applications at a high level of abstraction, and on the other hand MARTE defines precise semantics for the those concepts that makes them exploitable to build executable models. In order to execute MARTE models we need a framework that supports execution of MARTE high level real-time concepts. After a brief presentation of
Abstract The UML is now the most widespread language for systems modeling. However, this language has been designed as a general purpose modeling language that may lack for modeling constructs for specific domain, as for the real-time embedded (RTE) domain. In order to fill this lack, OMG has standardized a UML extension, called MARTE. This UML profile consists of specific concepts defined to cope with the specific concerns of the RTE domain. Of course, MARTE provides support for enabling model driven engineering (MDE) of RTE systems. The MDE development paradigm makes the model the first class citizen of development processes. Models need then to be productive. To achieve this purpose, providing methodology enabling model to be executable is a real challenge. The goal of this paper is then to present, on the one hand a UML/MARTE based methodology for executable RTE systems modeling and on the other hand, a framework and its underlying model transformations required to execute UML models conforming to the MARTE standard.
1. Introduction Building models of real-time application requires a modeling language that enables the description of the specific features inherent to real-time domain. Actually real-time applications have some qualitative features such as deadline and period, as well as quantitative features related to communication, concurrency and behavior aspects. The modeling language must a least provide the syntax (modeling concepts) to represent such features. Moreover, semantics associated to those concepts has to be precisely defined and unambiguous in order to ensure the executability of real-time applications models. Actually, in order to reduce the impact of changes on the system, we should be able to validate at early stages of the development process, functional and extra functional properties of the
978-0-7695-3139-7/08 $25.00 © 2008 IEEE DOI 10.1109/ICECCS.2008.37
222
Authorized licensed use limited to: Baylor University. Downloaded on December 12, 2008 at 22:52 from IEEE Xplore. Restrictions apply.
the MARTE profile in section 2, section 3 introduces the Accord|UML methodology which is a modeling framework that relies on MARTE modeling language as well as the Accord execution framework. Section 4 describes the transformation process to an executable prototype of MARTE-based models on the Accord execution platform.
with information required to perform schedulability or performance analysis. The MARTE_DesignModel profile provides support required from specification to detailed design of realtime and embedded systems. It covers software resource modeling (SRM) and hardware resource modeling (HRM) by specializing GRM core concepts. The following section details RTE Model of Computation and Communication (RTEMoCC) profile on which the Accord real-time application development framework relies.
2. MARTE profile This section presents an overview of the UML profile for MARTE. As our main concern is about realtime applications modeling, we will focus on this aspect of the language after a brief presentation of MARTE general architecture. For a more detailed presentation of the following concepts, the reader must refer to the standard specification document [2].
2.2. RTEMoCC profile Real-time applications development requires possibilities of modeling on the one hand quantitative features such as deadline and period and, on the other hand, qualitative features that are related to communication, behavior and concurrency. RTEMoCC profile provides concepts for modeling both aspects at a high abstraction level.
2.1. MARTE architecture overview. The UML profile for MARTE adds capabilities to UML for real-time and embedded systems development for design and analysis purposes. As illustrated in Figure 1, MARTE profile is organized around three main packages.
2.2.1. RtUnit and PpUnit concepts RtUnit and PpUnit stereotypes are specializations of UML BehavioredClassifier concept (see Figure 2). A real-time unit (RtUnit) is similar to the UML active object but with a more detailed semantics modeled thanks to its properties. An RtUnit may be seen as an autonomous execution resource that owns one ore more schedulable resources to handle incoming messages. If isDynamic property is set to true, the schedulable resources are created dynamically when required, otherwise the RtUnit has a pool of schedulable resources. When no schedulable resource is available, the RtUnit may wait indefinitely for a resource to be released, wait for only a given amount of time, etc. This semantic point is fixed with the poolPolicy property (and poolWaintingTime for waiting time specification). An RtUnit owns a concurrency and behavior controller for managing message constraints according to its current state and current execution constraints attached to incoming messages. An application owns at least one main RtUnit which is specified with the isMain boolean property set to true. Following its creation each RtUnit that is declared as main may start a main real-time service that is specified with main property of RtUnit stereotype. Furthermore, an RtUnit may own one or several behaviors. A message queue for storing incoming messages is defined for each of these behaviors. When modeling for concurrency, it is necessary to be able to model shared information. Protected passive
Figure 1: MARTE architecture MARTE_Foundations package defines founding concepts for real-time and embedded systems. These concepts cover generic applications and platform artifacts modeling: Generic components modeling (GCM), generic resource modeling (GRM), allocation modeling (Alloc), non functional properties modeling (NFPs) and time modeling (Time). These foundational concepts are refined for design purpose in the MARTE_DesignModel profile and for analysis purpose in the MARTE_AnalysisModel profile. The MARTE_AnalysisModel profile offers analysis modeling concepts. Actually, analysis models require specialized concepts that have their own terminology and semantics. The generic quantitative analysis modeling (GQAM) profile provides these concepts by refining core concepts of MARTE_Foundations. GQAM is then used to specify schedulability analysis modeling (SAM) and performance analysis modeling (PAM) profiles that offer facilities to annotate models
223
Authorized licensed use limited to: Baylor University. Downloaded on December 12, 2008 at 22:52 from IEEE Xplore. Restrictions apply.
units (PpUnit) have been introduced for that purpose. PpUnits may specify their concurrency policy either globally or for all of their provided services through the concPolicy property. PpUnits do not own schedulable resources for execution. Therefore, a PpUnit uses a schedulable resource of the RtUnit that invokes one of its services to execute it.
experts for specification and prototyping of embedded real-time systems. This section briefly introduces the Accord|UML methodology before giving an overview of its associated workbench.
3.1. Methodology As depicted in Figure 3, Accord|UML relies on a basic, three-stage process cycle that ensures analysis, prototyping and testing. A seamless and iterative process of UML model refinement achieves progression from one to another of these stages. To do so, the Accord|UML methodology uses the MARTE profile to define specific packages of model mappings.
Figure 2: MARTE RtUnit and PpUnit concepts 2.2.2. Real-time feature concept A real-time feature (RTF) defines characteristics that can be attached to a real-time service, a real-time action, a message or a signal. The rtf stereotype is used to annotate model elements with real-time features according to the properties defined in this stereotype. A real-time feature may specify the occurrence kind of a behavior (e.g. periodic, aperiodic, sporadic, etc.) through the occKind property. A time reference used by the other relative timing properties may be specified through the tRef property. An rtf may also specify a deadline (relative or absolute) through the relDl and absDl properties. A ratio of allowed missed real-time constraints may be specified through the miss property. MARTE language provides concepts for modeling real-time and embedded applications. In order to ease their development with this language and gather benefits from its use we need on the one hand a methodology that helps engineers to structure their models, and on the other hand we need an infrastructure that is able to exploits these MARTE models. The following section presents a framework covering those needs.
Figure 3: SPEM description of Accord|UML methodology This method is iterative for two reasons: It is based on three consistent and complementary models describing structure, interaction and behavior respectively. - And prototyping activities are performed throughout the specification stage to validate the specification models of the application. Prototyping takes place in addition to the testing stage, thus providing developers with useful feedback for improving their specifications. The structural model is an entity-relation based model and consists of the classes and their dependencies involved in the application. The interaction model describes the various possible scenarios (also called "tasks" or "activities") and includes the objects of the application involved in the scenario and the set of messages exchanged by them to perform a given job. Behavior model building consists of describing the behavior with state-transition diagram for each class of the application. With these three models, developers can describe a real-time system, explaining real-time constraints (e.g. deadline, periodicity), concurrency of processes, and various kinds of communication modes (e.g. synchronous, asynchronous). In the 3.2 and 3.3, few details are given on analysis model and execution platform. The prototype stage is detailed in section 4. -
3. Accord Overview Accord|UML [3, 4] is a model-based methodology dedicated to embedded real-time applications development. Its audience includes engineers who are not “software” experts but rather “software-intensive” systems developers. In this context, its aim is to provide both the method and the underlying toolkit required by non real-time low level implementation
224
Authorized licensed use limited to: Baylor University. Downloaded on December 12, 2008 at 22:52 from IEEE Xplore. Restrictions apply.
The Accord kernel provides resources on which we can allocate the RtUnits used in the application to ensure their execution. This allocation is specified in the transformation towards the prototype model which is detailed in the following section. A deadline controller verifies the validity of specified real-time constraint at run-time. Likewise, a scheduler defines the RtUnits which have to be activated or not. At this time, the scheduler is defined in the Accord kernel. To facilitate the interactions with the operating system, the scheduler will be integrated in the Accord VM as a service. If the operating system doesn't provide a scheduler compliant to application requirements, the VM scheduler service will be used. Else, the scheduler of the operating system will be kept.
3.2. Analysis Modeling Modeling real-time applications using Accord|UML relies on the previously described concept of separated views grouped as a consistent set. In a preliminary specification stage, the designer defines the use cases of the application and the several interactions with the environment. In the detailed specification stage, Accord|UML identifies three partial, complementary and coherent views of the system: The structural view defines the architecture of the application. This model is mainly based on UML class diagrams, and describes the whole application classes including their property and relationships. Interactions between classes are not treated here, relationships just model the fact that classes need or may need to have communication support. The behavioral view focuses on the local behavior of the classes defined in the structural view. The goal of this view is to clarify both class and operation behavior. Class behavior relates to control aspects, while operation behavior is the algorithmic description of operations [5]. UML state machine diagrams and an action language [6] based on UML Actions are used to specify a complete UML behavioral model. The interaction view concerns the “instance layer” of the application model. It connects the various instances used in the application and describes explicitly how messages are exchanged at runtime between a set of instances to realize the tasks that the application is required to realize. To introduce real-time concepts, the analysis model lied on MARTE. The structural view outlines PpUnits and RtUnits. For classes stereotyped with RtUnit, the designer could add real-time constraints on the behavior and the interactions. Real-time constraints are specified with the MARTE rtf. These stereotypes are taken into account during the platform specific model and are managed by the execution platform.
4. Accord Platform Specific Model The analysis models described in the previous section make an extensive use of real-time concepts owned by the RTEMoCC sub-profile. Some of these are implemented in the Accord execution platform. This part describes how the analysis models are refined and mapped on the software resources owned by the Accord execution framework to produce executable model. The result, called prototyping model (PrM) is a platform specific model, executable on an instance of the Accord platform.
4.1. Making analysis models executable A model is executable when it can be operated on a computer. There is mainly two ways to make a model executable. The first one requires a model execution engine which is a kind of model interpreter that can read a model and directly operates on a computer or any hardware execution unit. Building a UML virtual machine requires a strict and precise semantics for UML. There is some ongoing work that aims at providing such a virtual machine at the OMG [7]. In [7] a subset of UML (fUML) is considered and precise execution semantics is defined for that subset in order to make a virtual machine that would be able to execute models specified with that subset. However, our interest here is to be able to execute a model that is specified with MARTE which a UML profile which is out of the scope of fUML. The second way to model execution consists in defining a transformation from the model to an existing executable platform and formalism. This is usually achieved through a code generation process. For that purpose, Accord|UML provides a dedicated code
3.3. Execution Platform The execution platform is decomposed into several parts: (i) a POSIX virtual machine (Accord VM), (ii) an operating system abstraction layer (the Accord kernel) and (iii) a real-time operating system (e.g. VxWorks, Linux). The virtual machine offers basic mechanisms like thread, mutex, semaphore or condition variables. These mechanisms could be called during the creation of the prototype model. They are not dependent of the operating system.
225
Authorized licensed use limited to: Baylor University. Downloaded on December 12, 2008 at 22:52 from IEEE Xplore. Restrictions apply.
generation facility taking into account real-time features specified at a high level of abstraction, and an execution framework. This framework provides an operating support for some of the high level real-time concepts defined in the MARTE RTEMoCC subprofile. Hence, the Accord framework gives sense to features defined in RTEMoCC such as the RtUnit concept, by providing execution support to realize the behavior, communication and message management associated to this kind of objects. The code generation facility provided by Accord|UML consists both in: - A set of transformation used to apply implementation patterns on real-time concepts, - A standard C++ code generator, “standard” meaning that it is not dedicated to Accord|UML or the execution framework. The following part describes how the implementation patterns are used to make the models executable according to the execution framework.
-
RtService operations for the algorithmic aspects
Algorithmic part of the behavior Control part of the behavior
Figure 4: RtUnit behavior modeling The specified behavior is operated using software execution resources. These execution resources offered by the framework are OS thread based, managed in a global pool by the RtUnit that loads and starts the execution. These threads are dynamically allocated to the RtService for execution and released after. Regarding the modeling rules, to comply with this execution semantics, RtUnits must be used with the isDynamic property set to false (execution resources are not created dynamically) like shown on the picture below. The framework also provides support for communication and distributed execution. Software resources offered by the framework for communication are point to point or multicast RtService calls.
4.2 Mapping analysis models on the execution framework In order to make analysis model executable, the real-time concepts introduced in RTEMoCC must be refined and completed with C++ implementation patterns, or mapped on the software resources offered by the execution platform. The RtUnit concept may be considered as the founding concept in the center of the RTEMoCC sub-profile. This part will focus on RtUnit and related concepts and their executable implementation in the framework.
Fixed by the framework
4.2.1 Software resources of the execution platform
User defined
Although RtUnit stereotype from MARTE refines UML active objects with a more precise semantics, its semantic is still not fully defined. It depends from the use of related RTEMoCC concepts (RtService, RtBehavior, InMsgQueue …), and from the properties associated to stereotypes in the RTEMoCC profile. Obviously, the execution framework does not provide an exhaustive support for all the possible combinations of concepts and semantics that may be addressed through RtUnit, some of them are fixed by the framework. For example, the execution platform supports “Earliest Deadline First” scheduling policy associated to the message queue of RtBehavior but no implementation is offered for “FIFO” or “Time Table Driven” scheduling policies. The figure below illustrates modeling of behavior for RtUnits supported by the platform. It is described following two separated aspects: - RtBehavior state machine for the control aspects
Figure 5: RtUnit property values for a loader class 4.2.2 Implementation patterns Applying the implementation pattern to RtUnits for Accord execution framework mainly consists in: - Splitting the RtUnit into two C++ classes, an implementation class and a stub class. - Linking these classes with generic classes from the execution framework, and providing required C++ operation to deal with concurrency, communication and behavior. An example of the pattern applied to RtUnit is given in the figure 7. The link with generic classes
226
Authorized licensed use limited to: Baylor University. Downloaded on December 12, 2008 at 22:52 from IEEE Xplore. Restrictions apply.
from the framework is mostly done via inheritance. The RtUnit stub is expected to deal with communication and service concurrency. It receives signal or service call, transforms them into messages with concurrency and store them into the message queue of the corresponding RtUnit.
a well formed model that would be more easily exploited by tools. In this paper we have proposed the Accord|UML methodology to play the role of that structuring framework. An important aspect of models exploitation is to enable their executability. The Accord framework provides the infrastructure for MARTE models execution. We have exposed in section 4 the automatic transformation process for mapping MARTE concepts to Accord execution resources. The Accord execution platform could be parameterized with a subset of MARTE concepts properties but do not support all parameters values, hence this introduces some restrictions in usage of MARTE. These limitations are handled in the Accord|UML methodology. To reduce the number of limitations and enhance MARTE models execution support, an ongoing work consists in enhancing the Accord execution platform parameterization.
Figure 6: CruiseControl RtUnit after pattern application
6. References
The RtUnit (CruiseControl_impl in the example) manages the behavioral aspects. This is done by: - Translating the RtBehavior state machine into C++ code (checkPreCond and checkPostCond operations) - A method (startCL) that selects the user defined code to execute according to service call found in the message. The message scheduling policy and service concurrency management are operated by the framework and don’t appear in the RtUnit pattern. Thankfully this pattern application is fully automated with model transformations. As a result, users don’t need to be experts of C++ or experts of the real-time execution framework. They just need to understand the underlying semantics and can concentrate the efforts on the application itself. For the same matter, a large part of the concurrency is handled by the framework transparently.
[1] OMG, "Unified Modeling Language: Superstructure," formal/2007-02-05, 2007. [2] OMG, "A UML Profile for MARTE," ptc/07-08-04, 2007. [3] S. Gérard, "Modélisation UML exécutable pour les systèmes embarqués de l'automobile," Evry University, 2000. [4] S. Gérard, F. Terrier, and Y. Tanguy, "Using the model paradigm for Real-Time Systems Development," presented at OOIS'02-MDSD, Montpellier, France, 2002. [5] C. Mraidha, S. Gérard, F. Terrier, and J. Benzakki, "A Two-Aspect Approach for a Clearer Behavior Model," presented at 6th IEEE International Symposium on Objectoriented Real-time distributed Computing, Japan, 2003. [6] C. Mraidha, S. Gérard, Y. Tanguy, H. Dubois, and R. Schnekenburger, "Action Language Notation for Accord/UML," CEA 2005. [7] OMG, "Semantics of a Foundational Subset for Executable UML models," ad/06-05-02, 2007.
5. Conclusions MDE of real-time and embedded applications requires a modeling language providing concepts to capture at a high level of abstraction their qualitative and quantitative features. The UML profile for MARTE provides such concepts and is suited for realtime applications modeling. Furthermore, in order to gather benefits from model driven approaches and the abstraction provided by MARTE models, we have to exploit as automatically as possible those models to speed up the development process of real-time applications. To enable models automatic exploitation we need to give a structuring framework that defines modeling rules that must be followed in order to obtain
227
Authorized licensed use limited to: Baylor University. Downloaded on December 12, 2008 at 22:52 from IEEE Xplore. Restrictions apply.
