Final Report on the Device Controller-Monitor Project | Pacemaker...

MFES

Formal Methods for Software Engineering

Final Report on theDevice Controller-MonitorProject — Pacemaker BSC Theme

Andre Martins PG15142Joao Bordalo PG15141Nelson Goncalves PG15395

2 DCM Project — Final Report

1 Introduction

1.1 Problem Description and Approach

Formal methods are mathematical based techniques used in computer science for the specification,development and verification of software applications. Formal methods are used to create and buildapplications less prone to errors and as such, more robust and reliable. There are several kindsof formal methods and several uses for them as well. In this document we explain how we usedspecification formalisms to build a model of the Device Controller-Monitor and to demonstratethat such a model met the requirements we have been given.

The Device-Controller Monitor is what programs and queries the pacemaker allowing thephysician to change the operating mode or the parameters of the pacemaker in a non-invasivemanner. The DCM consists in an hardware platform and software to interact with the pacemaker,it has many features such as acquire and show the history of the pacemaker, acquire and showlead measurement information and sensor history, print reports, show the status of the battery,etc.

The Device Controller-Monitor is part of the requirements for the Pacemaker Grand Challenge.In such a context, our challenge was to build a formal model of the DCM according to therequirements presented in [10].

Because there is almost no documentation about this kind of interfaces, an initial part of ourwork was to establish contact with the town Hospital (Sao Marcos Hospital, in Braga). We visitthe relevant hospital service to be introduced to the use of a concrete DCM and build a generalidea about the way it works. After talking to a physician who gave us an opportunity to watcha working DCM we wrote a first draft about what we had seen. In that draft we registered amain window, divided into two sub windows. The the first sub-window was where the informationabout the sensors was shown in real-time the in the form of a graphic. The second sub-windowhad several tabs where the pacemaker’s parameters where shown and controlled. This first visitshaped our understanding of the interface and lead a definite mark in the following work.

Two main formal tools were used in meeting this group challenge: AADL [11], as a formal-ism for architectural description, and UPPAAL [1], a model-checker for systems with real-timerequirements.

AADL which is short for Architecture Analysis and Design Language is a SAE standardizedlanguage. It was first introduced in the avionics field in November 2004 by the Society of Auto-motive Engineers. The language uses formal modeling concepts to describe and analyze both thehardware and the software components of a system and the way they interact. Using AADL wecan model real-time systems and as such AADL was thought an appropriate tool to model theDCM. This required, however, the use of AADL Behavior Annex (BA) in order to specify thebehavior of the system components without resorting to any sort of concrete model and specificprogramming language.

Both AADL and BA are intended for modeling purposes. Verification must be carried on adifferent platform and UPPAAL was chosen for such a proposal.

UPPAAL is a tool for modeling, validating and verifying real time systems, modeled as networksof timed automata. It uses a simplified version of Computation Tree Logic, CTL, extended withsome data types (integers,arrays,etc). Notice that, on contrary to full CTL, UPPAAL formulae,used in verification, does not allow for nesting of path formulae.

Our DCM model abstracts itself from the hardware parts and concentrates only on the interfacepart. It should be stressed, however, that our model does not contemplate many aspects that aresometimes considered in interface design (for example, colors, fonts, windows displacement, etc).Our choice was clearly other: to focus on more on the functionality, rather than on appearance.

1.2 Report Structure

The rest of this report is structured as follows. Section 2 reviews briefly the tools used: AADLand UPPAAL. In section 3 we talk about the way our models satisfy the requirements present in

DCM Project — Final Report 3

[10] and afterwards we show some of the properties we proved in our UPPAAL model. Finally insection 4 we make a global appreciation of our work and the tools we have used and then we talka little bit about what can be done in the future to improve what we have done.

2 Background

2.1 AADL

The AADL standard [11] provides formal modeling concepts for the description and analysis of ap-plication systems architecture in terms of distinct components and their interactions. The AADLincludes software, hardware, and system component abstractions. In particular, it allows the map-ping of software components onto computational hardware elements, as well as the specificationand analysis of real-time systems.

Within AADL, a component is characterized by its identity, possible interfaces with othercomponents and subcomponents and their interactions. In addition to interfaces and internalstructural elements, other abstractions can be defined for a component and system architecture.The elements from which those abstractions are built can be in the core AADL language or beadded through a supplemental annex language. The component abstractions of AADL can bedivided into three categories:

1. Application Software• thread: active component that can execute concurrently and be organized into thread

groups• thread group: component abstraction for logically organizing thread, data, and thread

group components within a process• process: protected address space whose boundaries are enforced at runtime• data: data types and static data in source text• subprogram: concepts such as call-return and calls-on methods (modeled using a sub-

program component that represents a callable piece of source code)2. Execution Platform (hardware)• processor: schedules and executes threads• memory: stores code and data• device: represents sensors, actuators, or other components that interface with the external

environment• bus: interconnects processors, memory, and devices

3. Composite• system design elements that enable the integration of other components into distinct units

within the architecture

System components are made of various parts that consist of other systems as well as software orhardware components. In addition flows of information between the components can be defined,as well as what types of data are transmitted between them. In the standard AADL this is donethrough the specification of:

• message passing• event passing• synchronized access to shared components• thread scheduling protocols• remote procedure calls

AADL components interact exclusively through defined interfaces. A component interface con-sists of a directional flow through:

• data ports for enqueued state data• event data ports for queued message data• event ports for asynchronous events


• synchronous subprogram calls

• explicit access to data components

The AADL can be used to model and analyze new systems or systems that already exist. Itcan be used to do a partially analysis of such systems as well as a full-scale analysis. AADL alsosupports early prediction and analysis of system properties such as performance, scheduling andreliability.

In AADL, the components are defined through type and implementation declarations. Thecomponent type declaration is where the interface’s elements and externally observable attributesare defined. The component implementation details the internal structure. In other words, it iswhere the subcomponent connections, subprogram call sequences, flow of data and properties aredefined. Fig. 1 shows the diverse subclauses of a type declaration: Features are the interfaces ofa component; Flows specify distinct abstract channels of information transfer and Propertiesdefines the characteristics of the component. The extends clause allows for one component typeto use another component type already available, just as in JAVA [8].

!"#$%&'()*(++,-(-.'/0./"(+12$3.#$%&'2(

8 CMU/SEI-2006-TN-011

3.1 Components

4&56&'"'$2(7&35($8"(#"'$3.9(5&:"9%'/(;&#.109.3<(7&3($8"(++,-=(4&56&'"'$2(.3"(.22%/'":(.(0'%>0"(%:"'$%$<(?'.5"@(.':(.3"(:"#9.3":(.2(.($<6" .':(implementation(A%$8%'(.(6.3$%#09.3(#&56&'"'$(#.$"/&3<=(+(#&56&'"'$(#.$"/&3<(:"7%'"2($8"(30'$%5"("22"'#"(&7(.(#&56&'"'$=(B8"3"(.3"($83""(:%2$%'#$(2"$2(&7(#&56&'"'$(#.$"/&3%"2*(

C= .669%#.$%&'(2&7$A.3"(

.= $83".:*(.(2#8":09.19"(0'%$(&7(#&'#033"'$("D"#0$%&'(

1= $83".:(/3&06*(.(#&56&2%$%&'.9(0'%$(7&3(&3/.'%E%'/($83".:2((

#= 63&#"22*(.(63&$"#$":(.::3"22(26.#"((

:= :.$.*(:.$.($<6"2(.':(2$.$%#(:.$.(%'(2&03#"($"D$(

"= 20163&/3.5*(#.99.19"(2">0"'$%.99<("D"#0$.19"(#&:"((

F= ("D"#0$%&'(69.$7&35(

.= 63&#"22&3*(#&56&'"'$2($8.$("D"#0$"($83".:2((

1= 5"5&3<*(#&56&'"'$2($8.$(2$&3"(:.$.(.':(#&:"(

#= :";%#"*(#&56&'"'$2($8.$(%'$"37.#"(A%$8(.':(3"63"2"'$($8"("D$"3'.9("';%3&'5"'$((

:= 102*(#&56&'"'$2($8.$(63&;%:"(.##"22(.5&'/("D"#0$%&'(69.$7&35(#&56&'"'$2(

)= #&56&2%$"((

.= 2<2$"5*(.(#&56&2%$"(&7(2&7$A.3"G("D"#0$%&'(69.$7&35G(&3(2<2$"5(#&56&'"'$2(

H.#8(&7($8"(#&56&'"'$(#.$"/&3%"2(%2(:%2#022":(%'(2"6.3.$"(2"#$%&'2(&7($8%2(:&#05"'$=(B8"(2<'$.D(.':(2"5.'$%#2(&7(:"#9.3.$%&'2(%'(.'(++,-(26"#%7%#.$%&'(.3"(:%2#022":(%'(!"#$%&'(I=C=(

3.2 Component Types

+'(++,-(#&56&'"'$($<6"(:"#9.3.$%&'("2$.19%28"2(.(#&56&'"'$J2("D$"3'.99<(;%2%19"(#8.3.#$"3%2$%#2=(K&3("D.569"G(.(:"#9.3.$%&'(26"#%7%"2($8"(%'$"37.#"2(&7(.(thread(#&56&'"'$=(+(#&56&'"'$($<6"(:"#9.3.$%&'(#&'2%2$2(&7(.(:"7%'%'/(#9.02"(.':(:"2#3%6$%;"(201#9.02"2L(K%/03"()MF(28&A2(.($<6"(:"#9.3.$%&'(&7(.(thread=(Features(.3"($8"(%'$"37.#"2(&7($8"(#&56&'"'$=(Flows(26"#%7<(:%2$%'#$(.12$3.#$(#8.''"92(&7(%'7&35.$%&'($3.'27"3=(Properties(:"7%'"(%'$3%'2%#(#8.3.#$"3%2$%#2(&7(.(#&56&'"'$=(B8"3"(.3"(63":"7%'":(properties(7&3(".#8(#&56&'"'$(#.$"/&3<(?"=/=G($8"("D"#0$%&'($%5"(7&3(.(thread@=((

(Figure 3-2: Subclauses of a Type Declaration

thread <name> extends features flows properties

Fig. 1: Subclauses of a Type Declaration

In Fig.2, the diverse subclauses of a implementation declaration are shown. The subcom-ponents, connections, and calls declarations specify the composition of a component and theirinteractions. Flows represent implementations of flow specifications in the component type or end-to-end flows to be analyzed (i.e., flows that start in one subcomponent, go through zero or moresubcomponents, and end in another subcomponent). The Modes subclause represents alterna-tive operational modes that consist of alternate configurations of subcomponents, calls sequences,connections, flow sequences, and properties. Properties is where intrinsic characteristics of a com-ponent are defined. One can declare multiple implementations of a component type, such that eachimplementation provides a realization of a component that satisfies the same interface specifiedby the component type. In addition, a component implementation may extend and refine otherpreviously declared component implementations. Implementations may also be extended (usingthe extends subclause) which results in inheriting the characteristics of the original componentimplementation and all of its predecessors.

!"#$%&'()*(++,-(-.'/0./"(+12$3.#$%&'2(

CMU/SEI-2006-TN-011 9

45"(extends(201#6.02"("'.16"2(&'"(#&78&'"'$($98"(:"#6.3.$%&'($&(10%6:(08&'(.'&$5"3;(+(#&78&'"'$(:"#6.3":(.2(.'("<$"'2%&'(%'5"3%$2($5"(#5.3.#$"3%2$%#2(&=($5"(&3%/%'.6(#&78&'"'$(

>%;";?(%$(%2(.(201#6.22(&=($5"(&3%/%'.6@;(A%$5%'(.(#&78&'"'$(:"#6.3":(.2(.'("<$"'2%&'(&=(.'&$5"3(

$98"?(%'$"3=.#"2?(=6&B2?(.':(83&8"3$%"2(#.'(1"(.::":C(8.3$%.669(:"#6.3":("6"7"'$2(&=($5"(

.'$"#":"'$(#&78&'"'$($98"(#.'(1"(:"$.%6":C(.':(83&8"3$%"2(#.'(1"(7&:%=%":(>3"=%'":@;(45"2"(

D0.6%$%"2(8"37%$($5"(7&:"6%'/(&=(E.3%.$%&'2(%'($5"(%'$"3=.#"2(&=(.(=.7%69(&=(3"6.$":(

#&78&'"'$2;((

3.3 Component Implementations

+(#&78&'"'$(implementation(28"#%=%"2(.'(%'$"3'.6(2$30#$03"(%'($"372(&=(subcomponents?(%'$"3.#$%&'2(>calls(.':(connections@(.7&'/($5"(features(&=($5&2"(subcomponents?(flows(.#3&22(.(2"D0"'#"(&=(subcomponents?(modes($5.$(3"83"2"'$(&8"3.$%&'.6(2$.$"2?(.':(properties;((

45"(201#6.02"2(&=(.'(implementation(:"#6.3.$%&'(.3"(2077.3%F":(%'(G%/03"()H);(45"(subcomponents?(connections?(.':(calls(:"#6.3.$%&'2(28"#%=9($5"(#&78&2%$%&'(&=(.(#&78&'"'$(.2(.(#&66"#$%&'(&=(#&78&'"'$2(>subcomponents@(.':($5"%3(%'$"3.#$%&'2;(Flows(3"83"2"'$(%786"7"'$.$%&'2(&=(=6&B(28"#%=%#.$%&'2(%'($5"(#&78&'"'$($98"(&3("':H$&H"':(=6&B2(

$&(1"(.'.69F":(>%;";?(=6&B2($5.$(2$.3$(%'(&'"(201#&78&'"'$?(/&($53&0/5(F"3&(&3(7&3"(

201#&78&'"'$2?(.':("':(%'(.'&$5"3(201#&78&'"'$@;(Modes(3"83"2"'$(.6$"3'.$%E"(&8"3.$%&'.6(7&:"2($5.$(7.9(7.'%="2$($5"72"6E"2(.2(.6$"3'.$"(#&'=%/03.$%&'2(&=(subcomponents?(calls(2"D0"'#"2?(connections?(flow(2"D0"'#"2?(.':(properties;(Properties(:"=%'"(%'$3%'2%#(#5.3.#$"3%2$%#2(&=(.(#&78&'"'$;(45"3"(.3"(83":"=%'":(properties(=&3(".#5(#&78&'"'$(implementation;(

(

Figure 3-3: Subclauses of an Implementation Declaration

I06$%86"(%786"7"'$.$%&'2(&=(.(#&78&'"'$($98"(#.'(1"(:"#6.3":?(.66&B%'/(706$%86"(E.3%.'$2(

B%$5($5"(2.7"("<$"3'.6(%'$"3=.#"2($&(1"(7&:"6":(1"#.02"(".#5(implementation(83&E%:"2(.(3".6%F.$%&'(&=(.(#&78&'"'$($5.$(2.$%2=%"2($5"(2.7"(%'$"3=.#"(28"#%=%":(19($5"(#&78&'"'$(

$98";(J'(.::%$%&'?(.(#&78&'"'$(implementation(7.9("<$"':(.':(3"=%'"(&$5"3(83"E%&0269(:"#6.3":(#&78&'"'$(%786"7"'$.$%&'2;(K<$"':":(%786"7"'$.$%&'2(>:"#6.3":(B%$5($5"(

extends 201#6.02"@(%'5"3%$($5"(#5.3.#$"3%2$%#2(&=($5"(&3%/%'.6(#&78&'"'$(implementation(.':(.66(&=(%$2(83":"#"22&32;(L"=%'"7"'$(.66&B2(8.3$%.669(28"#%=%":(

(thread implementation <typeidentifier>.<implementationidentifier> extends refines type subcomponents calls connections flows modes properties

Fig. 2: Subclauses of a Implementation Declaration


Fig 3 depicts a summary of AADL elements and their relationships.

!"#$%&'()*(++,-(-.'/0./"(+12$3.#$%&'2(

CMU/SEI-2006-TN-011 7

3 AADL Language Abstractions

45"(#&3"(6.'/0./"(#&'#"7$2(.'8(9":(27"#%;%#.$%&'("6"<"'$2(&;(++,-(.3"(20<<.3%="8(%'(>%/03"()?@A(B'(++,-C(#&<7&'"'$2(.3"(8";%'"8($53&0/5($:7" .'8(implementation(8"#6.3.$%&'2A(+(Component Type(8"#6.3.$%&'(8";%'"2(.(#&<7&'"'$D2(%'$"3;.#"("6"<"'$2(.'8("E$"3'.66:(&12"3F.16"(.$$3%10$"2(G%A"AC(;".$03"2($5.$(.3"(%'$"3.#$%&'(7&%'$2(H%$5(&$5"3(

#&<7&'"'$2C(;6&H(27"#%;%#.$%&'2C(.'8(%'$"3'.6(73&7"3$:(F.60"2IA((+(Component Implementation(8"#6.3.$%&'(8";%'"2(.(#&<7&'"'$D2(%'$"3'.6(2$30#$03"(%'($"3<2(&;(subcomponentsC(201#&<7&'"'$(connectionsC(subprogram(#.66(2"J0"'#"2C(modesC(flow(%<76"<"'$.$%&'2C(.'8(propertiesA((Components(.3"(/3&07"8(%'$&(.776%#.$%&'(2&;$H.3"C("E"#0$%&'(76.$;&3<C(.'8(#&<7&2%$"(#.$"/&3%"2A(Packages("'.16"($5"(&3/.'%=.$%&'(&;(++,-("6"<"'$2(%'$&('.<"8(/3&072A(Property Sets(.'8(Annex Libraries("'.16"(.(8"2%/'"3($&("E$"'8($5"(6.'/0./"(.'8(#02$&<%="(.'(++,-(27"#%;%#.$%&'($&(<""$(73&K"#$?(&3(8&<.%'?

27"#%;%#(3"J0%3"<"'$2AL((

Component implementation identifier• extends {component implementation}• refines type• subcomponents• connections• call sequences• modes • flows• properties

Component implementation identifier• extends {component implementation}• refines type• subcomponents• connections• call sequences• modes • flows• properties

Component type• component category• extends• features (is)• subcomponents (requires)

Component type• component category• extends• features (is)• subcomponents (requires)

• port• access• parameter

• ports• access• subprogram• parameter

Component Type identifier

• extends {component_type}• features • flows• properties

Component Type identifier

• extends {component_type}• features • flows• properties

Packagepublic- declarationsprivate- declarations

Packagepublic- declarationsprivate- declarations

• modes• mode transitions

Property Setproperty typesproperty definitionsconstants

Property Setproperty typesproperty definitionsconstants

AnnexLibrary

AnnexLibrary

more details references implements

Components• data• subprogram• thread• thread group• process

• memory• device• processor• bus

• system

Legend

(Figure 3-1: Summary of AADL Elements

(((((((((((((((((((((((((((((((((((((((((((((((((L(( Annex libraries("'.16"(.(8"2%/'"3($&("E$"'8($5"(6.'/0./"(.'8(#02$&<%="(.'(++,-(27"#%;%#.$%&'($&(<""$(73&K"#$?(&3(8&<.%'?27"#%;%#(3"J0%3"<"'$2A(+'(annex(document(%2(.'(.773&F"8("E$"'2%&'($&($5"(#&3"(++,-(2$.'8.38A(

Fig. 3: Summary of AADL Elements

An AADL Model can be made using three different representations, its specification and dec-larations can be expressed textually, graphically, as in eXtensible Markup Language (XML), oras a combination of the three, as shown in Fig.4 .


!"#$%&'()*(++,-(!./$"0(1&2"3/(4'2(!5"#%6%#4$%&'/(

CMU/SEI-2006-TN-011 11

4 AADL System Models and Specifications

+'(++,-(/./$"0(0&2"3(2"/#7%8"/($9"(47#9%$"#$:7"(4'2(7:'$%0"("';%7&'0"'$(&6(4'(4553%#4$%&'(/./$"0(%'($"70/(&6(%$/(#&'/$%$:"'$(/&6$<47"(4'2("="#:$%&'(534$6&70(>9472<47"?(#&05&'"'$/(4'2($9"%7(%'$"74#$%&'/@(+'(++,-(0&2"3(%/(#45$:7"2(%'(4(/5"#%6%#4$%&'(#&'/%/$%'A(&6(/.'$4#$%#433.(4'2(/"04'$%#433.(#&77"#$(++,-(2"#3474$%&'/@(+(#&053"$"(++,-(/./$"0(0&2"3(%'#3:2"/(433(&6($9"(2"#3474$%&'/(7"B:%7"2($&(%'/$4'$%4$"(4(7:'$%0"(%'/$4'#"(&6(4'(4553%#4$%&'(/./$"0($94$($9"(/5"#%6%#4$%&'(7"57"/"'$/(>"@A@C(4'(4%7#746$D/(63%A9$(#&'$7&3(/./$"0?@((

E7&0(4(:/"7(5"7/5"#$%;"C(4'(++,-(/5"#%6%#4$%&'(4'2(%$/(#&'/$%$:"'$(2"#3474$%&'/(#4'(8"("=57"//"2($"=$:433.C(A7459%#433.C(%'(4(#&08%'4$%&'(&6($9&/"(7"57"/"'$4$%&'/C(&7(4/(F=$"'/%83"(147G:5(-4'A:4A"(>H1-?@(I9"(++,-($"=$:43(4'2(A7459%#43('&$4$%&'/(47"(2"6%'"2(8.($9"(!+F(++,-(/$4'2472(4'2(%$/("=$"'/%&'/(J!+F(KL4M@(I9"(H1-(6&70(%/(2"6%'"2(%'(Extensible Markup Language (XML) 1.0 (Third Edition)(JNOP(K)M@(E%A:7"()QR(/:0047%S"/($9"(43$"7'4$%;"(7"57"/"'$4$%&'/(&6(4'(++,-(/5"#%6%#4$%&'C(/9&<%'A(/4053"($"=$:43C(A7459%#43C(4'2(H1-(7"57"/"'$4$%&'/@(

(

(Figure 4-1: AADL Representations

XML <threadType name="data_processing"> <features> <dataPort name="raw_speed_in"/> <dataPort name="speed_out" direction="out"/> </features>

thread data_processing features raw_speed_in: in data port; speed_out: out data port; Properties Period => 20 ms; end data_processing;

AADL Graphical

data_processing

AADL Textual 20 ms

Fig. 4: AADL Representations

it should also be mentioned that AADL supports annexes that extend the language, allowingfor the incorporation of specialized notations within the standard AADL model. There are variouskinds of annexes for AADL (security, reliability, behavior, error). In this report, however, weresorted only to the behaviour annex.

The Behavior Annex (BA) extends the regular AADL with mechanisms to define the behaviorof the components. For example with BA it is possible to declare variables and clocks, which canbe used in guards between component transitions , either to restrain or to reflect the occurrenceof the transition.

2.2 UPPAAL

The idea behind the UPPAAL tool is to provide a framework for modeling, simulation and veri-fication of properties of a timed automata through a graphical interface. UPPAAL was created in1995 in Uppsala University and Aalborg University [4] .

UPPAAL is a real-time verification tool which explores basic results on decidability of modelchecking for real-time systems with dense time. The tool provides support for automatic verifica-tion of safety and bounded liveness properties, on top of a model-checking engine for a variant ofCTL. Furthermore it contains a number of additional features including graphical interfaces fordesigning and simulating system models. To model timed automata, UPPAAL provides a descrip-tion language and a visual interface through which the user can create automata templates, defineguards and invariants and specify instances and their composition. Integers and arrays are someof the data types the language grants. In general, its syntax is very close to (a subset of) C.

A UPPAAL model consists of a network of timed automata extended with discrete variables.The current state of an automaton incorporates the values of the declared clocks and variables.

Even though UPPAAL only uses a simplified version of CTL, not including, in particular,nesting of path formulae, it provides the following additional features on top of a model-checkingengine for this logic:

• Templates In UPPAAL templates are used to represent each automata individually withparameters(optionally). Parameters are a set of declarations of any type of variables existentwithin UPPAAL.

• Constants Are declared with the reserved word cons followed by the type. A constant cannotbe changed during execution time.


• Bounded Integer Variables When we want to change the default minimum and maximumvalue an integer value can take. By default an integer value can take any value between -32768and 32767.• Functions UPPAAL allows us to use functions which are very syntactically very similar to

C’s functions. We can use these functions when we have to do complex operations for exampleduring state transitions.• Urgent Location These are locations where the local clocks’ of that automata remain un-

changed, i.e time does not pass.• Committed Location A committed location is similar to urgent location but extends it by

imposing that the automata’s next transition origin has to be in a location of this kind.• Arrays Used for channels, clocks and integers.• Binary Channels Used to achieve synchronization between two endpoints, the sender and

the recipient (the sender blocks without a recipient).• Broadcast Channels Used to achieve synchronization between various endpoints. A sender

broadcasts a message to several recipients (the sender does not block if there are no recipients).• Urgent Channels Both types of channels previously mentioned can become a urgent channel

with the use of the urgent keyword. In this type of channels, guards about the clocks are notcontemplated in the transitions.

Modeling in UPPAAL can be made either textually or resorting to a graphical interface. Weshall concentrate in the graphical interface, as used in this project.

Fig. 5: Graphical Interface of UPPAAL

As can be seen in Fig. 5, the user interface is composed by three tabs (Editor,Simulator andVerifier). The editor is where we can build the networks of timed automata in a quick and easyway. The simulator is where we can follow the system execution and easily find possible bugs.


Finally, the verifier is where we can test the model for specific properties, such as reachability,safety and liveness. Such properties are expressed either by State Formulae or Path Formulae.

• State Properties These properties are relative to specific states in the model, the formerbeing identified by notation P .l (meaning that a process P is in location l). UPPAAL alsoprovides a special formula deadlock, which is not satisfied if there are no outgoing transitionsfrom a state;

• Reachability Properties These are the simplest form of properties, they only ask whethera given state formula ω can possibly be satisfied by any reachable state (EFω in CTL and inUPPAAL E <> ω;

• Safety Properties Safety properties state that something will always (or never) happen(AGω in CTL, A[]ω in UPPAAL) or that something will eventually happen ( EGω in CTLand E[]ω in UPPAAL);

• Liveness Properties In its simpler form, liveness is expressed as A <> ω (AFω in CTL)which means that something will eventually happen, i.e., that ω will be satisfied . Anotheruseful form of a liveness property is ψ ω which means whenever ψ is satisfied, ω willeventually be satisfied ( ψ - -> ω in UPPAAL and AG(ψ =⇒ ω) in CTL).

3 Development

3.1 Approach

We adopted an incremental approach to the design of DCM, iterating through several stages. Thefirst phase was devoted to document reading and complementary requirements elicitation througha direct contact with the local Hospital, as mentioned in the Introduction. This first phase lead toa very simple model of the Interface. As time went by our model started to become a little moredetailed but it never became over specified because a good model never does.

Modeling a system consists of identifying and precisely characterizing the sys-tem’s entities and behavioral rules governing them that are relevant for thereasoning or problems in hand. A model needs to be tractable in that it shouldnot encompass uninteresting details that would impair the desired analysis and,at the same time, it needs to be accurate so that it captures all attributes af-fecting the phenomena of interest. [9]

Our first abstract model was written on a piece of paper: it represented the several componentswe have identified from the requirements and a specification of how they would communicate. Thenwe started to build an AADL model one component at a time.

The second phase was concerned with the specification of the the behavior of various com-ponents. Our idea was to make a detailed behavior model in BA for each component and thenuse AADLtoTASM [2] to convert the AADL-BA model with behavior annex into TASM (TimedAbstract Stateless Machines) [7]. From there we would resort to UPPAAL and the TASM Toolsetto analyze the generated TASM (see Fig. 6). This, in itself, was not new: a similar approach wasused in [2] and [6], respectively, but the path seemed promising.

Unfortunately all our attempts to grant access to the AADLtoTASM tool failed; not a singleanswer were ever obtained from the webpage contact or any attempt to directly reach the teaminvolved. A contingency plan was, therefore, put forward: we decided to keep the AADL-BA modelin a high abstract level, to serve as an architectural guide to the DCM design, and to perform allsubsequent steps directly in UPPAAL. Therefore, UPPAAL was used, from that stage on, in twotwin ways: to refine the DCM model (modeling) and to state and verify its properties (verification).


Fig. 6: The initial plan: combining AADL and UPPAAL

3.2 Modeling

Example requirements captured in both UPPAAL and AADL models

In this subsection we discuss the ways in which our combined UPPAAL and AADL models ofthe DCM respect the the most relevant requirements originally given. Rather than being exhaus-tive, we opted for pointing out a few relevant issues in this process. Later, we will come back thespecification of the relevant properties.

Listing 1: The User interface shall be capable of utilizing and managing windows for display oftext and graphics

Our AADL model incorporates this requirement in the swing thread (see Fig. 7). It receives thegraph data through the in graph port and receives the text data through the in settings port. Oncethe swing thread receives that data it is presented to the user through the appropriate windows

Fig. 7: Swing Thread

In UPPAAL, as it can be seen in Fig. 8, the corresponding automata takes care of the graphicalcomponent. We assumed the text part is concerned with the parameters of the pacemaker; this ishandled through variables which correspond to such parameters (see Fig. 9).

Listing 2: The user interface shall be capable of processing user positioning and input buttons

The AADL model has an event port called click event that contemplates this as shown inFig. 7. The UPPAAL model, on its turn, consists of an automata (see Fig. 10) offering severalpossible states (Reports, Modes, Tests, etc) to the user choice.

Listing 3: The user interface shall be capable of displaying all programmable parameters for reviewand modification.


Fig. 8: Graphics Automata

Fig. 9: Pacemaker parameters variables

Fig. 10: Interface Automata


In the AADL model (Fig. 7) a in settings Data Port and a out settings Data Port were definedboth in the Swing Thread (as depicted in Fig. 7). The in settings port receives the parametersfrom the pacemaker, the Swing Thread then shows them for modification. Once modified they aresent back to the pacemaker via the out settings port.

The UPPAAL model has a Modes automata (Fig. 11) with states show and update corre-sponding to the visualization and updating of the programmable parameters.

Fig. 11: Modes Automata

Listing 4: The user interface shall be capable of visually indicating when the DCM and the deviceare communicating.

The AADL model includes a variable that reflects the connected state. When a pacemaker isconnected this variable is set to true, and when the pacemaker disconnects the variable is set tofalse. The same happens in the UPPAAL model.

Listing 5: The user interface shall be capable of visually indicating when a different PACEMAKERdevice is approached than was previously interrogated.

In both the AADL and the UPPAAL models each pacemaker has an unique identifier. In theAADL model (Fig. 12) when a new pacemaker is detected the Listener component notifies theInterface through the pacListNot port; the user is then notified by the interface.

The UPPAAL model includes a Listener Automata (Fig. 13) that is constantly broadcastingping messages, in order to detect any pacemaker active in the neighborhood. On receiving thismessage, a pacemaker is supposed to answer with a pong message which contains its identifier.When the Listener receives such a reply, if the pacemaker’s identifier is new, the user is notified.

Listing 6: The About function should display various parameters about the Application

Both the UPPAAL and the AADL models have static variables that are store that information.


Fig. 12: AADL Model of the DCM

Fig. 13: Listener Automata


Example requirements captured only in the UPPAAL final model

As previously explained, we started modeling the DCM in AADL, but when we realized theimpossibility of resorting to some sort of automatic translation to UPPAAL for property verifica-tion, we decided to focus exclusively in producing the final DCM model directly in UPPAAL. TheAADL model was maintained as a guide for design. As a consequence, from this point on, all therequirements to be discussed were only captures in the UPPAAL model.

Listing 7: The New Patient function shall allow a new device to be interrogated without exitingthe software application.

The UPPAAL automata of the interface (Fig. 10 ) has a Main state and a Listener state. The mainstate simulates the window where the user can navigate through a number of auxiliary windows.This main window is presented when the DCM has a connection established with a pacemaker.The Listener state represents the state where the user chooses the pacemaker with which he wantsto establish a connection. As can be easily seen, there is an edge between these two states thatallows going from the Main to the Listener state without closing the application.

Listing 8: The DCM shall be capable of printing various types of reports.

Fig. 14 shows the UPPAAL automata which specifies the emission of all kinds of reports. Thereport to be produced is selected by the user preferences.

Fig. 14: Reports Automata


Listing 9: The system shall be capable of displaying up to three along with an annotation fordisplay of event markers in a scrollable fashion

The Graphics UPPAAL automata (Fig. 8) contemplates this three real time traces using threedifferent synchronizations, one for each trace. Those synchronizations are: sendP Telemetry1,sendP Telemetry2 and ECG.

Listing 10: The DCM shall be capable of printing real time telemetered data and a surface ECG.

By combining the Graphic automata (Fig. 8), which receives the data for the three graphics,with the Printer automata (Fig. 15) that allows graphics to be printed in paper (through theprintTopaperOP synchronization) we also respect this requirement.

Fig. 15: Printer Automata

3.3 User Model

This small subsection is devoted to the User Model , which simulates the interaction betweenthe user and the interface. Notice this is not a part of the original requirements for the DCMInterface, as we have came across.

We can separate this model in three parts: what the user sees in the interface, what the userchooses in the interface and what the user writes in the interface.

To simulate what the user writes in the interface we built an UPPAAL automata (Fig. 16)that generates random numbers from the N0 set.

We reproduce what the user chooses with a state transition. For instance in the Interfaceautomata (Fig. 10 ), when we reach the main state 1 the user can choose either the Reports state,the Tests state or the Modes parameters state 2. Each of these states corresponds to a new windowrepresented by an UPPAAL automata which simulates what the user can see and possibly change.

1 Notice that a main state is reached when the interface becomes successfully connected to a pacemaker2 Modes parameters is where the pacemakers parameters are changed.


Fig. 16: Random Number Generator Automata

3.4 Communication Interface Document - CID

In this subsection we describe the communication protocol between pacemakers and the DCM.Before building such a protocol there are some considerations that must be made. In particular,we take into account the power limitations inherent to the pacemaker (actually, the DCM isconsidered to have unlimited power supply and a far better processor than that of the pacemaker).Our protocol was then built with the objective of spending as little battery of the pacemaker aspossible, and that is why the pacemaker never takes the initiative in any situation; it only respondsto external stimulus, which may come from the DCM or from any other device detectable by thepacemaker. Now we present the different types of messages in our protocol:

• Ping This message is broadcast to all pacemakers within DCM’s range. Its purpose is to probethe area searching for pacemakers(Fig:17).• Pong This is the message sent by the pacemaker as a response to the DCM’s Ping message.

This message contains the pacemaker’s ID 3

• AckP Message sent by the pacemaker to the DCM that confirms the receipt of a message.• SendP Message sent by the DCM to the pacemaker that contains information about the

parameters that regulate it.• ErrorP Message sent by the pacemaker warning the DCM it has received a invalid message.• Connect Message sent by the DCM to the pacemaker in order to establish a connection.• Disconnect Message sent by the DCM to the pacemaker in order to terminate a connection.• DataP Message sent by the pacemaker to the DCM that contains among several things the

reports, history and parameters.• SendP Telemetry1 Message that contains information relative to one of the pacemaker’s

sensor.• SendP Telemetry2 Message that contains information about the other pacemaker sensor.

3.5 Verified Properties

Before we started building the DCM interface model we did some research about user interfaces,focusing, in particular on their typical properties and how they can be specified. Form this studywe came up with a selection of property classes which seems suitable for this project. They aresummed up in Fig. 18, which adapts from [3].

There are other properties that an Interface can follow, but they mainly relate to the look andfeel, the color and size of the buttons, the disposition of the windows, etc. They are usability [5]

3 The ID is a unique identifier that allows the DCM to distinguish different pacemakers


Consideracao Considera-se que nao ha sobreposicao de Serial Numbers, como dito an-teriormente, esta informacao identifica univocamente cada PG.

Probing

Figure 3.1: DCM Radial Probing

Em termos de protocolo o probing e feito com o envio, por parte do DCM, de umamensagem em broadcast, mensagem aqui designada de Ping Message, na figura 3.4.1pode observar-se um exemplo de probing identificando dois dispositivos. O PG ao receberesta mensagem devera responder com uma mensagem - Pong Message3.

Session

A nocao de sessao, ou ligacao ponto a ponto, e estabelecida com recurso ao identificadordo PG e tambem do DCM. As mensagens trocadas no ambito de uma sessao tem umformato comum.

3Para questoes de optimizacao, podera considerar-se que um PG com sessao estabelecida com o DCMnao responda a estes pedidos

10

Fig. 17: DCM Radial Probing

Property Intent

Behavior Consistency Verify that a given action causes a consistent effect

Reversibility Check whether the effect of an action can be eventually undone

Feedback Verify that a given action provides causes a change in some attribute

Fig. 18: Table of relevant properties.

properties in general. However, we were only concerned with the functionality of the interface andas such our model does not have any concerns about usability properties.

At the same time we were building our UPPAAL model, we were testing it to see if it compliedwith properties in the classes mentioned above. we will discuss some of them in the sequel.

Property 1 ReachabilityE<> Listener.receive

E<> Listener.send

E<> Listener.update

E<> Listener.receive and (forall (i: id_t) PingPong(i).ping_state )

E<> Listener.send or Listener.receive or Listener.update

With this property we want to prove that certain states are attainable. This property provedto be very useful specially when we were building the model because we wanted to make surethat no unreachable states were being added. For instance, at some point we found out that nopacemaker could connect to the interface because the update state was unattainable.

We have a list in our model whose function is to store the pacemakers within range. With thisproperty we want to make sure that there are no duplicated pacemakers in that list.


Property 2 Safety

A[] forall (i:id_t) forall (j:id_t ) i!=j and (lista[i-1]!=0) imply lista[i-1]!=lista[j-1]

Property 3 Liveness

A[] not deadlock

Listener.send --> (Listener.receive or (cGlobal>10 imply Listener.send) )

The first liveness property is absence deadlock in the whole system. The second property statesthat in the Listener automata, when a ping message is sent, either the system evolves to a a statewhere replies to ping are expected, or a timeout occurs and another ping is sent.

Property 4 FeedbackInterface.Reports --> Report.initial or Report.Report or Report.Bradycardia_Report or

Report.Temporary_Report or Report.Implant_Report or

Report.Threshold_Report or Report.Measured_Report or

Report.Marker_Report or Report.Net_Change_Report or

Report.Final_Report or Report.Histogram_Report or

Report.Trending_Report

A<> Interface.Reports imply ( Report.Report or Report.Bradycardia_Report or

Report.Temporary_Report or Report.Implant_Report or

Report.Threshold_Report or Report.Measured_Report or

Report.Marker_Report or Report.Net_Change_Report or

Report.Final_Report or Report.Histogram_Report or

Report.Trending_Report )

A<> Report.Histogram_Report or Report.Trending_Report imply

process_report.Rate_Histogram_Or_Trending

A<> Report.Bradycardia_Report or Report.Temporary_Report or

Report.Implant_Report or Report.Threshold_Report or

Report.Measured_Report or Report.Marker_Report or

Report.Net_Change_Report or Report.Final_Report or

Report.Histogram_Report or Report.Trending_Report imply

(process_report.Build_Parameters or process_report.any_report)

With these properties we want to assure that when the Report option is chosen in the DCM,a new set of buttons appears from which the user can choose the kind of report he wants.


Property 5 Behavior ConsistencyA<> Report.Bradycardia_Report imply process_report.Build_Parameters

A<> Report.Histogram_Report imply process_report.Rate_Histogram_Or_Trending

These properties specify that when a user chooses a certain type of report the behavior of thesystem is always the same.

Property 6 ReversibilityA<> Interface.End_Point imply Interface.Start_Point

A<> Interface.Listener imply Interface.End_Point

A<> Interface.Listener imply Interface.Connect

A<> Interface.Listener imply Interface.Main

A<> Interface.Listener imply Interface.Reports

A<> Interface.Listener imply (Interface.Modes_parameters imply Interface.Start_Point)

These properties state that the Interface can always return to the initial state.

4 Conclusion

4.1 What has been achieved?

This challenge was something that took us a lot of time and effort compared to other projects wehave been in charged of along our academic life. Such an extra time was mostly because this workneeded a lot of research (on both interface design and tools, AADL and UPPAAL).

Therefore, in the beginning we had a difficult learning curve because examples available werescarce, specially with respect to AADL and its annexes.

Now that the project is at its end we think it is appropriate to say that we have learnt a lotalong this path, even with the difficulties. A set of AADL and UPPAAL models were produced,the latter quite more refined than the former. Actually, we resorted to AADL only as a supporttool for modeling because our main objective was to verify formally properties of (a model of)DCM.

Not all requirements for DCM were effectively specified and dealt with within the model.Actually, we opted by illustrating some of them in some detail, rather than provide a generaloverview of the whole system. We believe this work can easily accommodate several follow-ups.

4.2 Tool evaluation

Once we started modeling we noticed that both tools AADL and UPPAAL were very intuitive,each one with its advantages and disadvantages. On the one hand AADL provides us with formaldescriptions of both hardware and software components which are essential to model a concretesystem and that makes it simple to transform the model into the implementation. On the otherhand, UPPAAL models are built upon state machines and that kind of abstraction gives greaterfreedom of choice when modeling.

Concerning negative points of both tools:. AADL’s weakest point is the inability to make formalverification of the models. We also think its OSATE plugin could be more intuitive and stable.

UPPAAL’s weakest point is its verifier because we reached a relatively complex model andwhen we tried to prove some properties (for instance deadlock) they took really a lot of time andresources (more than 1 day and almost 4GB of ram). There are, however, a number of ways to getaround this problem, which boils down to state explosion, involving the definition of equivalenceclasses of states.


4.3 Future Work

A lot remains to be done, namely in what concerns the suitable handling of the remaining re-quirements. In a broad view, however, we would point out the generic theme of interface designand formal specifications. Exploring such an interconnection, eventually in the context of a Masterthesis, is really a challenge.


References

1. Gerd Behrmann, Re David, and Kim G. Larsen. A tutorial on uppaal. pages 200–236. Springer, 2004.2. Stefan Bjornander, Lars Grunske, and Kristina Lundqvist. Timed simulation of extended aadl-based

architecture specifications with timed abstract state machines. In QoSA ’09: Proceedings of the 5thInternational Conference on the Quality of Software Architectures, pages 101–115, Berlin, Heidelberg,2009. Springer-Verlag.

3. J. Creissac Campos and M. D. Harrison. Systematic analysis of control panel interfaces using formaltools. pages 72–85, 2008.

4. Kim G. Larsen, Paul Pettersson, and Wang Yi. Uppaal in a nutshell. 1(1–2):134–152, December 1997.5. Jakob Nielsen. Usability inspection methods. In CHI ’94: Conference companion on Human factors

in computing systems, pages 413–414, New York, NY, USA, 1994. ACM.6. Martin Ouimet and Kristina Lundqvist. A mapping between the timed abstract state machine lan-

guage and uppaals timed automata. Technical Report, Malardalen University, January 2007.7. Martin Ouimet and Kristina Lundqvist. The tasm language and the hi-five framework: Specification,

validation, and verification of embedded real-time systems. In 14th Asia-Pacific Software EngineeringConference (APSEC 07),, December 2007.

8. Matthew Robinson and Pavel Vorobiev. Swing, Second Edition. Manning Publications, 2003.9. Fred B. Schneider. What good are models and what models are good? pages 17–26, 1993.

10. Boston Scientific. Pacemaker system specification. Technical report, Boston Scientific, January 2007.11. Performance Critical Systems. Getting started with the aadl and osate: An introductory tutorial.

Technical report, Software Engineering Institute, Carnegie Mellon University, August 2007.

Final Report on the Device Controller-Monitor Project | Pacemaker...

Documents

Transcript of Final Report on the Device Controller-Monitor Project | Pacemaker...