Toward a Framework for Explicit Platform-Based Transformations Frédéric Thomas 1, Jérôme Delatour 2, François Terrier 1 and Sébastien Gérard 1 1
CEA LIST – Boîte 94 – Gif sur Yvette 91191
{frederic.thomas, sebastien.gerard, francois.terrier}@cea.fr
Abstract One promising solution for meeting the demands of constantly-evolving Real-Time Embedded (RTE) software is the model-driven development (MDD) paradigm, based on the principle of separating the description of an application from its platform-specific implementation. Existing model-driven approaches strive to achieve this separation through dedicated model transformations which actually embed a given computing platform model. This is a major impediment for MDD dissemination in an industrial context. The resulting dearth of customizable transformations hampers description of reusable generative processes. We therefore propose to explicitly describe the targeted computing platforms in the design process. The main benefit expected from explicit platform models is a true separation of concerns that enables efficient, reusable and customizable generative processes. This proposal is strongly promoted by the new OMG (Object Management Group) standard profile for Modeling and Analysis of Real-Time and Embedded systems (MARTE), with its software multitasking platforms. In this paper, we first describe the MARTE feature and then propose a framework for integrating explicit platform descriptions into a modelbased generative process.
1. Introduction
Real-Time Embedded Systems (RTES) are often heterogeneous by nature. Designing RTE systems thus means coping with different computing platforms, mixed computation modes, heterogeneous constraints (e.g., time, energy, memory footprint and determinism) and heterogeneous analysis or design formalisms. For managing such heterogeneity issues, the main paradigms of the last two decades were abstraction, refinement (e.g., code generation and model transformation) and the separation of concerns. The foundations laid at that time led to description of heterogeneous models that represent a system at varying levels of detail and for differing goals. In this approach, certain models are used to specify, analyze and sometimes also generate the system (or parts
2
ESEO TRAME
[email protected]
thereof). These models are described with different languages and supported by different tools. Each tool provides a specific support for expressing specific needs. In the model-driven engineering (MDE) community, all those supports are called platforms. The analysis tools, real-time operating systems (RTOSs) and specific languages dedicated to describing RTE applications are examples of such platforms. Platforms can be described either as models or as metamodels. Historically, model-driven methodologies for RTE systems have focused on improving dedicated RTE platform models [1] [2] [3] (i.e. platform models used as metamodels). At the same time, the MDE community has proposed generic transformation languages (e.g. [4] and [5]) which facilitate the description of dedicated bridges between metamodels. Current model-driven approaches for RTE therefore entail specific model transformations from a set of source platform to a set of target platform. In many case, the platforms are not described as input models of the transformation. In the RTE analysis domain, the use of stereotypes to annotate Unified Modeling Language (UML) [6] models and then drive model transformation is a typical example. Those stereotypes often account for the transformation description. As a result, transformation is a “mixture-of-concerns”. It involves source and target RTE platform concepts (e.g., task, semaphore and mailbox), transformation language features (e.g., for and while statements) and RTE constraints (e.g. memory footprint and execution time) for example. That failure to separate concerns hampers the description of flexible and reusable generative processes for RTES. The purpose of this paper is to propose a modeldriven framework enabling explicit platform description and consideration of the latter as a model transformation parameter. The proposed approach uses platform characteristics as an input for execution of a transformation and not for transformation rule description. The main benefit expected from explicit platform model descriptions is a clear separation of concerns within the design flow. Input models
customize a fixed and reusable generative process. RTE decisions are made in the input models and not implicitly in the transformation description. In this way, the generative process becomes more flexible, more adaptable and more reusable for several RTE platforms. In this paper, we have concentrated on the transformations dedicated to porting multitasking applications to heterogeneous computing platforms (e.g., multitasking operating systems). For reasons of space, the paper does not cover preservation of RTE properties through transformation. At the present time, our main challenges are to provide efficient modeling artifacts for describing the software computing platforms themselves and to efficiently integrate these models into a transformation process. After a quick look at the Software Resource Model (SRM) subprofile of the MARTE standard [7], we describe a generic transformation framework based on explicit platform models. The final sections of the paper are devoted to our conclusions and a discussion of possible future research orientations.
SRM is not a new API for real-time operating systems (RTOSs), but instead a language for describing such APIs. For this reason, the SRM profile is based on the “Resource-Service” pattern, which allows description of resources that own properties and provide services. Certain properties and services also play a role. Roles are therefore modelled as resource attributes. Figure 1 illustrates such pattern. The schedulable resource of SRM shown here is a task: modeling of a context for executing concurrent action sequences. A schedulable resource owns attributes and services. Some of these attributes play the role of priorities. Some of these services play the role of activation actions. For reasons of space, this paper cannot give a detailed description of the SRM profile, but further information on the subject can be found in [7] and [8]. It is expected that the SRM profile is used in three basic steps. The first aims at defining a UML library in order to depict the RTOS API useful for designing the RTE applications. UML
2. Multitasking resource modeling
We examined the use of a metamodel for describing multitasking computing platforms in [8]. We concluded that a metamodel could serve as a language to describe the application programming interface (API) for such platforms. The term “API” is not limited to the structural description of services provided by the platform. In our approach, an API gathers all observable platform features from a user point of view. Characteristics such as performance, reliability or behaviors (e.g. observable states and transitions) make up the platform API. Therefore, we considered the model of a platform as a model of such interface, and thus the platform metamodel as a language for describing that interface. Finally, we proposed a language – the UML Software Resource Modeling (SRM) subprofile of MARTE – for RTE multitasking platforms. In the current version of MARTE, the SRM profile is limited to the modeling of mechanisms and services provided by the platform SRM was built following a detailed analysis of main RTOS API standards ([9], [10], [11]) and a few widely-used industrial RTOSs (e.g. [12]). From this analysis, three families of concepts were identified: concurrent computation contexts (e.g., an interrupt and a task), interactions between concurrent contexts for either communication or synchronization purposes (e.g., mailbox and semaphore mechanisms) and hardware and software resource brokering concepts (e.g., driver and scheduler).
« profile » SRM
« import »
« metaclass » UML::kernel::Classes::Class ownedAttribute priority « stereotype » SwSchedulableResouce
0..*
« metaclass » Property
0..* ownedOperation activate
0..*
« metaclass » Operation
0..*
« modelLibrary » OSEK/VDX Platform
1
« swSchedulableResource » BasicTask +priority : UINT32
« apply »
« swSchedulableResource » priority = [ priority ] 2 activate = [ activate() ]
+activate()
« model » OSEK/VDX Application
3
« import »
t1 : BasicTask priority = 10
Figure 1. "Resource-Service" modeling pattern For example, Figure 1 outlines a part of the OSEK/VDX-OS model library. OSEK/VDX-OS is a multitasking execution platform for automotive applications. It provides a BasicTask concept for executing actions concurrently. The second step is to refine the abovementioned platform model using SRM.
The user thus applies the SRM profile to clarify the semantics of elements previously defined. According to the SRM terminology, an OSEK/VDX basic task is a schedulable resource. Its attributes and operations are referenced in the stereotype properties. The third step consists in using this annotated model library to describe the multitasking application: the OSEK/VDX application in Figure 1. The latter is said to be either the platform instance model or the application.
3. Explicit platform-based transformations In this section we show how an explicit platformbased transformation framework is described using the abovementioned platform metamodel. After a discussion of the common generic transformation scheme, we describe an implementation of this scheme and then use a simple example to illustrate the transformation framework.
3.1. Platform-based transformation scheme
We consider a model transformation τ : S → T as a function that takes a set of model in S and produces a model in T [13] [14]. S and T models are conformed to a set of metamodels. In our specific case, the metamodel set is made of a single main UML metamodel, which is extended with UML profiles using the “Resource-Service” pattern (e.g., the SRM profile). The description of τ is only dependent on these metaelements. One result of explicit platform models is that they are then included in the set S . In other words, they are at the front end of the transformation process instead of being implicit in the transformation description (i.e. τ description). S is thus made up of the source platform model, the target platform model and the source platform instance model. Target platform model libraries
Source platform model libraries
« import »
« import »
t Source platform instance models
source model set (S)
Target platform instance models
target model set (T)
Figure 2. Overview of the transformation scheme
All these models are in charge of grouping domain concepts (i.e. RTE concepts) and user concerns (i.e. RTE design decisions) in order to efficiently separate the concerns. τ is a generic transformation responsible for transforming any source instance platform models into any target instance platform models. Figure 2 illustrates such a scheme.
3.2. A platform-based framework
Figure 3 materializes the previous scheme for the UML SRM profile. On one hand, the τ UML2 SRM transformation consists of both stereotyping platform concepts with SRM stereotypes and referencing platform attributes parameters and operations as stereotype properties. τ UML2 SRM materializes the second step described in section 2. In our case, τ UML2 SRM is a manual transformation which uses one UML input model to produce one UML SRM output model. On the other hand, the τ transformation automatically transforms the source platform instance model (i.e. a multitasking model) into a target platform instance model. As platform model libraries are described with the same set of metamodels (i.e. UML and the SRM profile), one way to achieve a platform-based generative process is to reduce τ transformation implementation to a one-to-one endogenous copy process. Figure 4 gives an example of such an algorithm for the UML metamodel. From an instance (i.e. an InstanceSpecification in UML) of a source platform resource (i.e. a classifier in UML), τ produces an instance of a target platform resource which is said to be equivalent. τ defines an equivalent operator for comparing stereotyped elements and guiding the generation process. One implementation of such operator is based on both the stereotype applied and the values of stereotype properties. In Figure 5, for example, we define the BasicTask concept as equivalent to the Process concept because the stereotype schedulableResource is applied to both and the arrivalPattern and the isPreemptable tags have equal values. More sophisticated equivalence policies can of course also be implemented. The algorithm and the equivalent operator make the τ transformation only dependent of the UML metamodel. In fact, the transformation is independent of the UML profiles used to describe the platform. In this specific case, the τ transformation is therefore generic for any profile dedicated to platform modeling which uses the “Resource-Service” pattern. the
UML Metamodel
Source Platform Model Library
1
UML Metamodel + SRM
UML Metamodel + SRM
Source Platform Model Library
Target Platform Model Library
« import »
« import »
Source platform instance model
UML Metamodel
Target Platform Model Library
1 Legend:
Target platform instance model
2
Set of source model (S) Set of target model (T) Conforms to Transformation
Figure 3. Explicit platform-based framework 01. 02.
For each UML!InstanceSpecification do if its classifier isStereotyped() then
03.
- generate a new Instance Specification;
04.
- its target classifier is the one which is
05.
equivalent to the source classifier in the target
06. 07. 08.
platform; endif
a periodic interrupt resource associated with a counter (i.e. a timer resource). For each period of the timer, the alarm activates the task. The timer is parameterized with the cycleTime of the alarmParameter. The task is thus activated periodically. The collaboration is then stereotyped with the SRM profile to clarify its taxonomy (periodic schedulable resource). Finally, stereotype attributes reference the property of the collaboration part types. For example, the period of the periodic schedulable resource is in fact the cycleTime of the Autostart data type. « modelLibrary » ARINC-653 « schedulableResource » arrivalpattern = periodic priorityElements = [ARINC-653::ProcessAttribute::basePriority] periodElements = [OSEK/VDX::ProcessAttribute::period]
endFor
Figure 4. Transformation algorithm « schedulableResource » arrivalPattern = aperiodic isPreemptable = true
« schedulableResource » BasicTask
« memoryPartition » Partition
0..*
« schedulableResource » arrivalPattern = aperiodic isPreemptable = true « schedulableResource » Process
Figure 5. Conceptual equivalence example
3.3. Overview of a transformation case study
We will now illustrate our transformation process for porting a specific basic ARINC-653 multitasking application to an OSEK/VDX-OS platform. ARINC653 is a multitasking standard for avionics platforms. ARINC-653 is the source platform; OSEK/VDX-OS is the target platform. 3.3.1. Platform modeling We begin by modeling the source and target platforms. These platforms are modeled as UML model libraries. Figure 6 depicts a part of the ARINC653 model library applying SRM. Figure 7 shows part of the OSEK/VDX-OS library. ARINC-653 provides natively a periodic schedulable resource (a Process), whereas the OSEK/VDX-OS provide an aperiodic resource (a BasicTask). Yet we know that the transformation τ is a one-to-one transformation. We therefore need to refine our output OSEK/VDX -OS model. To do so, we describe a design pattern for implementing periodic schedulable resources with aperiodic ones. Figure 8 illustrates use of a UML collaboration to describe a periodic design pattern with OSEK/VDXOS native concepts. Each part of the collaboration is typed with an OSEK/VDX-OS resource. The alarm is
« schedulableResource » Process
processes
attribute : ProcessAttribute « dataType » ProcessAttribute basePriority : Integer period : Integer
Figure 6. Relevant part of the ARINC-653 model « modelLibrary » OSEK/VDX-OS
« schedulableResource » arrivalPattern = aperiodic priorityElements =[OSEK/VDX::Alarm::priority]
« schedulableResource » BasicTask
0..*
priority : UINT32
« dataType » AutoStart cycletime : UINT32
« alarm » Alarm
alarm
autostart : AutoStart 0..*
counter
« swTimerResource » Counter
Figure 7. Relevant part of the OSEK/VDX model « schedulableResource » arrivalPattern = periodic periodElements = [OSEK/VDX::AutoStart::cycletime] priorityElements =[OSEK/VDX::BasicTask::priority] « schedulableResource » PeriodicBasicTask task : BasicTask [1]
alarm : Alarm [1]
alarmParameter : AutoStart [1]
timer : Counter [1]
Figure 8. OSEK/VDX periodic task design pattern
3.3.2. Source Platform instance modeling The design model for our case study is very basic: a periodic 50 ms task within a memory partition. Model is then described as a set of instances of the ARINC653 classifiers. The user manually imports the ARINC653 model library and instantiates a partition p1, a process t1 and a process attribute t1Attr in Figure 9. ARINC-653 instance model « modelLibrary » ARINC-653
p1 : Partition
« import »
t1 : Process
t1Attr : ProcessAttribute basePriority = 1 Period = 50
attribute = t1Attr
Figure 9. Basic multitasking application 3.3.3. Target instance model generation The algorithm described previously in Figure 4 has been extended to cope with collaboration. The transformation searches for collaboration in the source model. In our case, there is no collaboration in the source platform, thus any instances collaborate implicitly and the transformation computes instances separately. The p1 element is not transformed because there is no memory partition concept in the target platform. The t1 instance is transformed by instantiating the design pattern that we introduced in Figure 8 for a periodic task. For each part of the collaboration, an instance is generated in the target model and values are assigned to referenced properties. For example, the priority of the t1Task is valued because it is referenced in the source and the target schedulableResource stereotypes.
« modelLibrary » OSEK/VDX-OS
« modelLibrary » OSEK/VDX-OS instance model t1Task : BasicTask
t1Alarm : Alarm
priority = 1 « import » t1AlarmParameter : AutoStart cycletime = 50
t1Timer : Counter
Figure 10. Generated OSEK/VDX-OS application
4. Results and discussion
The transformation process described above concerns a basic multitasking case study. This process relies on the feasibility of describing platforms with a common language which, in our case, is the UML SRM profile. The following paragraphs describe the results of platform modeling with such a pivot language and then further discuss the transformation process.
4.1. Platform modeling results In section 2, we outline the modeling capabilities of the SRM profile and its use for describing parts of platforms. We did not, however, demonstrate its suitability for modeling completely differing multitasking platforms. The present section is thus concerned with various experiments performed by us to describe different multitasking execution platforms with SRM. This involved modeling three platforms, i.e. the ARINC-653, OSEK/VDX-OS, and RTAI [12]. RTAI is an extension of the Linux specification for hard real-time (RT) applications. Our experiments concentrated on structural and behavioral features modeling. All the platforms were therefore modeled with the UML class diagram. Resources were modeled as classes, resource properties as attributes and resource services as operations. Figure 11 shows the percentage of resource modeling coverage. Platform resources which are not stereotyped are indeed dedicated to: - system timing resources (e.g., clock resource) - fault tolerance concerns (e.g., hook routine) - platform managers (e.g., boot manager) All these concept families have not yet been considered in the SRM profile. To fill this gap, the user can either extend the existing UML SRM to describe the missing resources or he can describe new profiles applied jointly with the existing SRM profile. The Time profile provided in MARTE can be used for clock resource modeling for example. As inputs for our transformation scheme, one important feature of such profiles is that they use the “Resource-Service” pattern. The UML Time profile of MARTE uses such a pattern. Figure 12 illustrates the resource property modeling issue. Our goal here was to measure SRM capacity for describing stereotyped resource characteristics. Unlike resource modeling, SRM resource property modeling was poor for two reasons. The first relates to the SRM profile, which failed to describe key characteristics such as the maximum number of resource instances. We reported these inadequacies to the OMG for correction in the next release of MARTE. The second reason was the heterogeneous nature of platform resources. A platform provides similar concepts for concurrent execution, interacting and resource management. It does not provide the same implementation of these concepts. To cope with their heterogeneity in case of model transformation, we ask to the user default values for each resource property whose lowest multiplicity is not null. Figure 13 illustrates the resource service modeling coverage. ARINC-653 and OSEK/VDX are well modeled with the UML SRM Profile. Services which are not described in the RTAI platforms are mostly
dedicated to multiprocessors and distributed applications. Such domains are not considered in the SRM profile yet.
Percenatge of stereotyped resources
100% 90% 80%
92% 80% 73%
70% 60% 50% 40% 30% 20% 10% 0% ARINC-653
OSEK/VDX-OS
RTAI
Multitasking platforms
Figure 11. Resource modeling coverage Percentage of properties described with SRM
70%
66%
63%
60%
55%
50% 40% 30% 20% 10% 0% ARINC-653
OSEK/VDX-OS
RTAI
Multitasking Platforms
Figure 12. Resource property modeling coverage Percentage of services described with SRM
100%
96%
96%
90% 80%
65%
70% 60% 50% 40% 30% 20% 10% 0% ARINC-653
OSEK/VDX-OS
RTAI
Multitasking Platforms
Figure 13. Resource service modeling coverage
4.2. Transformation process A prototype of the platform-based framework that we propose has been implemented using ATL [5]. It includes collaborating resource instance detection, the basic equivalence algorithm described previously and
the instantiation of collaborations. Such transformation currently affects only structural UML models (e.g. class diagram). Achieving a generic transformation to port any platform-specific source model to any platformspecific target model is unrealistic. Nevertheless, making parts of the transformation independent of the platforms and then merge them with specific platform rules is a more realistic objective. For example, as platforms models are at the front end of the generative process in the previous example the transformation description is reusable for platform modeled with the common primitive types (e.g., the Integer primitive type). These are not, however, truly perfect examples, since the meaning of a value in the source platform may not be the same as the same value in the target platform. A typical case of this is the priority value. Consider, for instance, a source platform in which a priority valued 0 is the highest priority versus a target platform in which 0 may be the lowest priority. This is a hindrance to our generic transformation approach in which priority are valued in the same way. In fact, priority is not currently a common integer. It is a specific primitive-type bounded value with a minimum and maximum. In the target platform, 0 is the maximum value. In our framework, transformations of basic primitive-type values (e.g., boolean, integer and string) have been implemented. For specific primitive-type cases such as priority, the user needs to describe how the value is transformed in a specific transformation description. This doesn’t involve considerable work. In our first experiment, for example, basic primitive value matching rules (i.e., for integer to string, string to boolean) are basic declarative rules. They represent only 6 % of the whole transformation code lines. The remaining 94% of the transformation description is therefore generic. The τ transformation is a combination of generic and specific rules. A model of specific primitive-type transformation rules must be provided along with the generic transformation rules. On way to increase generic parts in the transformation description is to describe completely the source and target platforms. In this case, the transformation is said to be total. As shown in the previous sub-section, SRM is not exhaustive, but it can be extended. In any case, inclusion of all multitasking concepts in a single platform metamodel is an unrealistic goal. It is, however, possible to use multiple platform metamodels jointly. We suggest using several metamodels, each with a single concern (e.g., one for time and one for fault tolerance). As the algorithms for the τ transformation is independent of the UML profile used to describe platforms, it can thus be said
that the current already manages multiple platform metamodels as input. Since the transformation algorithm is based on equivalences between stereotype applications, we determined what percentage of resources is commonly stereotyped between two platforms without considering collaboration descriptions. To do so, we eliminated from our results any resources that were not stereotyped. Figure 14 illustrates for each pair of platforms the percentage of stereotyped resources. Firstly, these results reflect the worst case transformation productivity. From each result we can determine the worst case number of resource transformation rules that can be deduced from our approach (i.e. generic rules). For example, at least 50 % of the structural description of an OSEK/VDX-OS application can be expected to be generated from an ARINC-653 platform, which means that our generic τ transformation cannot deduced the matching rules for each source instance to a target instance. This is not due to the SRM profile but instead to platform heterogeneity per se. ARINC-653 namely provides communication concepts that are not matched by the OSEK/VDX-OS platform (e.g., message communication resources). In such cases, users must either describe specific transformation rules merged with the τ transformation or model collaborations of native OSEK/VDX-OS concepts to refine the source model and then use the τ transformation. Secondly, surprising percentages were obtained for the ARINC2RTAI and RTAI2ARINC transformations: these proved to be unequal. Again, the problem was not the SRM profile but the way it was used. In the RTAI library, multiple concepts have been annotated with the same stereotype. For example real-time RTAI signals and RTAI message queues were identified as both communication resources. Hence, equivalence UML Metamodel + Platform Metamodels
UML Metamodel
« import » « constraints » Each stereotype is used only once
Legend:
73%
70% 60%
50%
50%
50% 40% 30% 20% 10%
Source platform instance model
TA I2 R
SE K RT AI 2O
AR IN C
TA I 2R SE K O
AR IN SE K2 O
AR I
AR IN
NC
C 2O
2R
SE
TA I
C
0%
Transformation metamodel
UML Metamodel + Platform Metamodels
UML Metamodel
Target Platform Model Library
Target Platform Model Library « import »
« import »
target platform design pattern model
« constraints » Each stereotype is used only once
« import »
Set of source model (S) Set of target model (T)
64%
63%
Finally, based on the above results and discussion, we have now refined our transformation scheme. Figure 15 illustrates the complete transformation framework that we propose. It requires constrained platforms models, source instance platform models, design pattern models (i.e. collaboration models) and platform specific matching rules.
Specific matching rules
« import »
80%
Transform ations
« import »
Source platform design pattern model
88%
90%
Figure 14. Comparisons of equivalent stereotyped elements
Source Platform Model Library
Source Platform Model Library
100%
K
Percentage of equivalent stereotyped elements
matching was no longer one-to-one and the transformation was no longer deterministic. To cope with such cases, we add a new step to our transformation process to select candidates annotated in the same way. We thus produce as transformation inputs a platform model in which SRM stereotypes were used only once. Their selection is currently manual in our framework. Nonfunctional annotations (e.g., memory footprint or worst case execution time) and QoS-required characteristics can guide this choice.
Target platform instance model
Conforms to Transformation UML to UML Platform Metamodels transformation
Figure 15. Explicit platform-based transformation framework
5. Conclusions and future research
In current MDE practices, one problem is that platform models are implicitly described in the transformation description. As a result, transformation is a “mixture-of-concerns”. This leads to generative processes which are difficult to maintain and reuse. We therefore proposed to explicitly model such platforms and provide a framework for transforming applications relying on the platform models. In this paper we have focused on multitasking execution platforms. Our approach first focused on a multitasking execution platform language: the UML Software Resource Modeling profile. This profile is part of the new UML standard profile for Modeling and Analysis of Real-Time Embedded systems (MARTE). The main advantage of using the SRM profile is that it is not a new multitasking API, but instead a standard framework for modeling existing multitasking platform APIs. It is therefore based on a standard-specific “Resource-Service” pattern for platform modeling. We then proposed a transformation scheme for integrating explicit platform models relying on the “Resource-Service” pattern. This scheme is based on both a one-to-one endogenous copy process and a common platform metamodel for describing source and target platforms. The results of our initial experiments showed that platform modeling was feasible with specific platform metamodels and that not only source and target platform models but also design pattern descriptions and platform specific matching rules were necessary upstream of the generative process. These enable a more efficient separation of concerns and thus a more reusable transformation framework. Resulting input models are also reusable. "Zoos" of platform models and design patterns thus become a real possibility. Future research will improve this platform-based transformation approach. Efforts will thus center on more sophisticated equivalence policies between platform resources in order to take in account non functional annotations (e.g., memory footprint or worst case execution time) and QoS-required characteristics. Such information will guide the generative process.
6. References
[1] CEA, I-Logix, Uppsala, OFFIS, PSA, MECEL, ICOM, “UML -based methodology for real- time embedded systems”, version 1.0, April 2003, Project IST 10069 AIT-WOODDES. [2] S. Graf, and I. Ober, “A real-time profile for UML”. STTT, Software Tools for Technology Transfer, April 2006, pp. 113–127. [3] Object Management Group, “UML Profile for Schedulability, Performance, and Time”, Object Management Group, Inc., 2005. OMG document: formal/05-01-02. [4] Object Management Group, “MOF 2.0 Query/Views/Transformations RFP”, Object Management Group, Inc., September 2007, OMG document ptc/200707-07. [5] F. Jouault and I. Kurtev, “Transforming Models with ATL”, Proceedings of the Model Transformations in Practice Workshop at MoDELS 2005, Montego Bay, Jamaica, October 2005, pp. 128-138. [6] Object Management Group, “Unified Modeling Language : Superstructure (version 2.1.1)”, Object Management Group, Inc., Needham, MA 02494, February 2007, OMG document number: formal/2007-02-05 [7] Object Management Group, “A UML Profile for MARTE (version beta 1)”, Object Management Group, Inc., Needham, August 2007, OMG document number: ptc/0708-04. [8] F. Thomas, S. Gérard, J. Delatour and F. Terrier , "Software Real-Time Resource Modeling", Forum on Specification and Design Languages (FDL) 2007, ECSI, Barcelona, Spain, September 2007, p.231-236. [9] The Open Group Base Specifications, “Portable Operating System Interface (POSIX)”, ANSI/IEEE Std 1003.1, 2004. [10] The OSEK/VDX Group, “OSEK/VDX OS specification”, OSEK/VDX Group, Inc., Version 2.2.3, http://portal.osek-vdx.org/files/pdf/specs/os223.pdf, 2005. [11] The Airlines electronic engineering committee, “Avionics Application Software Standard Interfac - ARINC Specification 653-1”, Aeronautical radio, Inc., Annapolis, Maryland, USA, October 2003 [12] RTAI 3.1 Documentation Page, http://www.rtai.org/ [13] J. Bézivin, S. Bouzitouna, M. Didonet Del Fabro, M. Gervais, F. Jouault, D. Kolovos, I. Kurtev and R. Paige, “A Canonical Scheme for Model Composition, Model-Driven Architecture”, ECMDA-FA 2006, LNCS 4066, SpringerVerlag, July 2006, pp. 346-360 [14] J. M. Küster, R. Heckel and G. Engels, “Defining and Validating Transformations of UML Models”, Proceedings of the 2003 IEEE Symposium on Human Centric Computing Languages and Environments, HCC. IEEE Computer Society, Washington, DC, October 2003, pp.145-152. [15] Bran Selic, "On Software Platforms, Their Modeling
with UML 2, and Platform-Independent Design", Eighth IEEE International Symposium on Object-Oriented RealTime Distributed Computing (ISORC'05), Seattle; USA, May 2005, pp. 15-21.
