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
Requirements, Formal Methods, Properties Verification, Observers, RELAX, Simulation, OMEGA2, IFx.
Formal methods provide tools to verify the consistency and correctness of a specification with respect to the
desired properties of the system. This verification 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
profile which is an executable UML/SYSML profile used for the formal specification and validation of critical
real-time systems. This profile is supported by the IFx toolset which provides mechanisms for the model
simulation and properties verification of the AAL system.
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
difficult 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 specification of these
systems. Our objective is to prove these properties as
soon as possible in the specification cycle.
On the other hand, formal methods
are intended
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 verification of AAL systems. We
use the OMEGA2-IFx approach which has been ap-
plied for the verification and validation of industry-
grade models (Dragomir et al., 2012) providing inter-
esting results. The OMEGA2 UML/SYSML Profile
(Ober and Dragomir, 2010) defines the semantics of
UML/SYSML elements providing the means to model
coherent and unambiguous system models. In order
to make the models verifiable, it presents as exten-
sion the observer mechanism for specifying dynamic
properties of models. The OMEGA2 UML/SYSML
Profile 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 verification of NFRs and specially RE-
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 defined for
the verification of AAL models, Section 3 introduces
the OMEGA2 UML/SYSML Profile and the IFx Tool-
box that are used for modeling and properties verifi-
cation, Section 4 describes the case study: its speci-
fication, system architecture and behavior, Section 5
presents the properties, the AAL system has to satisfy,
while Section 6 presents the verification and simula-
tion results, Section 7 concludes the paper and high-
lights the future work.
The specification and verification 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 specifications in order to describe the sys-
tem behavior and its environment. The formal spec-
ification of the system behavior supported by math-
ematical analysis and reasoning techniques improve
their development process and enable the verification
of these systems.
(Nehmer et al., 2006) present a verification 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 fulfill-
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 profile 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
verification/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 confidence in a design. For fi-
nite state space systems, exhaustive analysis is also
possible. Verification 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 satisfied by any system.
is a tool box for validation (via graphi-
cal simulation) and verification (via automatic model-
checking) of real-time systems. It consists of two
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 finite state machines with
time (clocks). A system consists of a network of pro-
cesses that are composed of locations. Transitions be-
tween these locations define how the system behaves.
The simulation step consists of running the system in-
teractively to check that it works as intended. Then
the verifier checks the reachability properties, i.e., if a
certain state is reachable or not.
In this section, we introduce the OMEGA2 Profile
which we used for modeling the AAL system and its
properties and the IFx toolset used for the verification
and simulation of these properties.
3.1 The OMEGA2 UML/SysML Profile
OMEGA2 is an executable UML/SYSML profile ded-
icated to the formal specification 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 Definition Diagrams by
classes/blocks with their relationships (association,
generalization and composition) and their interfaces.
Each class/block defines properties and operations, as
well as a state machine. The hierarchical structure
of a model is defined in composite structures/Internal
Block Diagrams: parts that communicate through
ports and connectors. The UML/SYSML Profile
leaves open several semantic variation points for
which OMEGA2 defines 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,
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-
file 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 flow structuring statements.
The operational semantics of OMEGA2 relies
on an asynchronous timed execution model. Each
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 Profile can model timed behavior,
where the model time base can either be discrete or
continuous and it is specified by the user at verifica-
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 specified
via the timeout operation that verifies that a certain de-
lay has elapsed. With respect to time progress, tran-
sitions can also define a particular semantics based
on their stereotype: eager defines 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 specifies that time progress is en-
abled and unbounded (i.e. time can progress to in-
finity). 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 defined by
classes/blocks stereotyped with <<observer>>. They
may have local memory (attributes) and a state ma-
chine describes their behavior. States are classified
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-
cific 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 specified 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 verified using the IFx toolset (Bozga et al.,
2004). The following terminology is used:
Verification. It designates the automatic process of
verifying whether an OMEGA2 UML/SYSML
model satisfies (some of) the properties (i.e. ob-
servers) defined on it. The verification 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 verification ac-
The IFx toolset relies on a translation of
UML/SYSML models towards a simple specification
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 verifies the set of well-formedness
rules imposed by the profile and generates an IF
model that can be further reduced by static analysis
techniques. This model is subject to verification 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
workflow of IFx Toolset is shown in Fig. 1 (Verimag
and Irit, 2011).
In this section, we explore the AAL system specifi-
cation, the system architecture showing its structural
and behavioral diagrams i.e. its block definition dia-
gram, internal block diagrams and state machine dia-
4.1 System Specification
Here is an excerpt of the AAL case study (Whittle
et al., 2009): Mary is a widow. She is 65 years old,
Figure 1: IFx Workflow(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 Patients 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 specifies 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 defines 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
profile and a predefined library provided with the tool
(OMEGA2.sbs and OMEGA2Predefined.sbs). Any
other UML2.2 or SYSML1.1 editor supporting profil-
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-
filled. 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
Figure 3: Fridge Internal Block Diagram.
Figure 4: Patient State Machine Diagram.
Fridge about what it contains. We define 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
The properties of the AAL system that we modeled
and verified 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-
ification of these systems. Typical textual require-
ments prescribe behavior using a modal verb such
as SHALL that defines 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-
tifies 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 verified.
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-
Property 1: The fridge SHALL detect and com-
municate information with AS MANY food pack-
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 identified. Then
we verify the identity of the Patient, if the person is
identified 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
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 verified.
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.
Untill now, we have modeled the AAL system and
the properties to be verified on the model. It is now
time to verify these properties and in case if there is
an error, simulate it to find the error and then cor-
rect it in the model. The AAL2 model is first 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
file i.e. AAL2.x. For the properties verification 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, first 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 satisfied. 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.
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 verification succeeds.
Figure 10: Model checking successful.
Fig. 10 shows the result of the model-checker on
the correct model.
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 profile which is used for specification and
verification of dynamic properties of models through
observers. Observers are special classes/blocks mon-
itoring run-time state and events. They are defined by
classes/blocks stereotyped with <<observer>>. For
the verification and simulation part, we have used
IFx which is a toolset used for the simulation of
OMEGA2 models and the verification of properties
defined on these models. We have verified two prop-
erties of the AAL system using the IFx toolset. At
first, the verification 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
verification results in the fulfillment of all the two
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 benefit from the
ContributionNature and ContributionType con-
cepts of SYSML/KAOS.
This work motivated us to take benefit 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 refine 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 verified by a test case and then the test case can
be refined by observer and then observer is allocated
to a state machine diagram. This whole sequence of
steps constitute our process.
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 verification us-
ing omega2/ifx, internal report university of toulouse
Apvrille, L., de Saqui-Sannes, P., and Khendek, F. (2006).
Turtle-p: a uml profile for the formal validation of crit-
ical and distributed systems. In Software and Systems
Modeling (SSM ’06). Springer, Volume 5, Issue 4, pp
Benghazi, K., Hurtado, M. V., Rodr
ıguez, M. L., and
Noguera, M. (2009). Applying formal verification
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
Bruel, J. M., Belloir, N., and Ahmad, M. (2009). Un pro-
file sysml pour les systmes auto-adaptatifs. In 15
Colloque National de la Recherche en IUT (CNRIUT
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
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 profile and the tools. In 15th International Con-
ference on Engineering of Complex Computer Systems
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 verification. In In-
ternational Journal on Software Tools for Technology
Transfer (STTT ’06). Springer, Volume 8, Issue 2, pp
Verimag and Irit (2011). OMEGA2-IFx for UML/SysML
v2.0, Profile and Toolset, User Manual Document
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.