Formal Behavioral Modeling of Real-time Operating Systems

C´edrick Lelionnais

, Matthias Brun

, J´erˆome Delatour

, Olivier H. Roux

and Charlotte Seidner

ESEO-TRAME, 4 Rue Merlet de la Boulaye, B.P.30926, 49009 Angers cedex 01, France

LUNAM Universit´e, IRCCyN-Ecole Centrale de Nantes, 1 Rue de la Noe, B.P.92101, 44321 Nantes cedex 03, France

Keywords:

Model Driven Engineering, Real-time Operating Systems, Behavioral Modeling, Formalization, Time Petri

Nets, Application Deployment.

Abstract:

Faced with the growing problems of complexity, heterogeneity and upgradability of Real-Time Embedded

Systems (RTESs), model-based frameworks dedicated to the application deployments facilitate the design and

the development of such systems. Within these frameworks, taking into account the Real-Time Operating

Systems (RTOSs) has become essential. These frameworks include transformation tools able to generate a

code that is portable to the speciﬁed RTOS. Moreover, certain tools can generate formal models that are used

for the veriﬁcation and validation of the RTESs. However, the RTOSs technological concepts are considered

in an implicit way, which involves a lack of genericity of the transformations. Some works have focused on

the explicit description of the RTOSs. Such a description offers the possibility to take into account a model

entirely dedicated to a targeted RTOS as a parameter of the transformation. Nevertheless, this method does not

allow to verify the expected properties on the application, since the RTOSs behavior is not observable. The

methodology presented in this paper tends to explicitly consider the formal description of the RTOSs behavior

during an application deployment. This approach aims both at making each transformation generic and at

verifying the deployment correctness.

1 INTRODUCTION

Nowadays, Real-Time Embedded Systems (RTESs)

increasingly surround us in various domains (air-

crafts, automotive, cell phones, robotics...). RTES

engineers are confronted with the challenge of de-

veloping more complex, higher quality systems, with

shorter development cycles at lower costs. Within this

context, reuse, maintainability and portability have

become major issues in RTES design processes.

From this point of view, some frameworks have

been developed with the aim of generating code.

Starting from a detailed model written in such a lan-

guage as AADL (Society of Automotive Engineer

(SAE), 2004) or UML (Object Management Group

(OMG), 2007b), the speciﬁc code for the deployment

of an application on a Real-Time Operating System

(RTOS) is then generated. These code generating

frameworks are generally used after some Veriﬁcation

and Validation (V&V) activities have been performed

on the models. In this way, some research works have

dealt with the transformation of those models into for-

mal models, using such formalisms as Time Petri Nets

(TPNs) or Finite State Machines (FSMs)...) as prese-

nted for instance in (Renault et al., 2009) (Berthomieu

et al., 2010).

However, the correctness of the application de-

ployed on the RTOS is not veriﬁed during these V&V

activities. It is therefore difﬁcult to ensure that the

generated code effectively corresponds to what was

designed. Moreover the consideration of the RTOSs

is often embeded within the processus of generation

(or seen in simpliﬁed terms). This approach is then far

from ﬂexible since each translation must be adapted in

accordance with the targeted RTOS. Due to the signif-

icant number of existing RTOSs, this results in having

to maintain a large amount of translations.

In consequence, this paper relates to the following

issues. Which methodology should be adopted in or-

der to both deploy an application on a targeted RTOS

and check the correctness of such a deployment? Is

it possible to consider any RTOS during the deploy-

ment? (and if so, how?) How can the behavior of

any RTOS be described within such frameworks? To

bring an answer to these questions, a method has been

experimented to take these factors into account within

a single framework. The basic idea is to add the for-

mal description of any RTOS. Each description can

407

Lelionnais C., Brun M., Delatour J., H. Roux O. and Seidner C..

Formal Behavioral Modeling of Real-time Operating Systems.

DOI: 10.5220/0004156204070414

In Proceedings of the 14th International Conference on Enterprise Information Systems (MDDIS-2012), pages 407-414

ISBN: 978-989-8565-11-2

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

then be considered as a parameter of the transforma-

tion, so as to keep the framework generic. Lastly, this

formalization should let V&V tools able to verify the

correctness of such deployments.

This paper is divided into the following sections.

Section 2 presents some works in conjunction with

the issues described above. As a result of that re-

search, the approach adopted is developed in Sec-

tion 3. It has proven the need to consider the behav-

ior of RTOSs during a deployment of an application.

Then Section 4 presents the strategy proposed to for-

mally take into account the behavioral description of

RTOSs. Consequently the beneﬁts and the limits of

the strategy are showed in Section 5 and discussed in

Section 6. Finally we conclude in Section 7.

2 RELATED WORK

2.1 Code Generating Frameworks

Code generating frameworks are used in a context of

application deployment. Code generation is the pro-

cess of transforming code from one representation to

another one. Often, this is from a higher level, such as

an UML diagram modeling an application, to a lower

level, such as a C code program that is portable to an

execution software platform.

From a real-time point of view, code generating

frameworks are used in a context of application de-

ployment to a speciﬁc RTOS. The information con-

cerning RTOSs are given in a program which im-

plements the deployment. For instance, Ocarina de-

scribed the information of a middleware with Ada

code in its Gaia generator (Vergnaud and Zalila,

2006).

Similarly, the Real-Time Workshop (RTW) tool

(The MathWorks, 2007) uses templates catching both

technological concepts of the RTOS and program-

ming language information. These templates struc-

ture the source code to generate.

As a result, these frameworks involve an implicit

description of the RTOSs during the processus of gen-

eration. This raises the problem of genericity of these

frameworks since each deployment corresponds to a

unique code generator.

2.2 RTOSs Modeling

In order to describe the Operating Sytems (OSs) con-

cepts, some model-based frameworks have been de-

veloped. Some works have focused on both structural

and behavioral aspects of the OSs. Revolving around

these two axes, the description of the OSs is made ex-

plicit and observable through formal models. Explicit

means that such a description is entirely dedicated to

the representation of the OS.

Metropolis (Team, 2004) uses formal languages

such as the Linear Temporal Logic. It offers the pos-

sibility to verify some properties of an application de-

ployed on a wide range of OSs.

Generic Modeling Environment (GME) (Davis,

2003) contributes to the description of OSs which

are not necessarely real-time and analysis platforms.

GME proposes assistance tools for the migration from

one OS to another. In addition, this environment of-

fers the possibility to insert formal metamodels. The

descriptions thereby made can be used by V&V tools.

Nevertheless, the genericity of the modeling lan-

guages used within these frameworks does not make

the modeling of platforms easier dedicated to a partic-

ular domain, such as the real-time domain, any easier.

More speciﬁcally to the RTESs, Ptolemy (Lee,

2003) is a framework which describes execution mod-

els. Most of these models support the actor-oriented

design focused on the concurrency and the communi-

cation between the components of a RTES. However,

the concepts of structural representation from this ap-

proach are only intended for the applications model-

ing, but not for RTESs themselves.

In spite of the fact that the OSs description is ex-

plicit, the works outlined above are less in line with

the RTESs. Furthermore, the separation of the con-

cerns does not clearly appear. This impacts on the in-

tervention of each domain specialist such as the appli-

cation or the OSs technology. The lack of genericity

previously noted arises once again.

Other researches have led to consider the de-

scription of RTOS during the application deployment.

This approach relies on a Model Driven Engineer-

ing (MDE) context. MDE promotes the distinction

of platform-speciﬁc modeling artefacts from those

that are platform-independent. The platform (RTOS)

model is considered as a parameter of this deploy-

ment. Each model is described by a modeling lan-

guage. Concerning the RTOS modeling, we can note

the Software Resource Modeling (SRM) (Thomas

et al., 2008) package which is a MARTE’s UML

proﬁle (Object Management Group (OMG), 2007a).

With SRM, RTOSs can be modeled using stereotyped

concepts from the real-time software domain.

For another example, RTEPML (Real-Time Em-

bedded Platform Modeling Language) (Brun and De-

latour, 2011) was developped with the aim of deﬁning

concepts dedicated to the real-time domain for mod-

eling RTOSs.

Contrary to the ﬁrst noted frameworks, SRM

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

408

and RTEPML better separate the concerns previously

highlighted (RTOSs structure, transformations, de-

ployments choice...). Nevertheless, only the structural

aspect is taken into account with these modeling lan-

guages. The behavior resulting from the concurrent

activities of the RTESs components is not observable

in the deployed application models. As a result, no

V&V activities can be applied to check the correct-

ness of such a deployment.

3 APPROACH ADOPTED

The previous section showed the interest to well dis-

tinguish the concerns for the intervention of each spe-

cialist for real-time applications deployment. In addi-

tion, it has been raised to explicitly consider the de-

scription of the RTOSs behavior within a code gen-

erating framework. Our approach relies therefore on

the extension of a model-basedframeworkto formally

observe the behavior of a deployed application on a

RTOS. This should add other concerns such as the

RTOSs behavior and some V&V activities on the de-

ployment at design phase.

As a result, we have chosen the RTEPML frame-

work as it has been developed within our team. In

addition this modeling language already contributes

to the explicit description of the RTOSs. However,

the behavioral aspect of RTOSs can not be modeled

with RTEPML. Therefore modeling behavior with

RTEPML means extending this language. That is why

we have sought to enrich it in order to deﬁne behav-

ioral concepts of RTOSs.

3.1 RTEPML with MDE

Based on the MDE initiative, the application deploy-

ment emanates from semi-generic transformations of

models. MDE is based on an architecture (Model

Driven Architecture (MDA)) (Object Management

Group (OMG), 2001) (see Figure 1) involving a de-

sign process where a Platform-Independent Model

(PIM) (description of the application without consid-

ering the platform) is transformed into a Platform-

Speciﬁc Model (PSM) (description of the application

deployed on the platform), according to a Platform

Description Model (PDM) (description of the plat-

form). Each model conforms to a modeling language,

also named metamodel.

In accordance with Figure 1, RTEPML is a meta-

model which has been built to model PDMs. The

concepts of the targeted RTOS are then deﬁned by

a PDM. So far, the modeling with RTEPML goes

through the structural characterizations (resources

Figure 1: MDA principle.

and services) of RTOSs. The resources represent the

concepts offered by the platform. For instance, in a

RTOS, the tasks, the semaphores, the mailboxes are

considered as resources. The services are offered by

the resources and caught at API’s level (Application

Programming Interface). For example, services asso-

ciated with semaphores are the take and release prim-

itives.

Consequently, in conjunction with this approach,

the deployment consists both in instantiating RTOS

resources and in using RTOS call services for imple-

menting the application. Then the generated PSM is

provided for a code generation process. Finally, it is

worth noting that the transformationserving to the de-

ployment is generic thanks to the explicit considera-

tion of the RTOSs.

3.2 Illustration around Semaphore

Sharing

We have mentioned the idea to extend RTEPML at the

beginning of this section. This extension should en-

able to consider the RTOS behavior during an appli-

cation deployment. To illustrate this behavioral lack,

a deployment is presented Figure 3

based on an

example of Robot application (see Figure 2). Obvi-

ously several concepts instantiations of the considered

RTOS are possible following the application. Accord-

ingly, this illustration is focused on a particular case :

the semaphore sharing.

In this way, the PIM representing the robot ap-

plication combines two periodic activities (a Driver

activity for driving the robot and a Vigil activity for

avoiding barriers). On the one hand, the Driver in-

The languages used in Figures 2 to 5 come from the

graphic description of each metamodel (their concrete syn-

tax).

FormalBehavioralModelingofReal-timeOperatingSystems

409

Figure 2: Model of a robot application.

vokes a Moving Strategy program. On the other hand,

the Vigil invokes a Barrier Bypass Strategy program.

Then two wheels allow the robot to move thanks to

two settings updated according to the activities. Fi-

nally each periodic activity owns a priority according

to its role.

The PDM described by RTEPML for this deploy-

ment is a model of the nxtOSEK’s RTOS (nxtOSEK,

2009). nxtOSEK is based on OSEK/VDX standard

(OSEK/VDX Group, 2005) and is widely used in

LEGO MINDSTORMS NXT educational projects.

According to our needs, some resources havebeen de-

ﬁned to be instantiated with regards to the application.

The Task concept is instantiated to represent each ac-

tivity, the Function concept to execute each program

and the Resource (semaphore concept in nxtOSEK)

concept to protect each wheel setting updating.

The PSM results in a model of the application de-

ployed on the nxtOSEK platform. However the con-

current activities which are governed by both appli-

cation and technological concepts do not concretely

appear in the ﬁnal model. For instance we do not

know whether each Resource (protection for updating

each wheel setting) is available or not (empty or full).

Moreover the state in which each Task (the Driver

and the Vigil T) is set cannot be clearly distinguished.

Finally the impact of the properties such as the prior-

ity and the period ofthe tasks is not directly veriﬁable.

Consequently this illustration shows how difﬁcult

it is to interpret the behavior of the resources instan-

tiated. The behavioral aspect of the generated model

is not observable. In this approach, it is therefore dif-

ﬁcult (if not impossible) to undertake some V&V ac-

tivities to verify the correctness of the deployment.

In order to be able to check the properties on the de-

ployed application, formal behavioral aspects have to

be introduced within the description of the software

platform.

4 STRATEGY OF BEHAVIORAL

FORMALIZATION

In accordance to the previous conclusion, RTEPML

has been enriched to bring a behavioral aspect in the

RTOSs description. On this point, we have extended

the abstract syntax of RTEPML in which executive

concepts have been deﬁned to explicitly describe any

platform.

Once RTEPML extended (newly called

RTEPML

BEHAVIOR), the implementation of

a transformation process could have been put in

place to make the model of the deployed appli-

cation behavioral. To meet the requirements of

V&V activities, the formalization of the PSM is

necessary. RTEPML

BEHAVIOR has therefore been

designed to take into account any formal language.

This solution has been thought in order to make

the transformation independant of other formal

languages.

4.1 Behavioral Consideration

Taking into account the RTOSs behavior necessitates

the identiﬁcation of the behavior of each resource

(scheduling task, state of a semaphore...). The same

applies to the behavioral description of each service

offered by resources (task terminating, semaphore ac-

quisition...). Lastly, each behavioral impact associ-

ated with each resource property (task priority, task

period, semaphore tokens number...) should also be

treated during the deployment.

To keep on the previous focus, an example of be-

havioral consideration around the semaphore is de-

picted Figure 4. As explained earlier, some concepts

have been added in RTEPML

BEHAVIOR to repre-

sent the behavior of the RTOSs resources. Thus, the

behavioral prototype of the semaphore concept, called

ResourceBehavioralPrototype, has been deﬁned on

the Behavioral PDM. As a reminder, Resource (on

Behavioral PDM) represents the semaphore con-

cept of nxtOSEK RTOS, whereas ”Resource” is the

RTEPML BEHAVIOR metaconcept allowing to de-

scribe any RTOS resource. In other words, Resource

conforms to MutualExclusionResource.

The formalism used to express the behavioral pro-

totype is Time Petri Net (TPN) (see (Boyer and Roux,

2008) for a survey). TPNs have been prefered be-

cause of their expressiveness. This formalism is in-

deed adapted to the description of concurrency activ-

ities such as resources schedulability, resource shar-

ing, call services sequence, time constraints... Fur-

thermore, TPNs proposeknown time extensions (such

as stopwatch TPNs) which allow to model real-time

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

410

Figure 3: Robot application deployment.

schedulings implemented in V&V tools like Romeo

(Gardey et al., 2005) (Lime et al., 2009) or Tina

(Berthomieu et al., 2004).

Figure 4: MER behavior.

As can be seen on Figure 4, a behavioral proto-

type can be composed of several behavior elements.

Indeed, a RTOS resource includes services and prop-

erties. The appearance of roles (deﬁned at meta-

model level) within the Behavioral PDM, enables to

precise certain behavior elements. In the nxtOSEK

semaphore case, serviceBehavioralDescription role

comes to describe the services behavior of getRe-

source and releaseResource, whereas deﬁnes role

comes to deﬁne the value of the semaphore.

4.2 Deployment with

RTEPML

BEHAVIOR

The behavioral description of RTOSs has been made

possible with RTEPML

BEHAVIOR. Moreover the

possibility to deﬁne formally the behavior elements,

contributes to the formalisation of the application de-

ployment. This important point should enable to ver-

ify its correctness before the code generation.

In accordance with the adopted approach, a trans-

formation has been developed to consider explicitly a

behavioral PDM of the targeted RTOS. We have taken

the same robot application from the previous section

to illustrate an example of formalisation of the de-

ployment (see Figure 5). For the sake of simplicity

and clarity, we have reduced the Robot PIM to the

Driver

T instance representing the periodic Driver

activity. Driver

T has an entry point on the Moving

Strategy in which only a service is called for termi-

nating itself.

The involved prototypes in the transformation are

those of the resources for the needs of the application.

Once the prototypes are detected, the latter are cloned

according to each instance of the application. It may

be observed that the cloned prototypes corresponding

to the behavior of the Driver

T and the Moving Strat-

egy (including the service of terminating) have been

composed through this example.

As a result, the TPN Behavioral PSM achieved is

more expressive than the previous one. Its expressive-

ness helps us to easily see its liveness (the different

states of Driver T, its periodicity...).

The composition of the building blocks repre-

sented by cloned behavioral prototypes (semaphore,

task, communication, priority...) make up the gener-

ated model. In TPNs case, the composition is car-

FormalBehavioralModelingofReal-timeOperatingSystems

411

Figure 5: Formalisation of robot application in TPN.

ried out by merging places interfacing all the blocks.

This presents some advantages. The semantics of the

places merging is obvious, while the one of the tran-

sitions merging is ambiguous. Indeed, the fact of as-

signing different time constraints on mergeable tran-

sitions makes their merging difﬁcult. In addition, the

places merging preserves the blocks behavior, which

enables to validate more easily the building.

In this paper, the purpose is neither to describe

exhaustively the modeling of the behavioral proto-

types and the composition of their clones, nor to prove

that it is correct. The aim is only to present the ap-

proach and the methodology which allows it. That is

why no proof of the building validity has been given.

Notwithstanding, this proof is greatly simpliﬁed by

our composition approach.

5 BENEFITS OF THE STRATEGY

The main beneﬁts of our methodology are both the

formalization and the moving of the application de-

ployment into the design phase. This should allow to

ensure its correctness before generating code. Bas-

ing our approach on MDE, a formalization of the de-

ployed application model can be carried out. V&V

activities will become applicable thanks to the use of

model-checking tools.

A second beneﬁt is the separation of the skills

highlighted in the second section. The distinction

of modeling artefacts allows both RTOSs behavior

and formal veriﬁcation experts to interact on the

application deployment (see Figure 6). Thanks to

RTEPML

BEHAVIOR, the specialist of the RTOSs

behavior can be assisted by the one more highly

skilled in the formal veriﬁcation. The latter one can

also interpret the most adapted formalism following

the case.

Figure 6: Intervention of specialists.

To put our strategy into practice, we have chosen

to verify a necessary and well-known condition in the

RTESs domain: the absence of deadlock. Once the

PSM generated in TPN, the formal model can be pro-

cessed by ROMEO (Gardey et al., 2005). ROMEO

has been developed within the Real-Time team at IR-

CCyN

lab. One of the reasons for choosing ROMEO

is that this tool is dedicated to Transition-TPN (T-

TPN) veriﬁcation, i.e. the time is only assigned to the

transitions. Algorithms were proposed for applying

veriﬁcation on T-TPN extended to scheduling.

Despite the combinatorial explosion risk of the

generated TPN, ROMEO has given a deadlock out-

come. This diagnosis could seem foreseeable from

the speciﬁcation since the wheels settings updating is

protected by semaphores. Notwithstanding, this veri-

ﬁcation helps us to evaluate the right protocol to use

http://romeo.rts-software.org

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

412

for this application. Indeed, the Priority Ceiling Pro-

tocol (PCP) (OSEK/VDX Group, 2005) should have

been chosen to remedy this situation during the de-

ployment.

We have exposed the deadlock case but other be-

havioral properties could have been tested. For in-

stance we could deal with liveness properties such

as termination of actions, occurency of expected

events... But we could also handle time constraints

such as Worst-Case Execution Time (WCET), respect

of a deadline...

6 LIMITS

This experimentation has showed the feasability of

generating a formal model to observe the behavior

of the application deployed on a RTOS. Nonetheless,

the behavior of some of concepts (the notiﬁcation re-

sources such as the events or the communication re-

sources such as the messages...) are not yet taken into

account within RTEPML

BEHAVIOR. As a result, an

optimization of the latter modeling language must be

widened in order to cover such concepts.

Another limit raised is the interpretation of other

formalisms to model the behavior during the deploy-

ment. Only TPNs have been presented through our

strategy but the implementation of other formal lan-

guages deserves to be examined.

Lastly, a deadlock has been detected during the

deployment. It has been deduced that the deploy-

ment was not correct. That being so, this decision

does not affect the correspondence between the ap-

plication and the targeted RTOS. Indeed, a proto-

col changement (Priority Ceiling Protocol (nxtOSEK,

2009) (OSEK/VDX Group, 2005)) is just sufﬁcient to

prove it. This leads us to say that the framework does

should integrate decision support tools for guiding the

experts involved in the RTOS choice.

7 CONCLUSIONS

Through this study, a methodology has been pre-

sented to consider the behavior of a real-time execu-

tion software platform (RTOS) during an application

deployment. The deployment which enables to im-

plement an application on a speciﬁc RTOS, has been

moved at design phase. The purpose of this choice

is to enable the different specialists to intervern more

easily on the deployment following its domain. In-

deed, thanks to the modeling with RTEPML and the

MDE approach, the separation of concerns (applica-

tion and RTOS) has been made explicit.

The description of the RTOSs behavior has

been made feasible by enriching RTEPML

(RTEPML

BEHAVIOR). In addition, each be-

havioral model can be formally described. A

transformation has been developed to generate a

formal model of the deployed application. The

formalization has the advantage of applying V&V

activities for checking the correctness of the deploy-

ment, even before generating the code useful to the

implementation of the application.

However, certain limits of our methodology have

arisen. Future prospects are the subject of our next

works to improveand to check the feasibility of such a

strategy. In accordance to the previous section, the be-

havioral concepts missing in RTEPML

BEHAVIOR

will have to be created. Then, to ensure the genericity

of the formalisation, other languages will have to be

interpreted. Finally, a large number of formal proofs

will have to be written within our framework. This

should contribute to the veriﬁcation of necessary and

sufﬁcient conditions for validating such deployments.

REFERENCES

Berthomieu, B., Bodeveix, J.-P., Dal Zilio, S., Dissaux, P.,

Filali, M., Gauﬁllet, P., Heim, S., and Vernadat, F.

(2010). Formal Veriﬁcation of AADL models with

Fiacre and Tina. In ERTSS 2010 - Embedded Real-

Time Software and Systems, pages 1–9, TOULOUSE

(31000), France. 9 pages DGE Topcased.

Berthomieu, B., Ribet, P.-O., and Vernadat, F. (2004). The

tool tina – construction of abstract state spaces for

Petri nets and time Petri nets. International Journal

of Production Research, 42(4).

Boyer, M. and Roux, O. H. (2008). On the compared ex-

pressiveness of arc, place and transition time Petri

nets. Fundamenta Informaticae, 88(3):225–249.

Brun, M. and Delatour, J. (2011). Contribution on the soft-

ware execution platform integration during an appli-

cation deployment process. First Topcased Day.

Davis, J. (2003). GME: the Generic Modeling Environ-

ment. In OOPSLA ’03: Companion of the 18th an-

nual ACM SIGPLAN conference on Object-oriented

programming, systems, languages, and applications,

pages 82–83, New York, NY, USA. ACM.

Gardey, G., Lime, D., Magnin, M., and Roux, O. H. (2005).

Rom´eo: A tool for analyzing time Petri nets. In 17th

International Conference on Computer Aided Veriﬁ-

cation (CAV’05), volume 3576 of Lecture Notes in

Computer Science, pages 418–423, Edinburgh, Scot-

land, UK. Springer.

Lee, E. A. (2003). Overview of the Ptolemy project. Tech-

nical Report UCB/ERL M03/25, EECS Department,

University of California, Berkeley.

Lime, D., Roux, O. H., Seidner, C., and Traonouez, L.-M.

(2009). Romeo: A parametric model-checker for Petri

FormalBehavioralModelingofReal-timeOperatingSystems

413

nets with stopwatches. In Kowalewski, S. and Philip-

pou, A., editors, 15th International Conference on

Tools and Algorithms for the Construction and Anal-

ysis of Systems (TACAS 2009), volume 5505 of Lec-

ture Notes in Computer Science, pages 54–57, York,

United Kingdom. Springer.

nxtOSEK (2009). NXTOSEK Operating System, version

2.10. http://lejos-osek.sourceforge.net/.

Object Management Group (OMG) (2001). Model

Driven Architecture (MDA) Guide, version 1.0.1.

http://www.omg.org/mda/.

Object Management Group (OMG) (2007a). UML Proﬁle

for Modeling and Analysis of Real Time and Embbe-

ded systems (MARTE), second revision submission.

http://www.omg.org/marte/.

Object Management Group (OMG) (2007b). Uniﬁed Model-

ing Language (UML) : Superstructure, version 2.1.2.

http://www.omg.org/mda/.

OSEK/VDX Group (2005). OSEK/VDX Operating Sys-

tem Speciﬁcation, version 2.2.3. http://www.osek-

vdx.org/.

Renault, X., Kordon, F., and Hugues, J. (2009). From aadl

architectural models to petri nets: Checking model vi-

ability. In ISORC, pages 313–320.

Society of Automotive Engineer (SAE) (2004). Architec-

ture Analysis & Design Language (AADL) AS5506,

version 1.0.

Team, M. P. (2004). The metropolis meta model - version

0.4. Technical Report UCB/ERL M04/38, EECS De-

partment, University of California, Berkeley.

The MathWorks (2007). Real-Time Workshop User’s

Guide. The MathWorks Inc., Natick, MA, USA.

Thomas, F., Grard, S., Delatour, J., and Terrier, F. (2008).

Embedded Systems Speciﬁcation and Design Lan-

guages, Selected Contributions from FDL’07, vol-

ume Embedded Systems Speciﬁcation and Design

Languages of FDL selected papers, chapter Soft-

ware Real-Time Resource Modeling, pages 169–182.

Springer, Barcelona, Spain, springer science+business

media b.v. edition.

Vergnaud, T. and Zalila, B. (2006). Ocarina, a com-

piler for the AADL. Technical report, Paris, France.

http://ocarina.enst.fr.

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

414