Early Analysis of Ambient SystemsSysML Properties using OMEGA2-IFx

Manzoor Ahmad1, Iulia Dragomir1, Jean-Michel Bruel1, Iulian Ober1 and Nicolas Belloir21IRIT, Universite de Toulouse, France

2LIUPPA, Universite de Pau et des Pays de l’Adour, France{ahmad,dragomir,bruel,iulian.ober}@irit.fr, belloir@univ-pau.fr

Keywords:Requirements, Formal Verification, Observers, Relax, Simulation

Abstract:Formal methods provide tools to verify the consistency and correctness of a specification withrespect to the desired properties of the system. This verification is important as the developmentof an AAL (Ambient Assisted Living) system involves different technologies (medical services,surveillance cameras, intelligent devices, etc.) requiring a strong consistency checking betweenmodels. We illustrate in this paper how we prove some of the properties of the system before thedevelopment even starts. To model the AAL system, we use the SysML language. In terms oftools, we used Rational Rhapsody in combination with the OMEGA2 profile which is an executableUml/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 simulationand properties verification of the AAL system.

1 INTRODUCTION

Ambient Assisted Living (AAL) systems are ded-icated to help people with limited capabilities intheir life. This kind of systems, and more specialyall Ambient Systems are highly adaptive. Theymodify their behavior at run-time in responseto changing environmental conditions. For thesesystems, Non Functional Requirements (NFRs)play an important role, and one has to identify asearly as possible the requirements that are adapt-able. The distributed nature of these systems andchanging environmental factors makes it difficultto anticipate all the explicit states in which thesystem will be during its lifetime. As such, theyneeds to be able to tolerate a range of environ-mental conditions and contexts, but the exact na-ture of these contexts remains imperfectly under-stood.

In this context, we focus on two types of sys-tem properties for our AAL case study : Relax-ed and Invariant. These requirements are ob-tained by applying a process called Relax [6]on traditional requirements. Relax is a require-ment engineering language for self-adaptive sys-

tems that incorporates uncertainty into the spec-ification of these systems. Our objective is toprove these properties earlier as possible in thespecification cycle.

By other hand, formal methods are intendedto systemize and introduce rigor into all thephases of software development. This helps us toavoid overlooking critical issues, provides a stan-dard means to record various assumptions and de-cisions, and forms a basis for consistency amongrelated activities. By providing precise and un-ambiguous description mechanisms, formal meth-ods facilitate the understanding required to coa-lesce the various phases of software developmentinto a successful endeavor [1].

In this paper we asses the use of formal meth-ods for the modeling and verification of Ambi-ent Assisted Living (AAL) systems. We use theOMEGA2-IFx approach which has been appliedfor the verification and validation of industry-grade models [2] providing interesting results.The OMEGA2 Uml/SysML Profile [3] definesthe semantics of Uml/SysML elements provid-ing the means to model coherent and unambigu-ous system models. In order to make the mod-

els verifiable, it presents as extension the ob-server mechanism for specifying dynamic proper-ties of models. The OMEGA2 Uml/SysML Pro-file is implemented by the IFx Toolbox [4] whichprovides static analysis, simulation and timed-automata based model checking [5] techniques forvalidation.

This paper takes the reader a step forward andenriches our existing work by integrating formalmethods for the verification of NFRs and spe-cially Relax-ed requirements.

Paper structure. This paper is organized asfollows: Section 2 presents other approaches de-fined for the verification of AAL models, Sec-tion 3 introduces the OMEGA2 Uml/SysMLProfile and the IFx Toolbox that are used formodeling and properties verification, Section 4describes the case study: its specification, systemarchitecture and behavior, Section 5 presents theproperties, the AAL system has to satisfy, whileSection 6 contains the verification and simulationresults, Section 7 concludes the paper and high-lights the future work.

2 Related work

The specification and verification of NFRs in theearly stages of the AAL development cycle is acrucial issue [9]. These systems require clear andprecise specifications in order to describe the sys-tem behavior and its environment. The formalspecification of the system behavior supported bymathematical analysis and reasoning techniquesimprove their development process and enable theverification of these systems.

In [10], the authors present a verification ap-proach based on MEDISTAM-RT which is amethodological framework for the design andanalysis of real-time systems and timed tracesto check the fulfillment of non-functional require-ments. They focus on safety and timeliness prop-erties, to assure the correct functioning of AALsystems and to show the applicability of thismethodology in the context of this kind of sys-tems.

In [11], the authors introduce a profile namedTURTLE (Timed Uml and RT-LOTOS Environ-ment). With its formal semantics given in RT-LOTOS and its toolkit, TURTLE enables a pri-ori detection of design errors through a combi-nation of simulation and verification/validationtechniques. By simulation the authors mean a

partial exploration of the system state space. It isoften used for debugging purposes and to quicklyincrease confidence in a design. For finite statespace systems, exhaustive analysis is also possi-ble. Verification relies on the exploration of thewhole system state space in order to prove ab-sence of deadlocks for instance and other generalproperties that should be satisfied by any system.

In [12], the authors introduce Uppaal whichis a tool box for validation (via graphical sim-ulation) and verification (via automatic model-checking) of real-time systems. It consists oftwo main parts: a graphical user interface and amodel-checker engine. The idea is to model a sys-tem using timed automata, simulate it and thenverify properties on it. Timed automata are finitestate machines with time (clocks). A system con-sists of a network of processes that are composedof locations. Transitions between these locationsdefine how the system behaves. The simulationstep consists of running the system interactivelyto check that it works as intended. Then the ver-ifier check the reachability properties, i.e., if acertain state is reachable or not.

3 THE VERIFICATION TOOLS

In this section, we introduce the OMEGA2 Profilewhich we used for modeling the AAL system andits properties and the IFx toolset used for theverification and simulation of these properties.

3.1 The OMEGA2 UML/SysMLProfile

OMEGA2 is an executable Uml/SysML profilededicated to the formal specification and valida-tion of critical real-time systems. It is based ona subset of Uml 2.2/SysML 1.1 containing themain constructs for modeling system structureand class/block behavior and which provides aclear and coherent operational and timed seman-tics.

The architecture of an OMEGA2 model isdescribed in Class/Block Definition Diagramsby classes/blocks with their relationships (as-sociation, generalization and composition) andtheir interfaces. Each class/block defines prop-erties and operations, as well as a state ma-chine. The hierarchical structure of a model is de-fined in composite structures/Internal Block Di-agrams: parts that communicate through portsand connectors. The Uml/SysML Profile leaves

open several semantic variation points for whichOMEGA2 defines a set of well-formedness rulesthat result in a strong typing language. For fur-ther details on the rules, their rationale and for-malization, the reader is referred to [13].

The behavior of a system is given by the mod-eled state machines that use asynchronous op-eration calls and signal outputs for communica-tion. The profile owns a textual action languagecompatible with Uml 2.2 action metamodel fromwhich implements the main constructs: objectcreation/destruction, expression evaluation, vari-able assignment, signal output and control flowstructuring statements.

The operational semantics of OMEGA2 re-lies on an asynchronous timed execution model.Each class/block is represented by a timed in-put/output automata, potentially executing inparallel with other blocks and communicating viaasynchronous operation calls and signals.

The OMEGA2 Profile can model timed be-havior, where the model time base can either bediscrete or continuous and it is specified by theuser at verification. The time model is controlledby primitives from automata with urgency [14]:clocks, time guards and transition urgency an-notations. The clock is represented by a Timerblock on which we can perform actions as: setfor setting the clock a delay and reset to restorethe clock to 0. Time guards are either describedas inequalities or specified via the timeout opera-tion that verifies that a certain delay has elapsed.With respect to time progress, transitions canalso define a particular semantics based on theirstereotype: eager defines that time progress isdisabled in a state (i.e., the actions on a transitionare executed as soon as possible), delayable meansthat the time progress is enabled but it is boundedby a limit and lazy specifies that time progress isenabled and unbounded (i.e. time can progressto infinity). Based on these notions, one can alsomodel synchronous communication in OMEGA2model.

For specifying and verifying dynamic prop-erties of models, OMEGA2 uses the notion ofobservers. Observers are special classes/blocksmonitoring run-time state and events. Theyare defined by classes/blocks stereotyped with<<observer>>. They may have local memory (at-tributes) and a state machine describes their be-havior. States are classified as <<success>> and<<error>> states to express the (non)satisfactionof safety properties. The main issue in model-ing observers is the choice of events which trigger

their transitions, and which must include specificUml/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 ofactual processing of call – may be differentfrom receive), invokereturn (sending of areturn value), receivereturn (reception ofthe return value), acceptreturn (actual con-sumption of the return value).

• Informal events explicitly specified by themodeller using the informal action.

The trigger of an observer transition is amatch clause specifying the type of event (e.g.,receive), some related information (e.g., the op-eration name) and observer variables that may re-ceive related information (e.g., variables receivingthe values of operation call parameters). Besidesevents, an observer may access any part of thestate of the Uml model: object attributes andstate, signal queues.

3.2 IFx Toolset

OMEGA2 models can be simulated and proper-ties can be verified using the IFx toolset [15]. Thefollowing terminology is used:

Verification: It designates the automatic pro-cess of verifying whether an OMEGA2Uml/SysML model satisfies (some of) theproperties (i.e. observers) defined on it. Theverification method employed in IFx is basedon systematic exploration of the system statespace (i.e., enumerative model checking).

Simulation: It designates the interactive exe-cution of an OMEGA2 Uml/SysML model.The execution can be performed step-by-step,random, or guided by a simulation scenario(for example an error scenario generated dur-ing a verification activity).

The IFx toolset relies on a translation ofUml/SysML models towards a simple specifica-tion language based on an asynchronous compo-sition of extended timed automata, the IF lan-guage1. The translation takes an input model inXMI 2.0 format. The compiler verifies the set ofwell-formedness rules imposed by the profile andgenerates an IF model that can be further reducedby static analysis techniques. This model is sub-ject to verification that either validates the model

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

with respect to its properties or produces a list oferror scenarios that can be further debugged us-ing the simulator. The overall workflow of IFxToolset is shown in Fig. 1 [16].

Figure 1: IFx Workflow

4 MODELING THE AALSYSTEM WITH OMEGA2PROFILE

In this section, we explore the AAL systemspecification, the system architecture showing itsstructural and behavioral diagrams i.e. its blockdefinition diagram, internal block diagrams andstate machine diagrams.

4.1 System Specification

Here is an excerpt of the AAL case study [6]:Mary is a widow. She is 65 years old, overweightand has high blood pressure and cholesterol levels.Following her doctors instructions, she is con-sidering to loose weight. The doctor has recom-mended a hypo caloric diet with low levels of salt.She lives by herself in an AAL house. First, westart by taking into account the structural partof the AAL system. We consider those parts that

are concerned with the daily calories intake of thePatient in the AAL house. The AAL systemis composed of Fridge and Patient. We wouldlike to model these parts and the interaction thattakes place between them. The Fridge partiallycontributes to the minimum liquid intake of thePatient; it also looks at the calories consumptionof the Patient as he/she does not need to exceedit after a certain threshold.

4.2 System Architecture

Fig. 2 shows the main internal block diagram.The important parts of the AAL system arePatient and Fridge. A Fridge in turn is com-posed of Food, Display, Alarm and Controllerblocks. The Food block contains informationabout the food items in the Fridge, the calo-ries contained by each item, the total numberof calories the Patient has accumulated and thecalories threshold that should not be surpassed.The fridge Display is used to show the amountof calories consumed by the Patient. The Alarmis activated in case the Patient’s calories levelsurpasses a certain threshold. The Controllertransfer the information from the Patient to theconcerning elements and back to the environ-ment.

The communication between different blockstakes place through ports. A port bears a type.In OMEGA2, the type of a port must be an In-terface. The type specifies the set of requests (op-eration calls and/or signals) that are transferredbetween parts (components) by means of portsand connectors. In Fig. 2, the Patient block hasa standard port named pToFridge. This port hasa contract named Patient2Fridge and is actingas a provided interface of the Patient block. Theinterface Patient2Fridge defines an operationeat(int item, int quantity). This interfaceis then used as a type of pToFridge port. At thesame time the Patient block has a required in-terface named pFromPatient. For the full systemarchitecture, the reader is referred to [17].

Rational Rhapsody Developer v7.5.22 is usedto create OMEGA2 models. OMEGA2 mod-els use a profile and a predefined libraryprovided with the tool (OMEGA2.sbs andOMEGA2Predefined.sbs). Any other Uml2.2 orSysML1.1 editor supporting profiling and ex-porting in the XMI2.0 standard compatible withEclipse ecore can be used for OMEGA2 models.

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

Figure 2: Main Internal Block Diagram

The Fridge interacts with the AAL system.Fig. 3 shows the internal block diagram for theFridge block. Each of the four blocks behaviorsis modeled in a separate state machine diagram.

Figure 3: Fridge Internal Block Diagram

Fig. 4 shows the state machine diagram forthe Patient block. Here the exchange of infor-mation between Patient and Fridge takes place.We identify the number and quantity of each itempresent in the Fridge. If a certain product stillpresent in the Fridge is chosen by the Patientthen the information is communicated with theFridge. Otherwise the Fridge is empty and thePatient will wait to be refilled. Also, if the Alarmof the Fridge is raised due to high intake of calo-ries, the Patient stops eating and waits for thesystem to be unblocked.

The Food block models the knowledge of theFridge about what it contains. We define thenumber of items and the amount of calories asso-ciated with each item present in the Fridge. Wethen calculate the total number of calories accu-mulated by the Patient. If the total number ofcalories is greater or equal to the maximum calo-ries allowed for the Patient, then a message issent and the alarm is raised or if the total numberof calories is greater than the maximum calories

Figure 4: Patient State Machine Diagram

allowed minus 500, then the Patient is warnedwith a message that the calories level is approach-ing the maximum amount of calories allowed.

5 PROPERTIES VERIFICATIONOF AAL SYSTEM

The properties of AAL system that we modeledand verified are obtained after Relax process isapplied on its traditional requirements. Relaxis a requirement engineering language for self-adaptive systems that incorporates uncertaintyinto the specification of these systems. Typicaltextual requirements prescribe behavior using amodal verb such as SHALL that defines func-tionality that a software system must always pro-vide. For self adaptive systems such as AAL,however, environmental uncertainty may meanthat it is not always possible to achieve all ofthose SHALL statements; or behavioral uncer-tainty may allow for trade-offs between SHALLstatements to Relax non-critical statements infavor of other, more critical ones. Therefore, Re-lax identifies two types of requirements: one thatcan be Relax-ed in favor of other ones calledvariant or Relax-ed and other that should neverchange called invariant. Below are the propertiesto be verified.

5.1 Traditional/Relax-edRequirement

We have studied two Relax-ed requirements:

• The fridge shall detect and communicate withfood packages

Relax-ed version of this requirement is as fol-lows:

• Property 1 : The fridge SHALL detect andcommunicate information with AS MANYfood packages AS POSSIBLE

Below are the uncertainty factors associatedwith the given Relax-ed requirement.

ENV: Food locations, foot item information(type, calories), food state (spoiled and un-spoiled)

MON: RFID readers, Cameras, Weight sensors

REL: RFID tags provide food locations and foodinformation; Cameras provide food locations(Cameras provide images that can be ana-lyzed to estimate food locations), Weight sen-sors provide food information (whether eatenor not)

Figure 5: Property1 State Machine Diagram

The satisfaction of this requirement con-tributes to the balanced diet of the Patient. Wewould like to verify this property as it is impor-tant for the AAL system to know about as manyfood items as possible present in the Fridge.Fig. 5 shows the state machine diagram of theProperty 1. In this property, we identify the num-ber of items consumed by the Patient and thetotal number of items in the Fridge. First ofall, we verify the identity of the Patient, if theperson is identified as the Patient, then we cal-culate the number of items consumed. We thencalculate the number of items left in the Fridge

which is equal to the sum of all the items presentin the Fridge. Then in the last step, we calcu-late if ((total number of items - number of itemsconsumed - number of items left) >-1) and ((to-tal number of items - number of items consumed- number of items left) <1), it means that wehave reached the <<success>> state by havinginformation about all the items present in theFridge, i.e. it should be 0 (which means thatthere is no information loss). Inversely, if it isless than -1 and greater than 1, then it meansthat we are missing information about some ofthe items present in the Fridge and the observerpasses into the <<error>> state.

5.2 Invariant Requirement

We have taken two examples of invariants:

• Property 2 : The alarm SHALL be raised in-stantaneously if the total number of caloriessurpasses the maximum calories allowed forthe patient

Figure 6: Property2 State Machine Diagram

This property ensures that the Patientshould stop eating when the total number of calo-ries surpasses the maximum calories allowed andthat the Alarm should be raised. Fig. 6 shows thestate machine diagram of the property 2. Thisrequirement implies that the Alarm shall be im-mediately raised as soon as the total number ofcalories equals or surpasses the maximum caloriesallowed for the Patient. If it happens then thePatient should stop eating.

6 Verification Results

Until now, we have modeled the AAL system andthe properties to be verified on the model. It isnow time to verify these properties and in caseif there is error during its verification, simulateit to find the error and then correct it in themodel. Fig. 7 shows the snapshot of the compila-tion of the AAL model named AAL2. The AAL2model is first exported into AAL2.xmi and thenusing the IFx toolset the AAL2.xmi is compiledinto AAL2.if.

Figure 7: XMI to IF Compilation

The AAL2.if is then compiled into an ex-ecutable file i.e. AAL2.x. For the proper-ties verification part, we run the model-checkerwith the following options: AAL2.x -dfs -po-me -ce ln

While verifying the AAL model, the model-checker has found several error scenarios. Any ofthe error scenario can then be loaded through theinteractive simulation interface of the IFx toolsetto trace back the error in the model and then cor-rect it. In order to debug a model, firstly we im-

Figure 8: Initial Simulation Interface

port it into the simulator as shown in Fig. 8. Wecheck the states of the observers in order to iden-tify which property has not been satisfied. Onecan observe in Fig. 9 that Property 2 fails. Whilechecking the state of the entire system for thisproperty, we discover that the error state con-tained the maximum allowed number of caloriesfor the total number of calories consumed andsubsequently eat requests sent by the Patient.

This implies that the Alarm function of the in-telligent Fridge doesn’t function properly. TheAlarm function of the Fridge is strictly linked toits Food process and the Alarm is raised only ifthe total number of consumed calories is strictlysuperior than the maximum allowed; conditionwhich doesn’t satisfy the request that the Alarmis raised as soon as possible. The correction con-sists in raising the Alarm in case the total numberof consumed calories is equal to the maximum al-lowed threshold. Once this error is corrected theverification succeeds.

Figure 9: Error State Food Observer Simulation In-terface

Figure 10: Model checking successful

Fig. 10 shows the result of the model-checkeron the correct model.

7 Conclusion

We have modeled the structural and behavioralparts of an AAL (Ambient Assisted Living) sys-tem. The modeling is done using Rational Rhap-sody 7.5.2 with OMEGA2 profile which is used forspecification and verification of dynamic proper-ties of models through observers. For the verifica-tion and simulation part, we have used IFx whichis a toolset used for the simulation of OMEGA2models and the verification of properties definedon these models. We have verified two propertiesof the AAL system using the IFx toolset. At first,the verification results in errors which can then besimulated through the interactive simulation in-terface of the IFx toolset in order to identify thesource of the error and then subsequently correctit in the model, after correcting the error in the

model, the verification results in the fulfillment ofall the two properties.

The future work is centered around the use offormal methods in the context of our integratedapproach [18].

In [7], we have investigated the use of goaloriented concepts in combination with Relaxfor modeling the requirements of ambient sys-tems. We have found a link between Re-lax and SysML/Kaos [8], which is a goal ori-ented approach based on Kaos and which ex-tends the SysML meta-model with goal con-cepts. Based on that, we have concluded thatthese two approaches are complementary witheach other and Relax can benefit from theContributionNature and ContributionTypeconcepts of SysML/Kaos.

This work motivated us to take benefit fromthe OMEGA2/IFx. In our integrated approach,we are interested in Relax requirement whichwe obtain by using the Relax process. Wethen refine the Relax requirement with theContributionType and ContributionNature ofSysML/Kaos which is a SysML profile with thegoal concepts integrated into it, the reader is re-ferred to [7] for an insight on our work on Relaxand SysML/Kaos. The Relax requirement isthen verified by a test case and then the test casecan be refined by observer and then observer is al-located to a state machine diagram. This wholesequence of steps constitute our process.

REFERENCES

[1] http://www-2.cs.cmu.edu/~svc/

[2] Iulia Dragomir, Iulian Ober and DavidLesens. A Case Study in Formal System En-gineering with SysML, ICECCS 2012,Pages:189 - 198.

[3] Iulian Ober and Iulia Dragomir.OMEGA2: A new version of the pro-file and the tools, ICECCS 2010, DOI10.1109/ICECCS.2010.59.

[4] Iulian Ober, Susanne Graf and Ileana Ober.Validating timed Uml models by simula-tion and verification, International Journal onSoftware Tools for Technology (2006) 8(2):128145

[5] E. M. Clarke, O. Grumberg, and D. A. Peled,Model Checking. MIT Press, 1999.

[6] Jon Whittle, Pete Sawyer, Nelly Bencomo,Betty H.C. Cheng, and Jean-Michel Bruel.

Relax : Incorporating Uncertainty into theSpecication of Self-Adaptive systems,RE Con-ference 2009, Pages: 79-88.

[7] Manzoor Ahmad, Jean Michel Bruel, RegineLaleau and Christophe Gnaho. Using RE-LAX, SysML and KAOS for Ambient SystemsRequirements Modeling, Procedia ComputerScience Volume 10, 2012, Pages 474481.

[8] Christophe Gnaho, Farida Semmak. Une ex-tension SysML pour l’ingenierie des exi-gences non-fonctionnelles orientee but. RevueIngenierie des Systemes d’Information, Vol16/1, 23 pages, 2011.

[9] Kawtar Benghazi, Marıa Visitacion Hurtado,Marıa Luisa Rodrıguez, Manuel Noguera. Ap-plying Formal Verification Techniques to Am-bient Assisted Living Systems, OTM 2009Workshops, pp 381-390.

[10] Jurgen Nehmer, Martin Becker, ArthurKarshmer and Rosemarie Lamm. Living as-sistance systems: an ambient intelligence ap-proach, ICSE ’06, Pages 43-50.

[11] Ludovic Apvrille, Pierre de Saqui-Sannes,Ferhat Khendek. TURTLE-P: a Uml profilefor the formal validation of critical and dis-tributed systems, Software and System Mod-eling 5(4): 449-466 (2006).

[12] http://www.it.uu.se/research/group/darts

[13] I. Ober and I. Dragomir, “UnambiguousUml Composite Structures: The OMEGA2Experience,” in SOFSEM 2011: Theory andPractice of Computer Science, Springer,2011, vol. 6543, pp. 418–430.

[14] S. Bornot and J. Sifakis, “An algebraicframework for urgency,” Information andComputation, vol. 163, 2000.

[15] M. Bozga, S. Graf, I. Ober, I. Ober, andJ. Sifakis, “The IF Toolset,” in Formal Meth-ods for the Design of Real-Time Systems,Springer, 2004, vol. 3185, pp. 131–132.

[16] OMEGA2-IFx for Uml/SysML v2.0 Profileand Toolset, User Manual Document v1.1

[17] Manzoor Ahmad, Iulia Dragomir. AAL Sys-tem Properties Modeling and Verification Us-ing OMEGA2/IFx, Internal Report, Univer-site de Toulouse.

[18] Jean-Michel Bruel, Nicolas Belloir and Man-zoor Ahmad. SPAS: un profile SysML pourles systemes auto-adaptatifs, CNRIUT, LilleJune 2009.