Early Analysis of Ambient Systems

SYSML Properties using OMEGA2-IFx

Manzoor Ahmad

, Iulia Dragomir

, Jean-Michel Bruel

, Iulian Ober

and Nicolas Belloir

IRIT, Universit

e de Toulouse, Toulouse, France

LIUPPA, Universit

e de Pau et des Pays de l’Adour, Pau, France

Keywords:

Requirements, Formal Methods, Properties Veriﬁcation, Observers, RELAX, Simulation, OMEGA2, IFx.

Abstract:

Formal methods provide tools to verify the consistency and correctness of a speciﬁcation with respect to the

desired properties of the system. This veriﬁcation is important as the development of an AAL (Ambient

Assisted Living) system involves different technologies (medical services, surveillance cameras, intelligent

devices, etc.) requiring a strong consistency checking between models. We illustrate in this paper how we

prove some of the properties of the system before the development even starts. To model the AAL system, we

use the SYSML language. In terms of tools, we use Rational Rhapsody in combination with the OMEGA2

proﬁle which is an executable UML/SYSML proﬁle used for the formal speciﬁcation and validation of critical

real-time systems. This proﬁle is supported by the IFx toolset which provides mechanisms for the model

simulation and properties veriﬁcation of the AAL system.

1 INTRODUCTION

Ambient Assisted Living (AAL) systems are dedi-

cated to help people with limited capabilities in their

life. This kind of systems, and more specialy all Am-

bient Systems are highly adaptive. They modify their

behavior at run-time in response to changing environ-

mental conditions. For these systems, Non Functional

Requirements (NFRs) play an important role, and one

has to identify as early as possible the requirements

that are adaptable. The distributed nature of these

systems and changing environmental factors makes it

difﬁcult to anticipate all the explicit states in which

the system will be during its lifetime. As such, they

need to be able to tolerate a range of environmental

conditions and contexts, but the exact nature of these

contexts remains imperfectly understood.

In this context, we focus on two types of system

properties for our AAL case study : RELAX-ed and

Invariant. These requirements are obtained by apply-

ing a process called RELAX (Whittle et al., 2009) on

traditional requirements. RELAX is a requirement en-

gineering language for self-adaptive systems that in-

corporates uncertainty into the speciﬁcation of these

systems. Our objective is to prove these properties as

soon as possible in the speciﬁcation cycle.

On the other hand, formal methods

are intended

http://www-2.cs.cmu.edu/

svc/

to systemize and introduce rigor into all the phases

of software development. This helps us to avoid

overlooking critical issues, provides a standard means

to record various assumptions and decisions, and

forms a basis for consistency among related activi-

ties. By providing precise and unambiguous descrip-

tion mechanisms, formal methods facilitate the under-

standing required to coalesce the various phases of

software development into a successful endeavor.

In this paper we asses the use of formal methods

for modeling and veriﬁcation of AAL systems. We

use the OMEGA2-IFx approach which has been ap-

plied for the veriﬁcation and validation of industry-

grade models (Dragomir et al., 2012) providing inter-

esting results. The OMEGA2 UML/SYSML Proﬁle

(Ober and Dragomir, 2010) deﬁnes the semantics of

UML/SYSML elements providing the means to model

coherent and unambiguous system models. In order

to make the models veriﬁable, it presents as exten-

sion the observer mechanism for specifying dynamic

properties of models. The OMEGA2 UML/SYSML

Proﬁle is implemented by the IFx Toolbox (Ober

et al., 2006) which provides static analysis, simulation

and timed-automaton based model checking (Clarke

et al., 1999) techniques for validation.

This paper takes the reader a step forward and en-

riches our existing work by integrating formal meth-

ods for the veriﬁcation of NFRs and specially RE-

147

Ahmad M., Dragomir I., Bruel J., Ober I. and Belloir N..

Early Analysis of Ambient Systems SYSML Properties using OMEGA2-IFx.

DOI: 10.5220/0004483101470154

In Proceedings of the 3rd International Conference on Simulation and Modeling Methodologies, Technologies and Applications (SIMULTECH-2013),

pages 147-154

ISBN: 978-989-8565-69-3

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

LAX-ed requirements.

Paper Structure. This paper is organized as fol-

lows: Section 2 presents other approaches deﬁned for

the veriﬁcation of AAL models, Section 3 introduces

the OMEGA2 UML/SYSML Proﬁle and the IFx Tool-

box that are used for modeling and properties veriﬁ-

cation, Section 4 describes the case study: its speci-

ﬁcation, system architecture and behavior, Section 5

presents the properties, the AAL system has to satisfy,

while Section 6 presents the veriﬁcation and simula-

tion results, Section 7 concludes the paper and high-

lights the future work.

2 RELATED WORK

The speciﬁcation and veriﬁcation of NFRs in the early

stages of the AAL development cycle is a crucial issue

(Benghazi et al., 2009). These systems require clear

and precise speciﬁcations in order to describe the sys-

tem behavior and its environment. The formal spec-

iﬁcation of the system behavior supported by math-

ematical analysis and reasoning techniques improve

their development process and enable the veriﬁcation

of these systems.

(Nehmer et al., 2006) present a veriﬁcation ap-

proach based on MEDISTAM-RT which is a method-

ological framework for the design and analysis of

real-time systems and timed traces to check the fulﬁll-

ment of non-functional requirements. They focus on

safety and timeliness properties, to assure the correct

functioning of AAL systems and to show the applica-

bility of this methodology in the context of this kind

of systems.

(Apvrille et al., 2006) introduce a proﬁle named

TURTLE (Timed UML and RT-LOTOS Environ-

ment). With its formal semantics given in RT-LOTOS

and its toolkit, TURTLE enables a priori detection of

design errors through a combination of simulation and

veriﬁcation/validation techniques. By simulation the

authors mean a partial exploration of the system state

space. It is often used for debugging purposes and

to quickly increase conﬁdence in a design. For ﬁ-

nite state space systems, exhaustive analysis is also

possible. Veriﬁcation relies on the exploration of the

whole system state space in order to prove absence

of deadlocks for instance and other general properties

that should be satisﬁed by any system.

UPPAAL

is a tool box for validation (via graphi-

cal simulation) and veriﬁcation (via automatic model-

checking) of real-time systems. It consists of two

http://www.it.uu.se/research/group/darts/uppaal

main parts: a graphical user interface and a model-

checker engine. The idea is to model a system using

timed automata, simulate it and then verify properties

on it. Timed automata are ﬁnite state machines with

time (clocks). A system consists of a network of pro-

cesses that are composed of locations. Transitions be-

tween these locations deﬁne how the system behaves.

The simulation step consists of running the system in-

teractively to check that it works as intended. Then

the veriﬁer checks the reachability properties, i.e., if a

certain state is reachable or not.

3 THE VERIFICATION TOOLS

In this section, we introduce the OMEGA2 Proﬁle

which we used for modeling the AAL system and its

properties and the IFx toolset used for the veriﬁcation

and simulation of these properties.

3.1 The OMEGA2 UML/SysML Proﬁle

OMEGA2 is an executable UML/SYSML proﬁle ded-

icated to the formal speciﬁcation and validation of

critical real-time systems. It is based on a subset of

UML 2.2/SYSML 1.1 containing the main constructs

for modeling system structure and class/block behav-

ior and which provides a clear and coherent opera-

tional and timed semantics.

The architecture of an OMEGA2 model is

described in Class/Block Deﬁnition Diagrams by

classes/blocks with their relationships (association,

generalization and composition) and their interfaces.

Each class/block deﬁnes properties and operations, as

well as a state machine. The hierarchical structure

of a model is deﬁned in composite structures/Internal

Block Diagrams: parts that communicate through

ports and connectors. The UML/SYSML Proﬁle

leaves open several semantic variation points for

which OMEGA2 deﬁnes a set of well-formedness

rules that result in a strong typing language. For fur-

ther details on the rules, their rationale and formal-

ization, the reader is referred to (Ober and Dragomir,

2011).

The behavior of a system is given by the mod-

eled state machines that use asynchronous operation

calls and signal outputs for communication. The pro-

ﬁle owns a textual action language compatible with

UML 2.2 action metamodel from which implements

the main constructs: object creation/destruction, ex-

pression evaluation, variable assignment, signal out-

put and control ﬂow structuring statements.

The operational semantics of OMEGA2 relies

on an asynchronous timed execution model. Each

SIMULTECH2013-3rdInternationalConferenceonSimulationandModelingMethodologies,Technologiesand

Applications

148

class/block is represented by a timed input/output au-

tomata, potentially executing in parallel with other

blocks and communicating via asynchronous opera-

tion calls and signals.

The OMEGA2 Proﬁle can model timed behavior,

where the model time base can either be discrete or

continuous and it is speciﬁed by the user at veriﬁca-

tion. The time model is controlled by primitives from

automata with urgency (Bornot and Sifakis, 2000):

clocks, time guards and transition urgency annota-

tions. The clock is represented by a Timer block on

which we can perform actions as: set for setting the

clock a delay and reset to restore the clock to 0. Time

guards are either described as inequalities or speciﬁed

via the timeout operation that veriﬁes that a certain de-

lay has elapsed. With respect to time progress, tran-

sitions can also deﬁne a particular semantics based

on their stereotype: eager deﬁnes that time progress

is disabled in a state (i.e., the actions on a transition

are executed as soon as possible), delayable means

that the time progress is enabled but it is bounded

by a limit and lazy speciﬁes that time progress is en-

abled and unbounded (i.e. time can progress to in-

ﬁnity). Based on these notions, one can also model

synchronous communication in OMEGA2 model.

For specifying and verifying dynamic proper-

ties of models, OMEGA2 uses the notion of ob-

servers. Observers are special classes/blocks moni-

toring run-time states and events. They are deﬁned by

classes/blocks stereotyped with <<observer>>. They

may have local memory (attributes) and a state ma-

chine describes their behavior. States are classiﬁed

as <<success>> and <<error>> states to express the

(non)satisfaction of safety properties. The main issue

in modeling observers is the choice of events which

trigger their transitions, and which must include spe-

ciﬁc UML/SYSML event types. One can observe:

• Events related to signal exchange: send,

receivesignal, acceptsignal.

• Events related to operation calls: invoke,

receive (reception of call), accept (start of ac-

tual processing of call – may be different from

receive), invokereturn (sending of a return

value), receivereturn (reception of the return

value), acceptreturn (actual consumption of the

return value).

• Informal events explicitly speciﬁed by the mod-

eller using the informal action.

The trigger of an observer transition is a match clause

specifying the type of event (e.g., receive), some re-

lated information (e.g., the operation name) and ob-

server variables that may receive related information

(e.g., variables receiving the values of operation call

parameters). Besides events, an observer may access

any part of the state of the UML model: object at-

tributes and states, signal queues.

3.2 IFx Toolset

OMEGA2 models can be simulated and properties

can be veriﬁed using the IFx toolset (Bozga et al.,

2004). The following terminology is used:

Veriﬁcation. It designates the automatic process of

verifying whether an OMEGA2 UML/SYSML

model satisﬁes (some of) the properties (i.e. ob-

servers) deﬁned on it. The veriﬁcation method

employed in IFx is based on systematic explo-

ration of the system state space (i.e., enumerative

model checking).

Simulation. It designates the interactive execution of

an OMEGA2 UML/SYSML model. The execu-

tion can be performed step-by-step, random, or

guided by a simulation scenario (for example an

error scenario generated during a veriﬁcation ac-

tivity).

The IFx toolset relies on a translation of

UML/SYSML models towards a simple speciﬁcation

language based on an asynchronous composition of

extended timed automata, the IF language

. The

translation takes an input model in XMI 2.0 format.

The compiler veriﬁes the set of well-formedness

rules imposed by the proﬁle and generates an IF

model that can be further reduced by static analysis

techniques. This model is subject to veriﬁcation that

either validates the model with respect to its prop-

erties or produces a list of error scenarios that can

be further debugged using the simulator. The overall

workﬂow of IFx Toolset is shown in Fig. 1 (Verimag

and Irit, 2011).

4 MODELING THE AAL SYSTEM

WITH OMEGA2 PROFILE

In this section, we explore the AAL system speciﬁ-

cation, the system architecture showing its structural

and behavioral diagrams i.e. its block deﬁnition dia-

gram, internal block diagrams and state machine dia-

grams.

4.1 System Speciﬁcation

Here is an excerpt of the AAL case study (Whittle

et al., 2009): Mary is a widow. She is 65 years old,

http://www-if.imag.fr/

EarlyAnalysisofAmbientSystemsSYSMLPropertiesusingOMEGA2-IFx

149

Figure 1: IFx Workﬂow(Verimag and Irit, 2011).

overweight and has high blood pressure and choles-

terol levels. Following her doctors instructions, she

is considering to loose weight. The doctor has rec-

ommended a hypo caloric diet with low levels of salt.

She lives by herself in an AAL house.

In this paper, we only consider the interaction of

the Patient with the Fridge for calculating the daily

calories intake of the Patient. First, we start by tak-

ing into account the structural part of the AAL sys-

tem. We consider those parts that are concerned with

the daily calories intake of the Patient in the AAL

house. The AAL system is composed of Fridge and

Patient. We would like to model these parts and

the interaction that takes place between them. The

Fridge partially contributes to the minimum liquid

intake of the Patient; it also looks at the calories

consumption of the Patient as he/she does not need

to exceed it after a certain threshold.

4.2 System Architecture

Fig. 2 shows the main internal block diagram. The

important parts of the AAL system are Patient and

Fridge. A Fridge in turn is composed of Food,

Display, Alarm and Controller blocks. The Food

block contains information about the food items in the

Fridge, the calories contained by each item, the total

number of calories the Patient has accumulated and

the calories threshold that should not be surpassed.

The fridge Display is used to show the amount of

calories consumed by the Patient. The Alarm is ac-

tivated in case the Patient’s calories level surpasses

a certain threshold. The Controller transfer the in-

formation from the Patient to the concerning ele-

ments and back to the environment.

The communication between different blocks

takes place through ports. A port bears a type.

In OMEGA2, the type of a port must be an Inter-

face. The type speciﬁes the set of requests (op-

eration calls and/or signals) that are transferred be-

tween parts (components) by means of ports and con-

nectors. In Fig. 2, the Patient block has a stan-

dard port named pToFridge. This port has a con-

tract named Patient2Fridge and is acting as a pro-

vided interface of the Patient block. The inter-

face Patient2Fridge deﬁnes an operation eat(int

item, int quantity). This interface is then used

as a type of pToFridge port. At the same time

the Patient block has a required interface named

pFromPatient. For the full system architecture, the

reader is referred to (Ahmad and Dragomir, 2013).

Rational Rhapsody Developer v7.5.2

is used to

create OMEGA2 models. OMEGA2 models use a

proﬁle and a predeﬁned library provided with the tool

(OMEGA2.sbs and OMEGA2Predeﬁned.sbs). Any

other UML2.2 or SYSML1.1 editor supporting proﬁl-

ing and exporting in the XMI2.0 standard compatible

with Eclipse ecore can be used for OMEGA2 models.

Figure 2: Main Internal Block Diagram.

The Fridge interacts with the AAL system. Fig. 3

shows the internal block diagram for the Fridge

block. Each of the four blocks behaviors is modeled

in a separate state machine diagram.

Fig. 4 shows the state machine diagram for the

Patient block. Here the exchange of information

between Patient and Fridge takes place. We iden-

tify the number and quantity of each item present in

the Fridge. If a certain product still present in the

Fridge is chosen by the Patient then the informa-

tion is communicated with the Fridge. Otherwise the

Fridge is empty and the Patient will wait to be re-

ﬁlled. Also, if the Alarm of the Fridge is raised due

to high intake of calories, the Patient stops eating

and waits for the system to be unblocked.

The Food block models the knowledge of the

http://www.ibm.com/developerworks/rational/

SIMULTECH2013-3rdInternationalConferenceonSimulationandModelingMethodologies,Technologiesand

Applications

150

Figure 3: Fridge Internal Block Diagram.

Figure 4: Patient State Machine Diagram.

Fridge about what it contains. We deﬁne the num-

ber of items and the amount of calories associated

with each item present in the Fridge. We then calcu-

late the total number of calories accumulated by the

Patient. If the total number of calories is greater

or equal to the maximum calories allowed for the

Patient, then a message is sent and the alarm is

raised or if the total number of calories is greater than

the maximum calories allowed minus 500, then the

Patient is warned with a message that the calories

level is approaching the maximum amount of calories

allowed.

5 PROPERTIES VERIFICATION

OF AAL SYSTEM

The properties of the AAL system that we modeled

and veriﬁed are obtained after the RELAX process

is applied on its traditional requirements. RELAX is

a requirement engineering language for self-adaptive

systems that incorporates uncertainty into the spec-

iﬁcation of these systems. Typical textual require-

ments prescribe behavior using a modal verb such

as SHALL that deﬁnes functionality that a software

system must always provide. For self adaptive sys-

tems such as AAL, however, environmental uncer-

tainty may mean that it is not always possible to

achieve all of those SHALL statements; or behavioral

uncertainty may allow for trade-offs between SHALL

statements to RELAX non-critical statements in favor

of other, more critical ones. Therefore, RELAX iden-

tiﬁes two types of requirements: one that can be RE-

LAX-ed in favor of other ones called variant or RE-

LAX-ed and other that should never change called in-

variant. Below are the properties to be veriﬁed.

5.1 Traditional/RELAX-ed Requirement

Following is the traditional requirement that we have

transformed into a RELAX-ed requirement.

• The fridge shall detect and communicate with

food packages

RELAX-ed version of this requirement is as fol-

lows:

• Property 1: The fridge SHALL detect and com-

municate information with AS MANY food pack-

ages AS POSSIBLE

Below are the uncertainty factors associated with

the given RELAX-ed requirement.

ENV. Food locations, foot item information (type,

calories), food state (spoiled and unspoiled)

MON. RFID readers, Cameras, Weight sensors

REL. RFID tags provide food locations and food in-

formation; Cameras provide food locations (Cam-

eras provide images that can be analyzed to esti-

mate food locations), Weight sensors provide food

information (whether eaten or not)

The satisfaction of this requirement contributes to

the balanced diet of the Patient. We would like to

verify this property as it is important for the AAL sys-

tem to know about as many food items as possible

present in the Fridge. Fig. 5 shows the state machine

diagram of the Property 1. To start with, the num-

ber of items consumed by the Patient and the total

number of items in the Fridge are identiﬁed. Then

we verify the identity of the Patient, if the person is

identiﬁed as the Patient, then we calculate the num-

ber of items consumed. We then calculate the num-

ber of items left in the Fridge which is equal to the

sum of all the items present in the Fridge. In the last

step, we calculate if ((total number of items - number

of items consumed - number of items left) >-1) and

((total number of items - number of items consumed

- number of items left) <1), it means that we have

reached the <<success>> state by having informa-

tion about all the items present in the Fridge, i.e. it

EarlyAnalysisofAmbientSystemsSYSMLPropertiesusingOMEGA2-IFx

151

Figure 5: Property1 State Machine Diagram.

should be 0. Inversely, if it is less than -1 and greater

than 1, then it means that we are missing information

about some of the items present in the Fridge and the

observer passes into the <<error>> state.

5.2 Invariant Requirement

Here is the invariant requirement that we veriﬁed.

• Property 2: The alarm SHALL be raised instanta-

neously if the total number of calories surpasses

the maximum calories allowed for the patient

Fig. 6 shows the state machine diagram of the

property 2. This requirement implies that the Alarm

shall be immediately raised as soon as the total num-

ber of calories equals or surpasses the maximum calo-

ries allowed for the Patient. If it happens then the

Patient should stop eating.

6 VERIFICATION RESULTS

Untill now, we have modeled the AAL system and

the properties to be veriﬁed on the model. It is now

time to verify these properties and in case if there is

an error, simulate it to ﬁnd the error and then cor-

rect it in the model. The AAL2 model is ﬁrst ex-

ported into AAL2.xmi and then using the IFx toolset

the AAL2.xmi is compiled into AAL2.if as shown in

Fig. 7.

The AAL2.if is then compiled into an executable

ﬁle i.e. AAL2.x. For the properties veriﬁcation part,

Figure 6: Property2 State Machine Diagram.

Figure 7: XMI to IF Compilation.

we run the model-checker on the AAL model which

found several error scenarios in the AAL model. Any

of the error scenario can then be loaded through the

interactive simulation interface of the IFx toolset to

trace back the error in the model and correct it.

In order to debug a model, ﬁrst we import it into

the simulator as shown in Fig. 8. We check the states

of the observers in order to identify which property

has not been satisﬁed. One can observe in Fig. 9 that

Property 2 fails. While checking the state of the en-

tire system for this property, we discover that the er-

ror state contained the maximum allowed number of

calories for the total number of calories consumed and

subsequently eat requests are sent by the Patient.

This implies that the Alarm function of the intelli-

Figure 8: Initial Simulation Interface.

SIMULTECH2013-3rdInternationalConferenceonSimulationandModelingMethodologies,Technologiesand

Applications

152

Figure 9: Error State Food Observer Simulation Interface.

gent Fridge doesn’t function properly. The Alarm

function of the Fridge is strictly linked to its Food

process and the Alarm is raised only if the total num-

ber of consumed calories is strictly superior than the

maximum allowed; condition which doesn’t satisfy

the request that the Alarm is raised as soon as pos-

sible. The correction consists in raising the Alarm in

case the total number of consumed calories is equal

to the maximum allowed threshold. Once this error is

corrected the veriﬁcation succeeds.

Figure 10: Model checking successful.

Fig. 10 shows the result of the model-checker on

the correct model.

7 CONCLUSIONS

We have modeled the structural and behavioral parts

of an AAL (Ambient Assisted Living) system. The

modeling is done using Rational Rhapsody 7.5.2 with

OMEGA2 proﬁle which is used for speciﬁcation and

veriﬁcation of dynamic properties of models through

observers. Observers are special classes/blocks mon-

itoring run-time state and events. They are deﬁned by

classes/blocks stereotyped with <<observer>>. For

the veriﬁcation and simulation part, we have used

IFx which is a toolset used for the simulation of

OMEGA2 models and the veriﬁcation of properties

deﬁned on these models. We have veriﬁed two prop-

erties of the AAL system using the IFx toolset. At

ﬁrst, the veriﬁcation results in errors which can then

be simulated through the interactive simulation inter-

face of the IFx toolset in order to identify the source

of the error and then subsequently correct it in the

model. After correcting the error in the model, the

veriﬁcation results in the fulﬁllment of all the two

properties.

The future work is centered around the use of

formal methods in the context of our integrated ap-

proach (Bruel et al., 2009). In (Ahmad et al., 2012),

we have investigated the use of goal oriented con-

cepts in combination with RELAX for modeling the

requirements of ambient systems. We have found a

link between RELAX and SYSML/KAOS (Gnaho and

Semmak, 2010), which is a goal oriented approach

based on KAOS and which extends the SYSML meta-

model with goal concepts. Based on that, we have

concluded that these two approaches are complemen-

tary with each other and RELAX can beneﬁt from the

ContributionNature and ContributionType con-

cepts of SYSML/KAOS.

This work motivated us to take beneﬁt from

the OMEGA2/IFx. In our integrated approach,

we are interested in RELAX-ed requirement which

we obtain by using the RELAX process. We

then reﬁne the RELAX-ed requirement with the

ContributionType and ContributionNature con-

cepts of SYSML/KAOS, the reader is referred to (Ah-

mad et al., 2012) for an insight on our work on RE-

LAX and SYSML/KAOS. The RELAX requirement is

then veriﬁed by a test case and then the test case can

be reﬁned by observer and then observer is allocated

to a state machine diagram. This whole sequence of

steps constitute our process.

REFERENCES

Ahmad, M., Bruel, J. M., Laleau, R., and Gnaho, C. (2012).

Using relax, sysml and kaos for ambient systems re-

quirements modeling. In The 3rd International Con-

ference on Ambient Systems, Networks and Technolo-

gies (ANT ’12). Elsevier Procedia Computer Science,

Volume 10, Pages 474 - 481.

Ahmad, M. and Dragomir, I. (2013). Ambient assisted liv-

ing system properties modeling and veriﬁcation us-

ing omega2/ifx, internal report university of toulouse

france.

Apvrille, L., de Saqui-Sannes, P., and Khendek, F. (2006).

Turtle-p: a uml proﬁle for the formal validation of crit-

ical and distributed systems. In Software and Systems

Modeling (SSM ’06). Springer, Volume 5, Issue 4, pp

449-466.

Benghazi, K., Hurtado, M. V., Rodr

ıguez, M. L., and

Noguera, M. (2009). Applying formal veriﬁcation

techniques to ambient assisted living systems. In

OnTheMove Workshop (OTM ’09). Springer-Verlag

Berlin Heidelberg 2009.

Bornot, S. and Sifakis, J. (2000). An algebraic framework

for urgency. In Information and Computation (IC

’00). Elsevier, Volume 163, Issue 1, Pages 172202.

Bozga, M., Graf, S., Ober, I., Ober, I., and Sifakis, J.

(2004). The if toolset. In Formal Methods for the De-

sign of Real-Time Systems (FMDRTS ’04). Springer

Berlin/Heidelberg.

EarlyAnalysisofAmbientSystemsSYSMLPropertiesusingOMEGA2-IFx

153

Bruel, J. M., Belloir, N., and Ahmad, M. (2009). Un pro-

ﬁle sysml pour les systmes auto-adaptatifs. In 15

eme

Colloque National de la Recherche en IUT (CNRIUT

’09).

Clarke, E. M., Grumberg, O., and Peled, D. A. (1999).

Model Checking. MIT Press, London.

Dragomir, I., Ober, I., and Lesens, D. (2012). A case study

in formal system engineering with sysml. In 17th

International Conference on Engineering of Complex

Computer Systems (ICECCS ’12). IEEE.

Gnaho, C. and Semmak, F. (2010). Une exten-

sion sysml pour l’ing

enierie des exigences non-

fonctionnelles orient

ee but. In Ing

enierie des Syst

emes

d’Information. Lavoisier Paris FRANCE.

Nehmer, J., Becker, M., Karshmer, A., and Lamm, R.

(2006). Living assistance systems: an ambient intel-

ligence approach. In Proceedings of the 28th interna-

tional conference on Software engineering (ICSE ’06

). ACM.

Ober, I. and Dragomir, I. (2010). Omega2: A new version

of the proﬁle and the tools. In 15th International Con-

ference on Engineering of Complex Computer Systems

(ICECCS ’10). IEEE.

Ober, I. and Dragomir, I. (2011). Unambiguous uml com-

posite structures: The omega2 experience. In The-

ory and Practice of Computer Science (SOFSEM ’11).

Springer, Volume 6543, pp 418-430.

Ober, I., Graf, S., and Ober, I. (2006). Validating timed

uml models by simulation and veriﬁcation. In In-

ternational Journal on Software Tools for Technology

Transfer (STTT ’06). Springer, Volume 8, Issue 2, pp

128-145.

Verimag and Irit (2011). OMEGA2-IFx for UML/SysML

v2.0, Proﬁle and Toolset, User Manual Document

v1.1.

Whittle, J., Sawyer, P., Bencomo, N., Cheng, B. H. C., and

Bruel, J. M. (2009). Relax: Incorporating uncertainty

into the specication of self-adaptive systems. In 17th

International Requirements Engineering Conference,

RE ’09. IEEE.

SIMULTECH2013-3rdInternationalConferenceonSimulationandModelingMethodologies,Technologiesand

Applications

154