PATTERNS FOR TEMPORAL REQUIREMENTS ENGINEERINGA Level Crossing Case Study∗

A. Mekki1,2, M. Ghazel1,2 and A. Toguyeni1,3

1 Univ Lille Nord de France, F-59000 Lille, France2 INRETS, ESTAS, F-59666, Villeneuve d’Ascq, France

3 EC LILLE, LAGIS, F-59651, Villeneuve d’Ascq, France{ahmed.mekki, mohamed.ghazel}@inrets.fr, armand.toguyeni@ec-lille.fr

Keywords: Model Transformation, Time-Constrained System, UML State Machines, Timed Automata, Verification andValidation.

Abstract: This work presents a method for verifying temporal requirements of time-constrained systems. The methodpredates by establishing a new time constraints (properties) taxonomy. Then, a basis of observation patternsrelative to the predefined requirements is developed. Our approach allows the automated verification of tem-poral requirements, initially expressed in a semi-formal formalism, through model transformation and model-checking. The contributions of the paper are: the definition of a new time constraints (properties) typologyas well as a basis of appropriate State Machines (SM) observation patterns. The second contribution consistsin developing an algorithm for transforming UML SM with time annotations into Timed Automata (TA). Inpractice, in order to verify the temporal aspects of a given specification, the observation patterns relative tothe investigated properties are instantiated to make appropriate observers. Then using our transformation al-gorithm, the system specification (denoted in the shape of an UML SM model) with time annotations as wellas the obtained observers are translated into TA models. The TA system model is next synchronized with theTA observers. Thereby, the verification process is reduced to a reachability analysis.

1 INTRODUCTION

Given their practical implication on safety and cor-rectness of critical applications (e.g. transportationsystems, nuclear plants), specification and verifica-tion are one of the most important research topics incritical systems engineering since such kind of sys-tems must achieve a high level of robustness and relia-bility. In addition, these systems usually involve time-dependent functionality. Consequently, methods forbehavior modeling and verifying (especially temporalrequirements) are increasingly important. The mostused approaches for specifying timed systems arebased on Timed Automata (TA). TA are well suitedfor expressing timed behavior and for modeling real-time components. A number of automatic verificationtools for TA have been developed and have proven tobe efficient e.g., Uppaal (Larsen et al., 1997) and Kro-nos (Yovine, 1997). Nevertheless, specifying and ver-

∗This research has been partially supported by Rgion Nord Pas de Calaisand European fund Feder under the FUI National project FerroCOTS, la-belled by i-Trans.

ifying time constraints is becoming a more and moredifficult task due to the widespread applications andincreasing complexity of checked systems. Despitethe different advantages proposed by TA, such as par-allel composition, users often need to manually ex-press the time properties into a set of clock variableswith complex calculated clock constraints. This pro-cess is tedious, error-prone and requires sophisticatedlogical and/or mathematical skills.

On the other hand, in order to cope with the com-plexity of critical systems engineering, approachesbased on Model Driven Engineering (MDE) seemsto be very useful (Schmidt, 2004). The aim of thiswork is to introduce a new temporal requirements’verification method based on MDE. First, we definea Patterns’ Basis for monitoring time constraints. In-deed, based on a new time constraints’ classification,we developed a set of time observation patterns ex-pressed in Unified Modeling Language (UML) StateMachines (SM)(UML, 2009): this is expected to be arelatively inexpensive activity since this procedure isdone once and for all. UML has been chosen since itis relatively intuitive, offers a graphic description, is

45

implemented by several tools and finally is a standardnotation well supported by the Object ManagementGroup. This set of patterns facilitates high-level sys-tem design. These patterns cover a large class of com-mon time constraints.

Since our aim is to keep a high precision level,a subsequent step consists in giving an accurate def-inition of each developed pattern. Hence, for eachpattern, we give (1) a textual definition, (2) an UMLSM model, (3) a structured English specificationand finally (4) a temporal logic expression (TimedComputational Tree Logic (TCTL)) relative to theproperty concerned.

Concretely, the verification process is based on theset of patterns. The suitable patterns correspondingto the time constraints extracted from the system re-quirements are picked up and instantiated. This in-stantiation step generates a set of SM Observers. TheSM observers are translated into more formal nota-tion, the TA, which provides support for the prop-erties’ verification. The translation is made accord-ing to a transformation algorithm that will be dis-cussed later in the paper. In this way, analyzers ex-ploit the benefits of formal notations without havingto go through the complex and expensive formal mod-eling phase. This transformation generates a set ofTA Observers. A system’s model, which is also gen-erated by the same transformation algorithm, is syn-chronized with the obtained TA observers to obtaina global model. Hence, the verification task is per-formed, on this obtained model, with a reachabilityanalysis while checking whether the observers’ for-bidden states - corresponding to constraints violation- are reachable.

The paper is organized as follows. In Section 2,we set the context and we briefly go through somerelated works. Section 3 describes our first contribu-tion by introducing the new time-constraints taxon-omy and the patterns basis. The second contributionof our method is outlined in Section 4 where the trans-lation from UML SM, with time annotations, to TAis described. The method is illustrated using a LevelCrossing (LC) case study in Section 5. Section 6 con-cludes the paper while drawing some future work.

2 CONTEXT AND BACKGROUND

2.1 Related Work

There are many recent research efforts in the fieldof time-constrained system validation. Only two ofthese research will be discussed in this section. First,based on the Dwyer (Dwyer et al., 1999) pattern basis,

Dhaussy (Dhaussy et al., 2009) defines a textual lan-guage, called ”CDL”, for requirement specification.The requirements are then translated into observer au-tomata. Furthermore, Dhaussy defines for each re-quirement a path, called ”context” where the require-ment should be checked. Finally, the system model,the observer automata and the context are translatedinto IF notation (Intermediate Format). Then, the ver-ification is carried out using the IFx tool. Second,Nascimento (Nascimento et al., 2009) presents an ap-proach for automatic generation of network of timedautomata from a functional specification depicted viaUML class and sequence diagrams. Nascimento usesUML sequence diagrams for the property specifica-tion phase. However, sequence diagrams suffer froma limited expressiveness when dealing with temporalaspects, since they only depict order.

Unlike the above methods, our approach uses TAas target notation; TA are assumed to be more expres-sive and well supported.

On the other hand, several projects have intro-duced natural-language-based approaches where nat-ural language is mapped into a more formal specifi-cation. (Dwyer et al., 1999) proposes several patternsapplicable to properties specification expressed in dif-ferent formalisms and logics such as LTL, CTL, GIL,and quantified regular expressions (QRE). (Konradand Cheng, 2005) proposes an extension to Dwyer’sclassification and real-time properties are added to theoriginal classification. Moreover, TCTL, MTL andRTGIL are used to specify the added real-time prop-erties.

Comparatively to the above-mentioned works, ourcontribution offers the following advantages:• Our method takes advantage of the flexibility and

expressiveness of UML SM in modeling tasks andthe precision of TA formalism in the verificationtasks, also UML SM are more expressive thanUML sequence diagrams or UML collaborationdiagrams used in other works,

• TA are well supported,• Patterns facilitate high-level specification and pro-

mote reusability and knowledge capitalization,• The verification task is reduced to a reachability

analysis, this allows us to overcome some limita-tions met with some existing tools, such as Up-paal.

2.2 Observer Technique

We deal with observer whenever we set artifacts towatch system behavior (Dong et al., 2008). Let usrecall here that the goal of our approach is to checkwhether the temporal requirements expected from a

ICINCO 2010 - 7th International Conference on Informatics in Control, Automation and Robotics

46

given system are satisfied. Hence, we make use ofobservers in order to express the satisfaction vs the vi-olation of the predefined requirements (Ghazel et al.,2009). Typically, checking a given temporal propertyconsists in examining whether the error state of thecorresponding observer is reachable.

3 OBSERVATION PATTERNS

In this section, we first propose a classification ofall the common temporal requirements one may meetwhen dealing with critical systems. Then, we developa structured English grammar that we use to expressthe predefined properties. Next, we introduce the pat-terns used in order to monitor the predefined temporalrequirements. Finally, a standardized description ofthese patterns is suggested.

3.1 Main Time-constraints

We strive to identify all the common requirementsone may meet when dealing with critical systems.The main identified requirements are defined and ex-plained in Table 1 (The relation which denotes that asystem S satisfies a requirement R is written S|=R)and also are depicted in the shape of a UML Classdiagram (Figure 1). This classification offers the ad-vantage that it deals with requirements on events only,since we used to express the requirements on statesusing two events: the first event represents the activa-tion of the state and the other the deactivation.

3.2 Structured English

To facilitate the expression and the formalization oftemporal properties, we have developed a structuredEnglish grammar. This grammar supports both quali-tative and quantitative properties. Each sentence gen-erated by our grammar describes a temporal propertyand serves as handler that helps expressing and under-standing the requirement. Our grammar is expressedbelow using BNF (Backus-Naur Form ) notation:

Property = {<Scope>: <Specification>};

Specification = {<Entity><Obligation>occur <Reference>} ;

Scope = Global |Before <Entity>|After <Entity>|Between<Entity>and <Entity>;

Entity = “Event” |“Active( State)” |“Desactive(State)”;

Obligation = must |cannot;

Reference = ((exactly at <time>over) |(After [a delay of <

time>over]) |(<Before [a delay of <time>over])) <Entity>;

Time = <Number>tu;

Number = <Digit>+ ;

Digit = {0|1|2|3|4|5|6|7|8|9} ;

Literal terminals are given in bold font, non-literalterminals are delimited by quotation marks (“ ”) andnon-terminals are given in italics. The start symbolof the grammar is property and the language L of thegrammar is finite, since the grammar is non-circularand has no repetitions.

3.3 Observation Patterns Basis

A pattern is a commonly reusable model in softwaresystems that guarantees a set of characteristics andfunctionalities. The identification of a pattern is basedon the context in which it is used. The goal behind de-veloping patterns is to offer a support for system de-sign and development. Using patterns helps in keep-ing design standardized and useful and minimizes thereinventing in the design process, since they facili-tate reusability and knowledge capitalization (Gammaet al., 1995).

In this work, we define a set of patterns whichwill serve as basis to generate observers for all theidentified temporal requirements. The notation usedis UML State Machines. The basis of patterns is in-troduced regardless the systems’ specification and isused to model all the common temporal requirementtypes that one may express. This pattern basis guar-antees the reusability and the genericity of the mech-anisms developed within our approach.

3.4 Pattern Formalization

We have introduced a new temporal requirement clas-sification that is used in implementing our patternrepository. Additionally, we include a graphical rep-resentation of each pattern in the shape of UML SMdiagram. This field will be used later as input modelto the model transformation phase. Each pattern inthe repository contains the following fields:

Pattern Name: The pattern name serves as a handlefor the pattern’s use and describes the type of thepattern.

Pattern Definition: A short description and defini-tion of the requirement for which the pattern isused.

Scoped Structured English Specification: Thescoped structured English sentence captures theinvoked property using the grammar definedpreviously. The scope, initially introduced byDwyer in (Dwyer et al., 1999), is used to expressthe applicability interval (scope) of the property.Four scopes are used in our grammar: globally,before an event occurs, after an event occurs andbetween two events.

PATTERNS FOR TEMPORAL REQUIREMENTS ENGINEERING - A Level Crossing Case Study

47

Table 1: Temporal Requirement’s Taxonomy Descriptions.

Class Category Pattern Name DescriptionQ

uant

itativ

e

QuantitativeAbsence

Forbidden Before

R ensures that an event (Emon) must never occur before a minimumTbe f ore (time unit over ERe f ). S|=R is true if this event does not occurbefore Tbe f ore.

Forbidden After

R ensures that an event (Emon) must never occur after a deadline Ta f ter

(time unit over ERe f ). S|=R is true if this event does not occur afterTa f ter .

Forbidden Between

R ensures that an event (Emon) must never occur between a temporalinterval ]tBegin; tEnd [ (over ERe f ). S|=R is true if this event does notoccur between temporal interval ]tBegin; tEnd [.

QuantitativePresence

MinimumDelayR ensures that an event (Emon) must occur after a minimum time Tmin

(time unit over ERe f ). S|=R is true if this event occurs after Tmin.

MaximumDelayR ensures that an event (Emon) must occur before a deadline Tmax

(time unit over ERe f ). S|=R is true if this event occurs before Tmax.

PunctualityR ensures that an event (Emon) must occur at one punctual date t (timeunit over ERe f ). S|=R is true if this event occurs at the t date.

Qua

litat

ive

Recurrence

UnboundedRecurrenceR ensures that an event (Emon) must occur infinity of time. S|=R istrue if this event occur.

BoundedRecurrenceR ensures that an event (Emon) must occur k time. S|=R is true if thisevent occur k time.

QualitativePresence

PresenceAfterR ensures that an event (Emon) must occur after ERe f have been de-tected. S|=R is true if this event occurs at least once after ERe f .

PresenceBeforeR ensures that an event (Emon) must occur before ERe f . S|=R is falseif ERe f occurs before Emon.

QualitativeAbsenceAbsenceAfter

R ensures that an event must never occur after ERe f . S|=R is true ifthis event does not occur.

AbsenceBeforeR ensures that an event (Emon) must never occu before ERe f r. S|=Ris true if Emon does not occur before ERe f .

Figure 1: Temporal Requirements Classification.

Temporal Logic Description: Contains mappingsof the property monitored by the pattern toTCTL for each of the four defined scopes. Wechose TCTL since it allows quantitative temporalproperties expression.

4 TRANSFORMATIONAPPROACH

Since the observation patterns’ basis has been intro-duced, we will discuss now how to use this basis inthe verification process. In practice, once the tempo-ral requirements for the system under study are iden-tified and extracted, the appropriate patterns for these

ICINCO 2010 - 7th International Conference on Informatics in Control, Automation and Robotics

48

requirements are selected and instantiated with thesuitable parameters, thus resulting in some SM ob-servers. Each SM observer monitors an elementaryrequirement. The SM observers are then translatedinto TA observers. This transformation will be pre-sented hereafter.

4.1 Transformation Idea

In spite of the number of automated analyzers devel-oped for TA, these tools suffer from two main lim-itations: the first is that users must be familiar withtheir formal notations. The second is the lack of pat-terns for high-level system design (hierarchy notionnamely). On the other hand, semi-formal languages,such as UML SM, are suitable for expressing systemrequirements. However, the automatic verification ofthese models is unfeasible directly. The temporal re-quirement verification approach that we propose takesadvantage of the expression flexibility of SM and theanalysis facilities offered by TA formalism.

The various rules of the transformation algo-rithm we have defined are expressed according to theModel-Driven Architecture (MDA) approach. MDAis an initiative and a standard proposed by the OMG,allowing developers to create systems entirely basedon models. It points out the idea of separation of con-cerns by unlinking/uncoupling the application logicfrom the implementation platforms technology (Weiset al., 2003).

Figure 2 illustrates the use of the MDA four-layermetamodeling architecture for our transformation;

• The source model (resp. target model) is ex-pressed according to the source metamodel (resp.target metamodel),

• The metamodels are defined and expressed ac-cording to the MOF metametamodel (in our trans-formation, we used the Ecore metametamodel,which is the Eclipse implementation of MOF),

• A metamodel is developed for TA. On the otherside, we used the UML metamodel distributed inthe Eclipse framework,

• All the rules are introduced at the metamodellevel,

• The transformation takes a UML SM model as asource model and generates a TA model with acorresponding formatted code.

4.2 Time Annotations

Here we use SM as a modeling notation to take advan-tage of the flexibility they offer. However, since westrive to obtain an accurate specification, we should

Figure 2: Transformation Approach.

guide the user while introducing the temporal con-straints. Concretely, we propose a set of timed anno-tations in order to express the states’ characteristics aswell as the transition guards. Table 2 shows some ex-amples of them and defines the signification of eachannotation.

Table 2: Time annotations used.

Time annotation Signification1 at most(Tmax) t≤ Tmax

2 at least(Tmin) t≥ Tmin

3 after(d) t=d4 between(Tmin, Tmax) Tmin ≤t≤ Tmax

5 upper(Tmin) t> Tmin

6 lower(Tmax) t< Tmax

4.3 Transformation Algorithm

One of the key parts of our method is the translationof UML SM with time annotations into TA. For sakeof space, we will briefly describe the transformationrules while giving the source and target element foreach of them in 3. For more details, the reader canrefer to (Mekki et al., 2010).

Table 3: Transformation Rules.

Rule Name Source element:UML SM

target element:TA

FromStateMachine StateMachine TASimple2Simple State StateFinal2State Final Pseudostate StateOR2Automata State AutomatonAND2Automata State AutomatonTrans2Trans Transition TransitionEntry2State EntryAction StateExit2State ExitAction StateDo2State DoActivity State

The main rule of this algorithm is FromStateMa-chine rule. This rule is the first one carried out bythe transformation algorithm. It picks elements inthe source model, then calls on other rules to trans-late the selected elements into TA elements in the tar-

PATTERNS FOR TEMPORAL REQUIREMENTS ENGINEERING - A Level Crossing Case Study

49

get model. Likewise, the called rules behave in thesame way; they select elements in the source modeland call the appropriate rule for transforming them.For example, the FromStateMachine rule is appliedto elements of type “UML::StateMachine” and trans-lates them into a “TA::AutomataMachine” element.Also, different element types are selected and differ-ent rules are called on in this rule. First, the ruleselects all the UML states. Then for each selectedstate, according to its type, the rule Simple2Simple orOR2Automata or AND2Automata is called on. Sec-ondly, it translates the “UML::Transition” elementsby invoking rule Trans2Trans. Also, this rule dealswith another element type, the “UML::Pseudostate”,by invoking some other rules such as Final2State.

This internal transformation process is the samefor all the rules; each rule transforms the source ele-ment into the target one. Then, it selects subelementsof the source element and calls on the appropriate ruleto transform them.

4.4 Verification Process

Once our observation patterns’ basis is implemented,we introduce a verification process based on this ba-sis. This section will outline the global architectureof our approach. The architecture is depicted graphi-cally in Figure 3 (Mekki et al., 2009).

Concretely, our approach is composed of four pro-cesses: first, temporal requirements for the system un-der study are identified and extracted. Second, theappropriate patterns for these extracted requirementsare selected and instantiated with the suitable param-eters. This second process results in some SM ob-servers. Each SM observer corresponds to an elemen-tary requirement. Third, the SM observers are trans-lated into TA observers. In parallel and in the sameway, the specification under study (SM model withtime annotations) is abstracted and translated into aTA model. The translation from the UML SM to TAis performed using the MDA model transformationtechnique as shown previously.

Finally, the generated TA are synchronized withthe formal system’s specification model (TA) to gen-erate a global model holding both the system speci-fication and the requiements’ monitoring. Thus, theverification task is reduced to an error-state reachabil-ity search on the obtained global model.

Figure 3: Method Global View.

5 CASE STUDY

5.1 Case Study Description

A classical automatic level crossing system is com-posed of several modules. The local control sys-tem which manages the traffic in the crossing area,a pair of barriers (gate), traffic lights whose role is toalert and prevent road users from entering the cross-ing zone and a train-sensing module which monitorstrains approaching/leaving (Ghazel, 2009). The sub-systems mentioned above execute in parallel and syn-chronize through events.

Several requirements ∗ are given in textual speci-fication in Figure 4. Next, using this textual specifi-cation, we will show how patterns are used to expressand monitor requirements.

5.2 Using Patterns

For sake of space, only two requirements will bechecked on the basis of the textual system specifi-cation. For each requirement, formalization is intro-duced using the defined generic template. First, a tex-tual description of the requirement is presented, fol-lowed by an intuitive graphical representation in theshape of an UML SM (SM patterns). Then, a defi-nition using our structured English grammar is givenand finally a temporal logic expression is used to ex-press formally the requirement. 1) The 1st require-∗http://www.dagstuhl.de/fileadmin/redaktion/Programm/Seminar/

07241/07241.CaseStudy.pdf

ICINCO 2010 - 7th International Conference on Informatics in Control, Automation and Robotics

50

1. “. . . As long as an approaching train runs over the activationsensor the sensor shall generate an occupied signal. When the lastaxle of the train has traversed the activation sensor it shallgenerate a free signal again. If the control unit receives anoccupied signal from the activation sensor in the unsaved mode, itwill enter the saving mode and gives the command to turn on theyellow lamp of the set of lights. Three seconds after entering thesaving mode the control unit has to give the command forswitching off the yellow lamp and turning on the red lamp. . . ”

2. “. . . By entering saved mode the controller shall switch on thesupervision signal to show signal aspect LC1, which means to turnon the blinking light. Twelve seconds after the system has enteredthe safed mode it must start to lower the gate. The activity oflowering or raising the gate must not last longer than six secondsfrom one end position to the other. When the gate has reached thelower end position within the six seconds interval the control unitwill enter the mode saved and gates closed. . . ”

Figure 4: Specification Example.

ments states that three seconds after receiving the en-tering signal, the controller should send command forswitching lights. This requirement consists in a punc-tuality property (Figure 5) of 3 seconds between en-tering signal and switch signal.

Punctuality Pattern

Pattern Name: Punctuality

Textual Description: The Punctuality pattern is used to check that agiven event execution is delayed by exactly d time units relativelyto a given reference.

UML SM Diagram:

Structured English:Scope “switch” must occur exactly at “3” tu over “entering”.

Temporal Logic description:

Globally: AG[receive(entering)⇒ AF=d receive(switch)]

After Ea: AG(Ea→(EG[receive(entering)⇒ AF=d receive(switch)]))

Before Eb: A((AG[receive(entering)⇒ AF=d receive(switch)]) U Eb)

Between Eb and Ee:P=AG[receive(entering)⇒ AF=d receive(switch)]AG((Eb ∧¬Ee)→(P) U Ee)

Figure 5: Punctuality Pattern.

2) The 2nd requirement states that the command sig-nal closed should be detected at most 19 seconds afterentering signal. This requirement consists in maxi-mumdelay property (Figure 6) of 19 time units be-tween entering and closed signals.

MaximumDelay Pattern

Pattern Name: MaximumDelay

Textual Description: The MaximumDelay pattern is used to check ifevent execution is delayed by at most a given value ` time unitsfrom a given reference. This value ` should be in [0, Tmax] interval.

UML SM Diagram:

Structured English: Scope “closed” must occur Before a delay of“19” tu over “entering”.

Temporal Logic description:

Globally: AG[receive(entering)⇒¬closed U≤19 receive(closed)]

After Ea:AG(Ea→(AG[receive(entering)⇒ (¬closed U≤19 receive(closed))]))

Before Eb:A((AG[receive(entering)⇒ (¬closed U≤19 receive(closed))]) U Eb)

Between Eb and Ee:P=AG[receive(entering)⇒ (¬closed U≤19 receive(closed))]AG((Eb ∧¬Ee)→(P) U Ee)

Figure 6: MaximumDelay Pattern.

5.3 Verification

The above step consists in instantiating the appropri-ate patterns in order to obtain observers for the ex-tracted requirements. These observers are then trans-lated into TA models to be synchronized with the sys-tem specification. The verification process consists inexamining the reachability of the KO-states within theobservers. The verification of our case study is carriedout using the UPPAAL model checker.

6 CONCLUSIONS

In this paper, we have presented a model-basedmethod applicable to formal specification and valida-tion of time-constrained systems. The approach usesa set of observation patterns that we have establishedand which act as watch-dogs for the defined temporalrequirements. Each pattern has been defined using astandard template we developed. Using patterns of-fers genericity and reusability.

On the other hand, we have developed a trans-formation algorithm to translate SM with time anno-tations into TA. The aim being to make a basis forthe verification process. For this purpose, we have

PATTERNS FOR TEMPORAL REQUIREMENTS ENGINEERING - A Level Crossing Case Study

51

introduced a TA metamodel using an extended def-inition of the original TA definition given by (Alurand Dill, 1994) (for briefness reasons, the TA meta-model description is omitted in this paper). Once therelationships (transformations rules) between UMLSM metamodel elements and TA metamodel ele-ments are defined, we expressed them in the QVT(Query/View/Transformation) language, defined bythe OMG as the standard for the transformation phase.Then we used QVTo -an Eclipse Plugin- to run the al-gorithm.

Processing the verification upon the TA observerssynchronized with the system specification reducesthe verification task to a reachability analysis of theKO-nodes within the observers.

Validation of the model transformation algorithmwe have developed is a key issue to ensure the correct-ness of our approach. Hence, a rigorous validationstep is still needed where several properties shouldbe checked such as; syntactic and behavioral equiv-alence, termination and confluence (Kuster, 2006).

Based on the structured English grammar we havedeveloped, a prototype tool which offers interest-ing facilities in terms of requirements specificationand requirements consistency-check has been imple-mented. A subsequent step will be to extend this toolwith a new module which automatically instantiatesobservers for the entered requirements using the ob-servation patterns repository.

REFERENCES

Alur, R. and Dill, D. (1994). A theory of timed automata.Theoretical Computer Science, 126:183–235.

Dhaussy, P., Pillain, P.-Y., Creff, S., Raji, A., Traon, Y. L.,and Baudry, B. (2009). Evaluating context descrip-tions and property definition patterns for software for-mal validation. In 12th ACM/IEEE International Con-ference, MODELS 2009, Denver, Colorado, USA.

Dong, J. S., Hao, P., Qin, S., Sun, J., and Yi, W. (2008).Timed automata patterns. IEEE Transactions on Soft-ware Engineering, 34(6):844–859.

Dwyer, M. B., Avrunin, G. S., and Corbett, J. C. (1999).Patterns in property specifications for finite-state ver-ification. In In Proceedings of the 21st InternationalConference on Software Engineering, pages 411–420.

Gamma, E., Helm, R., Johnson, R., and Vlissides, J.(1995). Design Patterns : Elements of ReusableObject-Oriented Software. Addison Wesley.

Ghazel, M. (2009). Using stochastic petri nets for level-crossing collision risk assessment. IEEE Transactionon Intelligent Transportation Systems, 10(4):668–677.

Ghazel, M., Toguyni, A., and Yim, P. (2009). State ob-server for DES under partial observation with time

petri nets. Journal of Discrete Event Dynamic Sys-tems, 19(2):137–165.

Konrad, S. and Cheng, B. (2005). Real-time specifica-tion patterns. In Proceedings of the 27th Interna-tional Conference on Software Engineering (ICSE05),St Louis, MO, USA.

Kuster, J. M. (2006). Definition and validation of modeltransformations. Software and System Modeling,5(3):233–259.

Larsen, K., Pettersson, P., and Yi, W. (1997). Uppaal in anutshells. International Journal of Software Tools forTechnology Transfer, 1(1/2):134–152.

Mekki, A., Ghazel, M., and Toguyeni, A. (2009). Vali-dating time-constrained systems using uml statechartspatterns and timed automata observers. In 3rd Inter-national Workshop on Verification and Evaluation ofComputer and Communication Systems Vecos09, Ra-bat, Morroco.

Mekki, A., Ghazel, M., and Toguyeni, A. (2010). Time-constrained systems validation using mda modeltransformation. In Proceedings of the 8th ENIM IFACInternational Conference of Modeling and Simula-tion, Hammamet, Tunisia.

Nascimento, F., Oliveira, M., and Wagner, F. (2009). For-mal verification for embedded systems design basedon mde. In IESS’09 - International Embedded Sys-tems Symposium, Friedrichshafen, Germany.

Schmidt, D. C. (2004). Model driven engineering. IEEEComputer, 23(2):25–31.

UML (2009). Unified Modeling Language Specification,Version 2.2. OMG.

Weis, T., Ulbrich, A., and Geihs, K. (2003). Model meta-morphosis. IEEE Software, IEEE Computer Society,20(5):46–51.

Yovine, S. (1997). Kronos: a verification tool for real-timesystems. International Journal of Software Tools forTechnology Transfer, 1(1/2):123–133.

ICINCO 2010 - 7th International Conference on Informatics in Control, Automation and Robotics

52