UNIVERZITET U SARAJEVU ELEKTROTEHNIKI FAKULTET

Lamija Kasumagi Erma Perenda

PROJEKTNI ZADATAK
Verifikacija protokola upotrebom vremenskih automata

Sarajevo, 2012. godine

Sadraj Uvod ........................................................................................................................................... 1 1. Vremenski automati ........................................................................................................... 3 1.1. 1.2. 1.3. 1.4. 1.5. 1.6. 1.7. 2. Satovi ........................................................................................................................... 5 Formalna sintaksa ........................................................................................................ 6 Mrea vremenskih automata ........................................................................................ 7 Semantika vremenskih automata ................................................................................. 9 Verifikacijski problemi .............................................................................................. 10 Izvoenje vremenskih automata ................................................................................ 11 Alati ........................................................................................................................... 13

UPPAAL .......................................................................................................................... 15 2.1. Arhitektura UPPAAL-a ............................................................................................. 15 Grafiki opis mree vremenskih automata ......................................................... 16 Tekstualni opis mree vremenskih automata ..................................................... 17 Linearni hibridni sistemi .................................................................................... 17 Sintaksika provjera ........................................................................................... 17 Provjera modela.................................................................................................. 18

2.1.1. 2.1.2. 2.1.3. 2.1.4. 2.1.5. 2.2.

Semantika UPPAAL modela za modeliranje realnih sistema ................................... 20 Dodjela varijabli ................................................................................................. 20 Kontrolni vektor i konfiguracija ......................................................................... 21 Maksimalno kanjenje ........................................................................................ 21

2.2.1. 2.2.2. 2.2.3. 2.3. 2.4.

Instalacija UPPAAL-a ............................................................................................... 22 Pregled UPPAAL Toolkit-a ....................................................................................... 22 Java klijent.......................................................................................................... 22 Editor........................................................................................................... 23

2.4.1.

2.4.1.1

2.4.2.

Simulator ............................................................................................................ 24 Verifikator ................................................................................................... 25

2.4.2.1 2.5.

Sintaksa UPPAAL-a .................................................................................................. 26 Deklaracija ......................................................................................................... 27 Definicija sistema ............................................................................................... 28

2.5.1. 2.5.2. 2.6. 2.7. 2.8.

Vremenski automati u UPPAAL-u ............................................................................ 29 Izrazi u UPPAAL-u ................................................................................................... 30 Query jezik u UPPAAL-u.......................................................................................... 31 Formule stanja .................................................................................................... 32 Formule putanja.................................................................................................. 32

2.8.1. 2.8.2. 3.

Verifikacija Subscriber protokola .................................................................................... 35 3.1. 3.2. 3.3. 3.4. Opis protokola ........................................................................................................... 35 Model Subscriber protokola ...................................................................................... 36 Simulacija modela Subscriber protokola ................................................................... 45 Verifikacija modela Subscriber protokola ................................................................. 47

Zakljuak .................................................................................................................................. 50 Literatura .................................................................................................................................. 51 Skraenice ................................................................................................................................ 52

Uvod
Verifikacija nekog programa ili logikog kola podrazumijeva provjeru da li je konkretna implementacija korektna, odnosno da li ispunjava neke unaprijed zadate zahtjeve. Iskustvo je pokazalo da sigurnost verifikacije ne moe biti apsolutna, u smislu da garantuje potpunu korektnost, jer se uvijek mogu javiti neki spoljni faktori koji utiu na sistem, a koje nije mogue unaprijed predvidjeti. Meutim, verifikacija znaajno utie na poveanje pouzdanosti sistema i skraivanje ciklusa razvoja, pa su i cijene savremenih programskih sistema ove namjene izuzetno visoke. Formalna specifikacija i verifikacija protokola zapoela je oko 1980., a bila je vezana za ISO (engl. International Organization for Standardization) standardizaciju OSI RM (engl. Open Systems Interconnection Reference Model). Tada je zapoelo koritenje termina: 'tehnike za formalni opis' (engl. Formal Description Techniques, FDT). U periodu od 1976. do 1983. formalna specifikacija protokola bila je u punom zamahu. U tom je periodu objavljen i poznati OSI standard. Formalna specifikacija usko je vezana uz formalnu verfikaciju protokola. Postupci verifikacije koriteni u tom vremenu predstavljaju temelj dananjim postupcima. Najranije istraivanje tog podruja odradili su G. Bochmann, C.A. Sunshine, C.H.West, H. Rudin, P. Zafiropulo. Kritika ISO OSI modela i protokola uzrokovala je i odreenu odbojnost prema formalnoj specifikaciji i verifikaciji. Odmah uoeni problem - eksplozije stanja (engl. state explosion) bio je dosta velika prepreka za ire koritenje tehnike bazirane na modelu s konanim brojem stanja. Iako su i tada koritene tehnike bazirane na dokazivanju teorema, teka automatizacija takvih postupaka nije omoguila njihovu iru primjenu. Danas, razvoj raunara, te sve kompliciranija programska podrka (i protokoli) omoguavaju, ali i zahtjevaju razvoj i usavravanje postupaka za formalnu verifikaciju.[8] U ovom radu za verifikaciju Subcriber protokola koristiti e se postupak provjere modela. Provjera modela je tehnika kojom se obavlja iscrpno pretraivanje prostora stanja. Protokoli (osobiti kontrolni aspekti) se esto opisuju pomou nekog od formalizma baziranog na automatima s konanim brojem stanja. Stoga je provjera modela vrlo prikladna tehnika ak i za verifikaciju standardiziranih industrijskih protokola. Poetak razvoja provjere modela poinje oko 1980. kada je razvijena tehnika provjere modela koritenjem vremenske logike (engl. Temporal Logic Model Checking, TLMC). Razvili su je neovisno Clarke i Emerson, te

Quielle i Sifakis. U ovom pristupu specifikacija svojstava se opisuje propozicijskom vremenskom logikom. Modeli koji se provjeravaju opisani su kao tranzicijski sistemi s konanim brojem stanja. Efikasni postupak pretraivanja stanja koristi se za odreivanje da li je u tranzicijskom sistemu zadovoljena specifikacija opisana u vremenskoj logici. Najvanija prednost koritenja postupka provjere modela za verifikaciju je potpuna automatizacija. Prednost je i to se uvid u ispravnost sistema moe dobiti i bez potpune specifikacije. Ako specifikacija nije zadovoljena, pomou dodatnih formula mogue je tano locirati uzrok greke. Osnovni nedostatak provjere modela je eksplozija stanja. Osnovni uzrok eksplozije stanja je paralelno izvravanje mnogih komponenti sistema. Broj stanja sistema moe eksponencijalno rasti s brojem procesa. Upravo zbog tog problema, smatralo se da tehnike zasnovane na modelima s konanim brojem stanja, dakle i provjera modela, nee biti primjenjive na realne sisteme. No, napretkom raunarske tehnologije ovaj problem je prevazien, pa se tehnike provjere modela danas esto koriste u industriji kao praktina tehnika verifikacije. Proces provjere modela sastoji se od tri osnovna dijela: modeliranja, specifikacije svojstava i verifikacije. Kao jedan od naina opisivanja reaktivnih sistema (protokoli, komponente komunikacijskog sistema) koristi se vremenski automati. Vremenski automati se obino koristi za modeliranje sistema koji su vremenski ovisni. Jednostavni su za koritenje i grafiko specificiranje komponenti sistema. Nekoliko alata za provjeru modela bazirano je na modeliranju sistema pomou teorije vremenskih automata, poput UPPAAL-a, KRONOS-a i dr.[8] Za realizaciju verifikacije Subscriber protokola koristit e se UPPAAL, koji je zasnovan na hijerarhijskoj strukturi vremenskih automata. Rad je konceptualno podjeljen na tri dijela. U prvom dijelu rada data je definicija, sintaksa i semantika vremenskih automata, kao i nain izvedbe vremenskih automata kako bi posluili za verifikaciju realnih reaktivnih sistema. Takoer, dat je kratki osvrt na razvijene alate koji koriste teoriju vremenskih automata za verifikaciju. Kao najraireniji i najbri u toj oblasti izdvaja se UPPAAL, te iz tog razloga u drugom dijelu rada ovaj alat je detaljno opisan zajedno s svojom arhitekturom, sintaksom i semantikom. U treem dijelu rada objanjen je nain verifikacije Subscriber protokola pomou ovog alata.

1. Vremenski automati
Vremenske automate (engl. Timed Automata, TA) kao model ponaanja sistema za rad u stvarnom vremenu predloili su Rajeev Alur i David Dill [1]. Vremenski automati proiruju konane automate s ogranienjima ponaanja u vremenskoj domeni. Za potrebe iskazivanja vremenskih ogranienja, konani automati proireni su skupom varijabli koje odreuju stvarno vrijeme. U izvornoj teoriji vremenskih automata u [1], vremenski automat je Bchi-ev automat s konanim brojem stanja, proiren sa skupom realnih varijable modeliranih kao satovi. Pojednostavljena verzija, nazvana Timed Safety Automata specificira bolja svojstva koristei lokalne invarijante. Zbog svoje jednostavnosti, ovi automati se modeliraju unutar nekoliko alata za verifikaciju pomou vremenskih automata npr. UPPAAL i KRONOS. [9] U ovom radu mi emo se bazirati na Timed Safety Automata i u daljem tekstu e se oznaavati kao vremenski automati. Primjer 1: Slika 1.1 a) pokazuje jednostavan primjer vremenskog automata. Ponaanje automata u vremenu kontrolirano je pomou dva sata x i y. Sat x se koristi za kontrolu selfloop u lokaciji loop. Jedina tranzicija se moe pojaviti kada je x=1 i automat ostaje u istoj lokaciji i sat se resetira. Sat y kontrolie izvravanje cijelog automata. Automat moe napustiti lokaciju start u svakom trenutku kada je y izmeu 10 i 20 i prelazi u lokaciju loop, a iz ove lokacije moe jedino prei u lokaciju end ako je vrijednost sata y izmeu 40 i 50, a u lokaciju start iz ove lokacije prelazi kada je vrijednost sata y izmeu 10 i 20 vremenskih jedinica, te se prilikom ove tranzicije vrijednost sata y postavlja na 0 tj. sat se restetuje. Slika 1.1 b) pokazuje vremenski safety automat koji odgovara obinom Bchi-evom automatu predstavljenom na lijevoj strani iste slike. [2]

Sl.1. 1 Vremenski automati i invarijanti lokacija [2]

Kod Bchi-evih vremenskih automata, vremenska ogranienja satova omoguavaju da se izvre neke tranzicije, no to ne mora uvijek biti sluaj. Na primjer, neki automat moe zauvijek ostati u jednoj lokaciji. U poetnom radu Alur-a i Dill-a problem je rijeen uvoenjem Bchi-acceptance uslova, tj. podskup lokacija automata su oznaene kao accepting, i samo ova beskonano esta izvrenja prolaska kroz accepting lokacije se smatraju vaeima ponaanjem automata. Kao primjer, uzmimo da je kod automata na slici 1.1 (a) lokacija end oznaena kao accepting, ovo podrazumijeva da se za sva izvrenja automata mora posjetiti lokacija end beskonano mnogo puta. To namee implicitne uvjete na lokaciju start i loop. Lokacija start mora biti naputena kada vrijednost sata y manja ili jednaka od 20, inae e automat ostati u lokaciji start i nikada nee moi doi do lokacije end. Isto tako, automat mora napustiti lokaciju loop kada je vrijednost sata y manja ili jednaka 50 vremenskih jedinica i prei u lokaciju end. [2] Timed Safety Automata uvodi jednostavnije intuitivnije rjeenje. Umjesto accepting uslova, ovi automati za lokacije postavljaju lokalna vremenska ogranienja koja se nazivaju invarijanti lokacije. Automat moe ostati u istoj lokaciji sve dok vrijednosti satova zadovoljavaju invarijante. Primjer ovih automata je dat na slici 1.1 (b), koji odgovara Bchijevem automat sa slike 1.1 (a), pri emu je lokacija end oznaena kao accepting lokacija. Invarijanti specificiraju lokalne uslove za lokacije start i end, koje moraju biti naputene kada je vrijednost sata y dostie vrijednost 20 i lokacija loop se mora napustiti kada je y vie od 50. To daje lokalni pogled na vremensko ponaanje automata u svakoj lokaciji.[2]

1.1. Satovi
Satovi (engl. clocks) su centralni koncept vremenskih automata. U poetku su svi satovi postavljeni na nulu i sinhronizirano rastu istom brzinom. Model vremena koji se koristi u konstrukciji vremenskih automata je model linearnog vremena - izvoenje operacije moe se potpuno opisati kao niz stanja ili dogaaja nazvan tragom (engl. trace). Ponaanje sistema u ovom modelu je skup trace-ova, odnosno nizova stanja, to prirodno vodi do upotrebe automata za opis i verifikaciju sistema. U postupku analize nastoji se konstruisati automat koji kao jezik prihvata skup ispravnih trace-ova, te iz njegovih svojstava izvesti zakljuke o ponaanju sistema. Dogaaji su pridrueni vremenskim trenucima gustog vremena (engl. dense time). Gusto vrijeme je skup trenutaka predstavljenih realnim brojevima (interval realnih brojeva) koji monotono rastu bez ogranienja [1]. Skup da je konaan skup realnih varijabli sata. Dodavanjem sata koji predstavlja konstantu 0, dobijamo proireni skup . tako

Ogranienja sata (engl. clock constraints) se koriste kao guards of edges (odnosi se na diktiranje tranzicija izmeu lokacija) i kao invarijanti lokacija. Skup ogranienja sata preko X opisan je gramatikom [6]: (1.1) gdje je oznaava relaciju, . Ogranienja oblika

nazivaju se atomikim. Skup svih ogranienja preko X oznaen je s , dok je njegov podskup ogranienja u kojima nejednakosti koje ukljuuju razliku satova nisu dozvoljena oznaen s . U ovom sluaju konstanta c je ograniena na skup

prirodnih brojeva. Normalna ogranienja sata odgovaraju gramatici: (1.2) gdje je oznaava relaciju, .

Svako ogranienje sata moe se pretvoriti u normalni oblik sljedeim postupkom: Ogranienja oblika oblik Ogranienja oblika , odnosno , gdje je , {<, , , >} i c N pretvaraju se u

ili

zamjenjuju se izrazom ;

True se zamjenjuje izrazom ; sva ogranienja oblika , gdje su izrazom , a ona oblika izrazom

i c

N zamjenjuju se .

Ogranienja oblika zadovoljena. Valuacija sata u X je vrijednost sata , v + oznaava valuaciju

uvode se u svrhu prikaza ogranienja koja nikad nisu

pri emu svaki lan

n-torke v oznaava

u v , to se krae moe oznaiti i kao takvu da je za svaki x X,

ili v(i). Za valuaciju v i . Podskup

skupa satova X' X, v[X := 0] oznaava valuaciju ponitavanja sata (eng. clock reset) v takvu da je: (1.3) Relacija zadovoljenja |= za ogranienje sata v |= true; v |= ( v |= ( c) akko v( ) c; c) akko v( ) v( ) c; definirana je sa:

v |= (cc cc') akko v |= cc i v |= cc'.

1.2. Formalna sintaksa

Definicija 1.1. Vremenski automat je struktura (n-torka)

gdje su: - A konani skup akcija, gdje je - L konani skup lokacija (stanja), L poetna lokacija, - X konaan skup satova, - :L relacija prelaza, svakoj lokaciji pridruuje ogranienje sata invarijant. ,

Edge

izmeu lokacija l (izvorine lokacije) i l' (odredine lokacije)

oznaen je ogranienjem sata cc, akcijom a i skupom Y satova koji e se ponititi. Edge e oznaava se sa ime se oznaava da je edge izmeu lokacija l i l 'omoguen

zadovoljenjem ogranienja sata cc, izvodi akciju a i ponitava satove iz skupa Y. Funkcija svakoj lokaciji l L pridruuje ogranienje sata i (invarijant) koje odreuje uvjet pod kojim automat smije ostati u l. Lokacije mogu biti obine (engl. ordinary), hitne (engl. urgent) ili izvrive (engl. committed). Automat u hitnoj i izvrivoj lokaciji ne smije kasniti. Takoer, automat u izvrivoj lokaciji ne sarauje s drugim automatima. Ako su ogranienja sata i invarijanti lokacija strogo iz skupa C, za automat kaemo da je bez dijagonala (engl. diagonal-free). Za edge definie se i funkcije izvor(e), odredite(e), akcija(e), uslov(e), reset(e) za l, l', a, cc, Y. Uslov edge-a ograniava aktiviranje edge-a (ali ne implicira da mora doi do prelaza upravo tim edge-om). Invarijant lokacije dozvoljava automatu ostanak u lokaciji l tako dugo dok je uvjet (l) ispunjen.

1.3. Mrea vremenskih automata

Vremenski automati mogu formirati mreu tj. sistem od vie automata koji komuniciraju meusobno preko sinhroniziranih akcija. Mrea vremenskih automata je paralelna kompozicija od n vremenskih automata , koji se u ovom sluaju nazivaju procesi i kombinuju se u jedan sistem, ali eksterne akcije mogu ostati skrivene. Za sinhronizaciju dva automata predvieni su binarni sinhronizacijski kanali. Uz svaki kanal c pridruen je par sinhronizacijskih operacija c! i c?. Edge koji sadri uslov oznaen kao c! (gdje je c ime sinhronizacijskog kanala) sinhronizira se s drugim edge-om oznaenim s c?. Operacija '!' moe se predstaviti i kao slanje sinhronizacijske poruke, dok je operacija '?' prijem poruke. U sluaju kad je omogueno vie edge-eva koji ekaju na kanal, sinhronizacijski par odabire se nedeterministiki. Operacija sinhronizacije je blokirajua ukoliko ne postoji primaoc koji eka na sinhronizaciju, poiljaoc nee moi ostvariti prelaz i doi e do njegove blokade. [2] Broadcast sinkronizacijski kanali doputaju jednom poiljatelju c! da se sinhronizira s proizvoljnim brojem primatelja c? (poiljatelj alje obavijest primateljima). Za razliku od binarnih sinhronizacijskih kanala, broadcast kanali nee blokirati poiljatelja ako nema primatelja koji ekaju na sinhronizaciju.[2]

Oba tipa kanala mogu biti dodatno oznaeni kao hitni [2]. Hitni kanali ne doputaju prolazak vremena (kanjenje) ako je omoguena veza s operacijom sinhronizacije putem kanala i takve veze ne smiju imati uslove koji ukljuuju satove. Osim sinhronizacijskih kanala, elementi koji mogu pojednostaviti opis i analizu ponaanja sistema su hitne i sinhronizirane ili izvrive lokacije. Hitne lokacije ne doputaju da vrijeme prolazi dok je sistem u stanju koje ukljuuje hitnu lokaciju. Isti efekt moe se postii dodavanjem dodatnog sata s koji se brie na svim edge-evima koji ulaze u hitnu lokaciju i na svim edge-evima koji izlaze iz hitne lokacije, dok sama lokacija ima invarijant koji ukljuuje uvjet s <= 0. Sinhronizirane lokacije uvode dodatna ogranienja [2]. Stanje S u kojem se sistem nalazi je sinhronizirano ako je bilo koja od lokacija ukljuena u stanju sistema oznaena kao sinhronizirana lokacija. Vrijeme ne prolazi u sinhroniziranom stanju, a prelaz u sljedee stanje (prelaz kojim sistem naputa stanje S) mora sadravati barem jedan edge koji vodi iz sinhronizirane lokacije. Tim uslovom se osigurava da sistem mora napustiti sve sinhronizirane lokacije prije nego to vrijeme nastavi prolaziti. Primjer 2: Slika 1.2 pokazuje jednostavan primjer mree vremenskih automata, kojom se modelira lampa. Lampa ima tri lokacije: off, low i bright. Ako korisnik pritisne dugme, odnosno ako se lampa sinhronizuje sa press?, tada e se lampa upaliti (low). Ako korisnik ponovo pritisne dugme, lampa e se ugasiti (off). U sluaju da korisnik veoma brzo pritisne dugme dva puta, lampa e se upaliti i postati bright. Model korisnika je dat na slici 1.2 b). Korisnik moe pritisnuti dugme sluajno u bilo koje vrijeme ili ak ne pritisnuti dugme (sistem moe zaglaviti, engl. deadlock). Sat y se koristi za detekciju brzine korisnika pri paljenju lampe: brzo (y<5) ili sporo (y>=5).

Sl.1. 2 Mrea vremenskih automata [7]

1.4. Semantika vremenskih automata

Semantika vremenskih automata definirana je kao sistem tranzicija, gdje se stanje ili konfiguracija sastoji od trenutne lokacije i trenutne vrijednosti varijable sata. Postoje tri vrste tranzicija/edge-eva izmeu stanja: delay tranzicije, interne tranzicije i sinhronizacija.[2] Definicija 1.2. Operativna semantika (engl. Operational Semantics, OS): Semantika vremenskih automata je sistem tranzicija (takoer poznat kao vremenski prelazni sistem) gdje su stanja odreena parom
, ako je , ako je ,

i tranzicije su definisane pravilima:

za nenegativne realno . ;

Sljedea slika ilustrira semantiku vremenskih automata. Za dato poetno stanje, moe se izabrati tranzicijska akcija ili neka od delay tranzicija (u ovom sluaju postoje dvije delay tranzicije). Ovisno o izabranoj delay tranziciji, neke dalje tranzicijske akcije mogu biti zabranjene.

Sl.1. 3 Semantika vremenskih automata [7]

Definicija 1.3. Semantika mree vremenskih automata: Neka je od n vremenskih automata. Neka je se definira kao sistem tranzicija je inicijalno stanje, a

mrea

inicijalni vektor lokacija. [7] Semantika , gdje je skup stanja,

je skup tranzicijskih relacija definiranih kao:

, ako je , ako postoji ; , ako postoji .

za nenegativne realno , tako da je

, tako da je

Primjer ove semantike, moe se pokazati na modelu lampe predstavljenom na slici 1.2. Lampa moe imati slijedea stanja:

1.5. Verifikacijski problemi

Operativna semantika je osnova za verifikaciju pomou vremenskih automata. Vremenska akcija je par , gdje je akcija koju poduzima automat poslije vremena od kako

je automat pokrenut. Apsolutno vrijeme zove se time-stamp akcije . Vremenski trag (engl. timed trace) je sekvenca vremenskih akcija sve . [2] sa poetnim stanjem predstavlja sekvencu gdje je za

Definicija 1.4. Pokretanje vremenskog automata preko vremenskog trace-a tranzicija:

Zadovoljavajui uslov Vremenski jezik preko

, za svako je set svih vremenskih tragova za koje postoji proces pokretanja

Neki od verifikacijskih problema su [2]: 1. Neodluivost - negativna posljedica vremenskih automata kao raunarskog modela je to da je jezik koji ukljuuje provjeru problema neodluiv, tj. da provjera je neodluiva. Za razliku od konanih automata, vremenski automati nisu u potpunosti deterministiki.

10

2. Bisimulacija je druga negativna posljedica vremenskih automata uvedena kod vremenskog procesiranja algebre. Moe se jednostavno proiriti i na vremenske automate. Dva automata su vremenski bisimilarna akko postoji bisimulacijski sadraj u poetnim stanjima automata. Intuitivno, dva automati su vremenski bisimilarna akko oni obavljaju istu akciju u isto vrijeme i postiu bisimularna stanja. 3. Dosenost analize - najkorisnije pitanje za vremenske automate je sposobnost dosega odreenog konanog stanja ili skup konanih stanja. Takva konana stanja mogu se koristiti za karakterizaciju sigurnosnih svojstva sistema.

1.6. Izvoenje vremenskih automata

Kako varijable sata uzimaju realne vrijednosti i kako je sistem tranzicija beskonaan, vremenski automati u tom obliku nisu prikladni za automatsku verifikaciju. Iz tog razloga vremenski automati se izvode poput vremenskih zona ili regija. Uzmimo da je . Za ogranienje sata zadovoljavaju ogranienje cc: (1.4) Vremenska regija u je svaki konveksni poliedar Z odreen ogranienjem sata: (1.5) Radi jednostavnosti, pojam regije smatramo identinim s ogranienjem sata koje ju odreuje. Skup svih regija u X oznaavamo sa . oznaimo sa skup svih valuacija satova x X koje

Sl.1. 4 Primjer vremenske regije za dva sata x i y [2]

11

Slika 1.4 prikazuje pokazuje sve mogue regije za svaku lokaciju automata sa dva sata x i y. Za sat x postoje tri mogue regije, dok za sat y dvije regije. Sve ugaone take, linijski segmenti i otvoreni prostori predstavljaju regiju na ovoj slici. Broj moguih regija za svaku lokaciju ovog automata je 60. Za v, v' te Z, Z' v v' akko Z( ) definirane su sljedee operacije:

takav da je v'= v + , (Z\Z') particija (familija

Z\Z' je konaan skup disjunktnih regija takav da je {Z'} disjunktnih podskupova) Z,

, .

Vremenska zona/regija za vremenski automat je konana. Nekoliko problema verifikacije, kao to su dosenost analize, neodluivost, bisimulacija, moe se rijeiti ovom tehnikom. Meutim, problem s grafovima vremenskih regija je eksplozivan porast regija. Efikasnija reprezentacija prostora stanja vremenskog automata temelji se na ideji zone i zone-grafova. Za razliku od regija, zone se koriste za oznaavanje simbolinih stanja. To u praksi daje grublju i time kompaktniju reprezentacija prostora stanja. Kao primjer, vremenski automat i odgovarajua zona-graf prikazani su na slici 1.5. Napominjemo da za ovaj automat zona graf ima samo osam stanja, dok regija-graf za isti primjer ima preko 50 stanja. Kao i regija, i zona je ograniena s ogranienjem varijabli sata.[2] Detaljnije o vremenskim zonama i regijama vidjet u [3]

Sl.1. 5 Primjer vremenskog automata i odgovarajue vremenske zone [2]

12

1.7. Alati
Istraivanje prostora vremenskih automata i real-time sistema dovelo je do razvoja nekoliko alata za automatsku verifikaciju sistema. Neki od tih alata navedeni su u nastavku [3]. KRONOS razvijen na VERIMAG-u u Francuskoj s ciljem verifikacije kompleksnih real-time sistema. Real-time sistemi imaju strogo definisano vrijeme za obavljenje nekog zadatka. Ugraeni regulatori, energetska kola i komunikacijski protokoli su primjeri takvih vremenski zavisnih sistema. U KRONOS-u komponente real-time sistema su modelirane pomou vremenskih automata a korektnost zahtjeva su izraene preko real-time temporalne logike TCTL (eng. Timed Computation Temporal Logic). TCTL je proirenje vremenske logike CTL koja omoguuje kvantitativno vremensko obrazloenje u gustom vremenu. KRONOS provjerava da li vremenski automati zadovoljavaju TCTL formule. Definicija bilo koje komponente vremenskog automata je opisana programom jednostavne sintakse, koja se koristi za definiranje stanja, invarijanata, logikih varijabli i tranzicija vremenskog automata. Kako je semantiki model baziran na stanjima, KRONOS dozvoljava labele na tranzicijama. Moe se iskoristiti za konstrukciju paralelnih sistema sastavljenih od nekoliko vremenskih automata. Potujui odreena ogranienja, paralelni sistem moe se formirati i tokom verifikacije. Na taj nain se tedi prostor i vrijeme. UPPAAL Opisuje mreu vremenskih automata predstavljenu kao skup predloaka (engl. template) pojedinih automata. Predloku moe biti pridruen skup parametara koji se zamjenjuju argumentima pridruenim predloku u okviru deklaracije procesa. Parametri mogu biti bilo kojeg od podranih tipova. Ovo je jedan od najbrih i najkoritenijih alata u podruju verifikacije realnih sistema, pomou vremenskih automata. Detaljnije o UPPAAL-u dato je u sljedeem poglavlju. HyTECH The Hybrid TECHnology je alat za automatsku analizu ugraenih sistema. On rauna uslove pod kojima linearni hibridni sistem zadovoljava vremenske zahtjeve. Hibridni sistemi su sastavljeni od diskretnih i kontinualnih komponenata. Poto su vremenski automati tipini hibridni sistemi oni mogu biti verifikovani pomou ovog alata.

13

SGM State Graph Manipulator je alat za specifikaciju i verifikaciju real-time sistema. Razvijen je od strane Formal Methods grupe na Institute of Information Science, Academia Sinica, Taipei, Taiwan i SGM grupe. Koristi razne sofisticirane provjere i tehnike razvijene u posljednih nekoliko godina.

14

2. UPPAAL
UPPAAL je alat za validaciju (putem grafike simulacije) i verifikaciju (putem automatske provjere modela) realnih sistema razvijen od strane UPPsala univerziteta iz vedske u saradnji sa AALborg univerzitetom iz Danske. Ovaj alat je dizajniran u cilju verifikacije sistema koji mogu biti modelirani kao mrea vremenskih automata sa mogunostima koritenja cjelobrojnih varijabli, strukturnih tipovima podataka i sinhronizacije kanala. Tipina podruja primjene su real-time kontroleri i komunikacijski protokoli prije svega, za iju su realizaciju kljuni vremenski aspekti. Prva verzija UPPAAL-a je objavljena 1995. godine i od tada se stalno unaprijeuju i razvijaju nove verzije. [4]

2.1. Arhitektura UPPAAL-a

UPPAAL se sastoji od dvije komponente, grafikog korisnikog interfejsa GUI (engl. Graphical User Interface) koji je napisan u programskom jeziku Java i omoguava grafiki opis i definisanje sistema i mehanizma za provjeru modela, koji je napisan u C++. Upravo ovakva arhitektura UPPAAL-a omoguava realizaciju sistema koja je efikasna i jednostavna za upotrebu. Mehanizam provjere i GUI meusobno komuniciraju upotrebom protokola, to omoguava da proces verifikacije bude izvren ili na lokalnom raunaru, ili pak na snanijem serveru koji se nalazi unutar mree. Korisniki interfejs podrava i grafiku i tekstualnu prezentaciju mree vremenskih automata, te omoguava automatsku transformaciju grafikog opisa sistema u tekstulani opis. Pored toga, moe raditi sa mreom linearnih hibridnih automata koji mogu biti transformisani u vremenske automate koritenjem apstraktnih tehnika. Mehanizam za provjeru modela (eng. Model-checker) je baziran na tehnikama za rjeenje problema ogranienja. Kod provjere modela za realne sisteme javljaju se dva problema. Jedan problem predstavlja irenje u podruju stanja, a drugi irenje u podruju upravljanja vorovima. Trenutna verzija UPPAAL-a se nosi sa problemom koji se javlja u domenu stanja upotrebom tehnika baziranih na simbolima koje reduciraju verifikacije na problem rjeavanja sistema sa jednostavnim ogranienjima. Drugi problem vezan za kontrolu vorova se rjeava koritenjem on-the-fly tehnika za verifikaciju. UPPAAL takoer podrava i dijagnostiki"

15

mehanizam za provjeru modela koji osigurava informacije o uzrocima problema u sluaju da ne uspije proces verifikacije odreenog realnog sistema. [4]

Sl.2. 1 Prikaz strukture UPPAAL-a [4]

2.1.1. Grafiki opis mree vremenskih automata

Mogue je grafiki predstaviti mreu vremenskih automata koritenjem Autograph-a, uzimajui u obzir da su ispotovana odreena sintaksika pravila [4]. Da bi se ubacio opis sistema (kreiran pomou Autograph-a) u UPPAAL sistem mora biti snimljen u .atg autograph formatu. Pravila koja se moraju ispotovati [5]: Procesi sistema moraju biti smjeteni u posebne okvire, pri emu imena odgovaraju strukturnim labelama; Svim stanjima procesa moraju biti dodjeljena imena. Imena pridruena stanjima su lokalna i mogu biti iskoritena i u drugim procesima; Sve tranzicije moraju biti izmeu stanja istog procesa. Tranzicije izmeu razliitih procesa nisu dozvoljene; Mora postojati i okvir za opis konfiguracije sistema. To je okvir sa strukturnim nazivom "config", u kojem se nalaze deklaracije varijabli; Okvir bez stanja i bez "config" oznake, se smatra komentarom i njega translacijski program ne uzima u obzir.

16

2.1.2. Tekstualni opis mree vremenskih automata

UPPAAL omoguava da mrea vremenskih automata bude opisana koritenjem tekstualnog formata, .ta, osiguravajui osnovni programski jezik za vremenske automate. U pojedinim sluajevima ovaj tekstualni format je pogodniji i bri za upotrebu od grafikog interfejsa. Atg2ta kompajler automatski transformira opis sistema iz grafikog .atg formata u tekstualni .ta format [4]. Sintaksa .ta opisa je veoma jednostavna i sastoji se iz tri osnovna dijela [5]: Globalna deklaracija - koja podrazumijeva deklaraciju globalnih varijabli, kao to su satovi, kanali i brojevi. Opis procesa - dio u kojem se definiu svi procesi u sistemu. Konfiguracijski dio - u kojem se definie globalna konfiguracija sistema. U trenutnoj verziji UPPAAL-a, u ovom dijelu se definiu, odnosno kreiraju liste svih procesa u sistemu. U naprednijim verzija mogue je u ovom dijelu definisati i sve kanale koji su sakriveni od okruenja (u trenutnoj verziji svi kanali su sakriveni od okruenja).

2.1.3. Linearni hibridni sistemi

Pod odreenim uslovima, model vremenskih automata moe biti generaliziran na nain da dozvoli koritenje satova sa vrijednostima koje variraju izmeu gornje i donje granice, te da dozvoli da se vrijednosti satova mijenjaju izmeu razliitih kontrolnih vorova [4]. Ovo proirenje vremenskih automata je korisno za modeliranje hibridnih sistema kod kojih ponaanje sistemskih varijabli moe biti opisano ili aproksimirano koritenjem gornjih i donjih granica njihovih vrijednosti. UPPAAL podrava vrstu linearnih hibridnih automata kod kojih je brzina sata odreena vremenskim intervalom. Ova vrsta hibridnih automata moe biti transformirana u obine vremenske automate koritenjem hs2ta translacijskog programa.

2.1.4. Sintaksika provjera

Za dati tekstulani opis sistema vremenskih automata zapisan u .ta formatu program checkta izvrava provjere sintakse [4]. Checkta provjerava sljedee [5]: da su svi tipovi podataka podrani (tipovi podataka koji se koriste su clock i integer), da su sve varijable i kanali deklarisani, da su deklarisani svi procesi sistema i da svi procesi imaju definisano poetno stanje,

17

da su izvor i odredite tranzicije stanja, i da su ta stanja deklarisana u istom procesu kao i tranzicija, da su guard i assign oznake (labele) tranzicija ispravno formirane, da su deklarisani samo oni procesi koji se koriste u sistemu.

2.1.5. Provjera modela

Provjera modela se vri koritenjem verifyta modula koji kao ulaz prima mreu vremenskih automata u .ta formatu. Ukoliko ne uspije verifikacija odreenog realnog sistema, verifyta automatski alje "diagnostic trace". Ovakva putanja sadri informacije o grekama koje su dovele do problema u verifikaciji, a koje su korisne za naredni proces traenja greaka u razmatranom sistemu. Verifyta uzima u obzir opise i osobine, te kao odgovor daje "da" i "ne". Verifikacija se odvija unazad, tj. u obrnutom modu. Verifikator poinje u stanju sistema koje zadovoljava osobinu, logiku (ili njenu negaciju), te pokuava da nae put nazad do poetnog stanja. Izbor stanja u kojem e poeti proces verifikacije je odreen strukturom samog svojstva koja treba biti zadovoljena. Ukoliko je svojstvo, tj. logika koja treba biti zadovoljena tipa E < > p onda se stanja koja zadovoljavaju tu osobinu biraju kao poetna stanja verifikacije, i ukoliko se pronae put nazad do poetnog stanja to znai da je svojstvo zadovoljeno. U sluaju da se razmatra osobina tipa A [ ] p, proces verifkacije poinje u onim stanjima koja zadovoljava negaciju te logike, te ukoliko se pronae put do poetnog stanja to znai da je svojstvo narueno, tj. da nije zadovoljeno [5]. Verifyta opcije i njene odgovarajue opcije u GUI-u su date u nastavku (default-ne Verifyta opcije su boldirane) [7]: Reprezentacija prostora stanja: -C DBM Koristi DBM-ove umjesto grafa sa minimalnim ogranienjem za reprezentaciju koritenu za pohranjivanje dostupnih stanja. Ovo poveava upotrebu memorije (posebno u modelima sa velikim brojem satova), ali je esto bra solucija. -A Over approximation Koristi convex hull over-approximation. Za vremenske sisteme, ovo moe drastino ubrzati brzinu verifikacije, dok za ostale sisteme ovo nema nikakvog efekta.

18

-Z

Under approximation Koristi bit-state rasprenu under-approximation. Na ovaj nain se redukuje upotreba memorije na manje ili vie fiksiranu koliinu. Preciznost aproksimacije je kontrolisana promjenom veliine hash tabele.

-T

Ponovna upotrebljivost Omoguava se ubrzavanje verifikacije tako to se vri ponovna upotreba generisanog prostora stanja, kada god je to mogue. Za neke kombinacije osobina ova opcija moe dovesti do vee reprezentacije prostora stanja, to ustvari ponitava postignuto ubrzanje.

-U

Kada se koristi reprezentacija stanja sa grafom sa minimalnim ogranienjem, ova operacija mijenja nain poreenja stanja. Ovo redukuje upotrebu memorije na raun komparacijskog operatora. Smanjena upotrebe memorije moe reducirati i overhead. U GUI je ova opcija uvijek aktivna.

-H

Mijenja veliinu hash tabela tokom procesa verifikacije. Moe takoer ubrzati verifikaciju za vee sisteme.

Redukcija prostora stanja: -S0 Nema redukcije Pohranjuju se sva dostupna stanja. Zauzima dosta memorije, ali sprijeava da bilo koje stanje bude istraeno vie puta, dovoljno je samo jednom. -S1 Konzervativna redukcija Pohranjuju se sva neizvrena stanja. Koristi se manje memorije kada se koriste committed lokacije, te se za veinu modela stanja provjeravaju samo jedanput. -S2 Agresivne redukcije Pokuava da to vie redukuje broj pohranjenih stanja. Koristi znatno manje memorije, ali zbog toga moe trajati znatno due. Ova opcija se ne kombinuje sa pretraivanjem prve dubine (eng. dept first search), zbog toga to se vrijeme izvravanja drastino poveava. Naredbe pretraivanja: -b Breadth First

19

Pretrauje prostor stanja koritenjem Breadth First tehnike. -d Depth First Pretrauje prostor stanja koritenjem Depth First tehnike. Trace opcije: - none Nijedan trace Ne generie ni jedan trace -t0 Neki trace Generie neki dijagnostiki trace. -t1 Najkrai trace Generie najkrai trace. Ovdje se podrazumijeva da je najkrai u odnosu na broj koraka koje je potrebno izvriti. -t2 Najbri trace Generie najbri trace, odnosno sa najmanjim kanjenjem. -f -y Zapisuje trace-ove u XTR trace file-ove (koje moe proitati GUI). Generiu se default-ni, konkretni trace-ovi, prikazujui kanjenje i kontrolu tranzicija. Ova opcija proizvodi simbolike trace-ove kao to su oni prikazni u GUI-u.

2.2. Semantika UPPAAL modela za modeliranje realnih sistema

Proces modeliran koritenjem automata poinje u voru trenutku vremena proces moe promijeniti trenutni vor. sa svim satovima

inicijaliziranim na 0. Vrijednost satova raste sinhrono za vremenom na voru l. U bilo kojem

2.2.1. Dodjela varijabli

Dodjela varijabli predstavlja proces mapiranja koji preslikava varijable sata C u nenegativne realne vrijednosti i podaktovne varijable V u cjelobrojne vrijednosti (tipa integer). Za dodjelu varijable v i kanjenja d, oznaava dodjelu varijable takvu da je za bilo koju

za bilo koju vrijednost sata x i

20

cjelobrojnu varijablu i. Ova definicija operacije

oznaava da su sve clock operacije, koje

imaju istu brzinu i varijable podataka, vremenski nezavisne. Za reset operaciju r (skup operacija dodjeljivanja), i sata g, vrijedi da je dodjela varijable za oznaava vrijednost e u v. Za dato ogranienje

u suprotnom, gdje

je boolean vrijednost koja oznaava da li v zadovoljava vrijednost g ili ne. [6]

2.2.2. Kontrolni vektor i konfiguracija

Kontrolni vektor mree je konfiguracija mree ,a je je vektor vorova, pri emu je vor mree . Stanje mree

, gdje je kontrolni vektor, a v je dodjela varijable. Poetno stanje , gdje je inicijalizacijski vektor iji su elementi poetni vorovi mree

poetna dodjela varijabli koja svim varijablama dodjeljuje vrijednost 0. [6]

2.2.3. Maksimalno kanjenje

Neka je konfiguracija automata A. Proces modeliran sa A u stanju mora ekati

da ogranienja postanu true, to onemoguuje tranziciju u neko drugo stanje. Meutim, nije poeljno da proces zauvijek ostane na istom kontrolnom voru. to znai da neke diskretne tranzicije trebaju biti izvrene u skladu sa odgovrajuim vremenskim ogranienjima. Zahtjeva se da ta granica bude maksimalno kanjenje, prije to se sva ogranienja zatvore, odnosno prije nego to vie nikad ne budu u mogunosti da preu u true stanje. [6] Formalno se maksimalno kanjenje automata moe definisati na sljedei nain: (2.1) Pri emu vrijedi da je max{} = 0. Ovo ustvari znai da mrea A nije fiziki izvodiva. Postoje dvije vrste tranzicija izmeu stanja [6]: 1. Tranzicije kanjenja: Dokle god su vrijednosti kontrolnog vora u odreenom stanju zadovoljavajue, vrijeme moe proticati bez uticaja na vektor kontrolnog vora, pri emu vrijednost sata raste u skladu sa istekom vremena. 2. Tranzicije akcija: Ako su dvije komplementarne edge oznake razliitih komponenti u enable stanju, onda one mogu biti sinhronizirane.

21

2.3. Instalacija UPPAAL-a

Da bi bilo mogue instalirati i pokrenuti UPPAAL GUI neophodno je prvo instalirati i ispravno konfigurisati Java radno okruenje. UPPAAL zahtjeva Java verziju 6, ili noviju, npr. J2SE (engl. Java to Platform Standard Edition) Java Runtime Environment (JRE). Moe se preuzeti sa linka: Oracle Site. U naem sluaju je koritena Java (TM) SE 7 U9 platforma. Nakon to je ispunjen preduslov za instalaciju, moe se krenuti sa instalacijom samog UPPAAL-a, koja se sastoji od nekoliko jednostavnih koraka. Prvo je potrebno download-at ovaj alat sa oficijalne UPPAAL stranice, odnosno sa linka: UPPAAL. Nakon toga je potrebno otpakovati download-ani zip fajl koji sadri instalacijske fajlove, ukljuujui uppaal.jar, uppaal, te direktorije bin-Linux, bin-Win32, demo i lib. Bin direkorij sadre dva fajla server.exe i verifyta.exe. Demo direktorij sadri demo fajlove sa eksenzijama .xml i .q., tj. gotove primjere nekih UPPAAL modela. U naem sluaju je koriten uppaal-4.1.13, instaliran na Ubuntu operativnom sistemu, koji se pokree pokretanjem startup skripte uppaal.

2.4. Pregled UPPAAL Toolkit-a

UPPAAL koristi klijent-server arhitekturu, pri emu je klijent (korisniki interface) implementiran u Javi, a server (mehanizam za provjeru modela) je namjenjen za rad na razliitim platformama kao to su Linux, Windows i Solaris [7]. Ove dvije komponente se mogu pokretati na razliitim mainama pri emu komuniciraju upotrebom TCP/IP-a.

2.4.1. Java klijent

Ideja UPPAAL alata je modelirati sistem, predstavljen preko vremenskih automata, koritenjem grafikog editora, zatim simulirati razmatrani sistem na nain da se on ponaa kako je i predvieno, te na kraju provjeriti tanost sistema u odnosu na set postavljenih svojstava (engl. Properties). Grafiki interface Java klijenta upravo reflektira ovu ideju. Podijeljen je u 3 glavna dijela: editor, simulator i verifikator, to se moe vidjeti na slici 2.2.

22

Sl.2. 2 Izgled GUI-a u UPPAAL-u

2.4.1.1 Editor
Sistem definisan kao mrea vremenskih automata se naziva proces. Proces je instanciran iz parametriziranog template-a ili predloka. Sam editor je sastavljen iz dva dijela: stabla koje omoguava pristup razliitim predlocima, i deklaracijskog tekstualnog editora. Naime, stablo (lijeva strana slike 2.3.) omoguava pristup razliitim dijelovima deklaracije sistema [7]: Globalna deklaracija (eng. Global declaration) - sadri globalne cijelobrojne varijable, clock-ove, sinhronizacijske kanale i konstante. Predloak Moe sadravati lokalnu deklaraciju varijabli, kanala i konstanti. Procesni zadaci (engl. Process assignments) Predloci su instancirani u obliku procesa.

23

Sl.2. 3 Izgled editora unutar UPPAAL GUI-a

2.4.2. Simulator
Simulator se moe koristiti na tri naina [7]: Korisnik moe pokrenuti sistem runo i izabrati koje e tranzicije biti izvrene. Moe se aktivirati random mode koji omoguava da se sistem sam pokrene. Korisnik moe proi kroz zapis, trace, koji je sauvan ili unesen od strane verifikatora, kako bi provjerio dostupnost pojedinih stanja. Simulator se sastoji od sljedeih dijelova: Kontrolni dio koristi se za odabir moguih tranzicija, prolazak kroz trace i aktiviranje random simulacije. Pogled na varijable prikazuje vrijednost cijelobrojnih varijabli i ogranienja satova. UPPAAL ne prikazuje konkretna stanja sa stvarnim vrijednostima satova. Poto, teoretski, postoji beskonano takvih stanja, UPPAAL umjesto pojedinanih prikazuje skup konkretnih stanja koji su poznati kao simbolika stanja. Sva konkretna stanja unutar simbolikog stanja dijele isti lokacijski vektor i istu vrijednost za diskretne

24

varijable. Mogue vrijednosti satova su opisane skupom ogranienja. Za simboliko stanje se koristi upravo onaj sat koji zadovoljava sva ogranienja iz datog skupa ogranienja. Pogled na sistem prikazuje sve instancirane automate i aktivne lokacije trenutnih stanja. Message Sequence Chart prikazuje sinhronizaciju izmeu razliitih procesa kao i sve aktivne lokacije u svakom koraku, tj. iteraciji. [7]

Sl.2. 4 Izgled simulatora unutar UPPAAL GUI-a

2.4.2.1 Verifikator
Svojstva ili mogunosti, koja se trebaju provjeriti, se mogu izabrati u Overview listi. Korisnik moe provjeriti model za jedno ili vie svojstava, unijeti novo ili izbrisati postojee, ili aktivirati pogled tako da vidi svojstvo ili komentare na listi. Kada je svojstvo izabrano, mogue je promijeniti njegovu definiciju ili komentar. Statusni panel na dnu ekrana prikazuje komunikaciju sa serverom. Kada je omogueno generisanje trace-a i mehanizam za provjeru modela pronae taj trace, postavlja se pitanje korisniku da li eli da se taj trace unese u simulator. Svojstvo koje je zadovoljno je oznaeno kao zeleno, u suprotnom je oznaeno kao crveno. Ukoliko je korisnik

25

u meniju izabrao vrijednost ispod ili iznad aproksimirane, tada je mogue da verifikacija ne bude u skladu sa koritenom aproksimacijom. U tom sluaju svojstva su oznaena kao uta.

2.4.2.1.1

Stand-alone verifikator

Ukoliko je rije o velikim zadacima i problemima koje treba verificirati, teko ih je izvriti unutar samog GUI-a. U ovakvim situacijama se koristi ve spomenuti stand-alone verifikator verifyta. On omoguava da se verifikacija obavlja na udaljenim UNIX mainama, pri emu je osigurana i memorijska uteda. Prihvata arugmente komandne linije za sve opcije prisutne u GUI-u.

Sl.2. 5 Izgled verifikatora unutar UPPAAL GUI-a

2.5. Sintaksa UPPAAL-a

Sintaksa UPPAALa je jednostavna i ima dosta slinosti s ostalim objektno orjentisanim jezicima. U ovom djelu dat emo samo kratak osvrt na pojedina sintaksika pravila, detaljinije i opsenije moe se nai u Help menu UPPAAL-a.

26

2.5.1. Deklaracija
Deklaracija bilo lokalna ili pak globalna moe sadravati deklaraciju satova, ogranienih cjelobrojnih varijabli, kanala (iako su lokalni kanali beskorisni), nizova, skalara (tipova) i struktura. Razlikujemo deklaraciju varijabli, deklaraciju struktura, funkcija i deklaraciju kanala. Unutar UPPAAL-a razlikujemo data i clock varijable. Sintaksa za deklaraciju je slijedea: VariableDecl ::= Type VariableID (',' VariableID)* ';' VariableID ::= ID ArrayDecl* ['=' Initialiser ] Initialiser ::=Expression | '{' Initialiser (',' Initialiser )* ';' TypeDecls ::= 'typedef' Type ID ArrayDecl* (',' ID ArrayDecl *)* ';' Type ::=Prefix TypeID Prefix ::= 'urgent' | 'broadcast' | 'meta' | 'const' TypeID ::=ID |'int' |'clock' | 'chan' | 'bool' | 'scalar' |'struct' FieldDecl ::= Type ID ArrayDecl* (',' ID ArrayDecl*)* ';' ArrayDecl ::='[' Expression ']' | '[' Type ']' Dakle, postoji etiri predefinirana tipa: int, bool, clock i chan. Podrazumjevani opseg integera je [-32768, 32767]. Svaka vrijednost varijabli van opsega moe uzorkovati prekid verifikacije. Prefiksi meta i const odnose se na varijable, dok urgent i broadcast na kanale. Meta varijable su pohranjene u vektor stanja, ali semantiki se ne smatraju dijelom stanja. Drugim rjeima, dva stanja koja se razlikuju jedino u vrijednosti meta varijable se smatraju istim stanjima. Strukture su specificirane preko kljune rijei struct, kao u C notaciji. Skalari u UPPAAL-u su integer-i, kao elementi s ogranienim brojem operacija. S tim u vezi, skalari su neureeni. Skalari se tretiraju kao tipovi. Novi skalarni set od n elemenata se konstruie pomou scalar[n] konstruktora. Npr. typedef scalar [3] mySet; mySet s; int a[mySet];

27

gdje je mySet skalarni set veliine 3, s je varijabla tipa mySet, a je niz cjelobrojnih vrijednosti indeksiranih s skalarnim setom mySet. Vrijednosti varijabli se mogu testirati i aurirati tokom tranzicija, i na taj nain utjecati na ponaanje. Statike varijable su neophodne za modeliranje netrivijalnih sistema i na taj nain daju UPPAAL-u izraajnu mo koja je usporediva s jednostavnim programskim jezicima. Deklaracija funkcija se vri na isti nain poput C notacije (for, while, do/while, if petlje). Za kanale je mogue definirati globalno prioritete pomou notacije: ChanPriority ::= 'chan' 'priority' (ChanExpr | 'default') ((',' | '<') (ChanExpr | 'default'))* ';' ChanExpr ::= ID | ChanExpr '[' Expression ']' Deklaracija se sastoji od popisa kanala gdje separator '<' definira viu razinu prioriteta za kanale navedene na desnoj strani. Default-na prioritizacija se dodjeljuje svim ostalim kanalima koji nisu navedeni.

2.5.2. Definicija sistema

Procesi sistema su definirani u formi linije sistemske deklaracije, koristei sintaksu: System ::= 'system' ID ((',' | '<' ) ID)* ';' Linija sistema sadri listu predloaka koji ekaju da budu instancirani u procese. Predloci bez parametara instanciraju se u tano jedan proces sa istim imenom. Predloci s parametrima dovode do vie instanciranja vie procesa koji se razlikuju po kombinaciji argumenata. Notacija za instanciranje procesa je: Process ::= ID '(' Arguments ')' Sljedei primjer pokazuje sistem koji se sastoji od pet procesa (P, Q(0), Q(1), Q(2) i Q(3)). Automatsko vezivanje parametara predloaka je vrlo korisno kod modela koji se sastoje od velikog broja gotovo identinih procesa.
process P() { state s...; ... } process Q(int[0,3] a) { state t...;

28

... } system P, Q;

Mogue je definirati i prioritete procesa pomou separatora '<' , proces na desnoj strani ima vei prioritet. U sistemima s prioritetima i kanala i procesa, predloci se prvo porede u odnosu na kanale. U sluaju da kanali imaju isti prioritet onda se vri poreenje po prinicipu procesa.

2.6. Vremenski automati u UPPAAL-u

UPPAAL proiruje vremenske automate sa sljedeim dodatnim karakteristikama [10]: Template automata

Template automata se definie kao set parametara koji mogu biti bilo kojeg tipa (npr. int, chan i sl.). Ovi parametri se zamjenjuju sa datim argumentima koji su dodjeljeni procesima prilikom njihove deklaracije. Konstante

Konstante se deklariu kao const name value. Konstante se po definicije ne mogu mijenjati i moraju imati cjelobrojnu vrijednost. Ograniene cjelobrojne varijable

Ove varijable se deklariu kao int[min,max] name, gdje su min i max donja i gornja granica, respektivno. Guard-ovi, invariant-i i asignment-i mogu sadravati izraze ije vrijednosti prelaze granice ogranienih cjelobrojnih varijabli. Zbog toga se ove granice provjeravaju u procesu verifikacije i prekoraena ogranienja vode do nepravilnih stanja, koja se dalje ne uzimaju u obzir. Binarni sinhronizacijski kanali

Ovi kanali se deklariu kao chan c. Tranzicija (engl. edge) oznaena sa c! se sinhronizira sa drugom tranzicijom koja je oznaena sa c?. Ukoliko su mogue razliite kombinacije, onda se sinhronizacijski parovi biraju na nederetministiki nain. Broadcast kanali

Ovi kanali se deklariu kao broadcast chan c. U broadcast sinhronizaciji jedan predajnik c! moe da se sinhronizira sa veim brojem prijemnika c?. Svaki prijemnik koji je u mogunosti

29

da se sinhronizuje u trenutnom stanju, mora to i uraditi. Ukoliko nema prijemnika, predajnik ipak moe izvriti c! akciju (broadcast slanje nije nikad zabranjeno, odnosno blokirano). Hitni sinhronizacijski kanali

Ovi kanali se deklariu tako to se ispred obine deklaracije kanala doda kljuna rije urgent. U ovom sluaju, ne smiju postojati kanjenja ukoliko se tranzicija izvrava na hitnom kanalu. Tranzicije koje koriste iste hitne kanale za sinhronizaciju ne smiju imati vremenska ogranienja, npr. guard-ove satova. Hitne lokacija

Ove lokacije semantiki odgovaraju dodavanju dodatnog sata x, koji se resetuje na svim dolaznim tranzicijama, i ima invariant x<=0 na toj lokaciji. Dakle, kada se sistem nalazi u hitnoj lokaciji nije dozvoljeno kanjenje, tj. protok vremena. Izvrive lokacije

Ove lokaciju uvede vee restrikcije u pogledu izvravanju u odnosu na hitne lokacije. Stanje je izvrivo ukoliko je bilo koja od lokacija u stanju izvriva. U ovakvom stanju ne smije biti kanjenja i sljedea sinhronizacijska tranzicija mora ukljuiti izlazni edge barem jedne izvrne lokacije. Nizovi

Nizovi su dozvoljeni za satove, kanale, konstante i cjelobrojne varijable. Oni se definiu dodjeljivanjem veliine nazivu varijable npr. chan c [4]; clock a[2]; int[3,5]; u[7];. Inicijalizatori

Oni se koriste za inicijalizaciju cjelobrojnih varijabli i nizova cjelobrojnim varijabli. Npr. int i := 2; ili int i[3] := 1, 2, 3;.

2.7. Izrazi u UPPAAL-u

Izrazi u UPPAAL-u se odnose na satove i cjelobrojne varijable, te se koriste sa sljedeim labelama [10]: Select

Select labela sadri zarezom odvojenu listu name : type izraza gdje je name ime varijable i type definisani tip (kreirani ili ve postojei). Ove varijable su prisutne samo na dodjeljenom edge-u i dodjeljuju im se nedeterministike vrijednosti u skladu sa njihovim tipom.

30

Guard

Guard je poseban izraz kojem se dodjeljuje boolean vrijednost. Samo satovi, cjelobrojne varijable i konstante (ili nizovi ovih tipova) mogu imati guard-ove. Podaci tipa clock se jedini porede sa cjelobrojnim izrazima, te guard-ovi dodjeljeni satovima predstavljaju osnovne konjunkcije, odnosno veze izmeu izraza i tipova podataka (disjunkcije su dozvoljene u cjelobrojnim uslovima). Guard-ovi moraju biti true kako bi bila omoguena tranzicija kojoj su oni dodjeljeni. Sinhronizacija

Sinhronizacijska labela je u obliku Expression!, Expression? ili je prazna. Ovim izrazima se dodjeljuju vrijednost kanala, te se odnose na cjelobrojne vrijednosti, konstante i kanale. Assignment

Asignment labela je zarezom-odvojena lista izraza sa popratnim efektima. Izrazi se moraju odnositi samo na cjelobrojne vrijednosti, konstante i satove, pri emu se satovima dodjeljuju samo assign cjelobrojne vrijednosti. Assigment izrazi se izvravaju kada se njima odgovarajua tranzicija izvri. Invariant

Invariant je poseban izraz koji vrijedi samo za cjelobrojne vrijednosti, konstante i satove. Predstavlja skup uslova oblika x < e ili x <= e gdje je x oznaka sata, a e predstavlja odgovarajuu cjelobrojnu vrijednost.

2.8. Query jezik u UPPAAL-u

Glavni cilj mehanizma za provjeru modela jeste da provjeri da li model zadovoljeva zahtjevanu specifikaciju, odnosno da izvri verifikaciju kreiranog modela. Zahtjevana specifikacija modela mora biti izraena jezikom koji je formalno definisan. UPPAAL koristi pojednostavljenu TCTL logiku kao query jezik. On se sastoji od formula stanja i formula putanja. Formule stanja opisuju pojedninana stanja, dok formule putanja opisuju putanje u modelu. Formule putanja se dijela na formule dostupnosti (engl. reachability), sigurnosti (engl. safety) i liveness formule. [10]

31

2.8.1. Formule stanja

Formula stanja je izraz koji moe vrijediti za neko stanje bez provjere ponaanje modela Pomou ovih formula se moe provjeriti da li je neki proces na datoj lokaciji koritenjem izraza oblika P.1 gdje je P proces i 1 traena lokacija. Takoer, pomou posebne formule stanja, u UPPAAL-u se provjerava deadlock stanje. Ova formula se jednostavno sastoji od kljune rijei deadlock i zadovoljena je za sva deadlock stanja. Pod deadlock stanjem se podrazumijeva stanje iz kojeg ne postoje izlazne tranzicije, kao ni tranzicije narednih stanja. [10] [7]

2.8.2. Formule putanja

1. Svojstva dostupnosti (engl. Reachability Properties)

Pomou ovih svojstava se vri provjera da li data formula stanja, tj. logika p, moe biti zadovoljena bilo kojim dostupnim stanjem. Postoje dvije vrste ovih kvatifikatora: E <> p ::= mogue je pronai stanje za koji vrijedi logika p. Odnosno postavlja se pitanje da li postoji putanja koja poinje u inicijalnom stanju, takva da na kraju p bude zadovljena du te putanje. Ovo su tzv. 'Mogua' svojstva. A <> p ::= 'neizbjeno p', automat e sigurno dostii stanje u kojem je p istinito (p je istinito u nekoliko stanja na svim putanjama). Odnosno, postavlja se pitanje da li e p biti na kraju zadvoljeno du svih putanja koje poinju u inicijalnom stanju. Ovo su tzv. 'Konana' svojstva. 2. Svojstva sigurnosti (engl. Safety Properties) Ova svojstva provjeravaju da li data formula stanja, tj. logika p, moe biti uvijek izbjegnuta. To znai da je sistem siguran u smislu da se ne moe desiti nikakva specifina opasnost. Postoje dvije vrste sigurnosnih svojstava: A [] p::= Postavlja se pitanje da li je p istinito u svim dostupnim stanjima. Ovo su tzv. 'Invarijantna' svojstva. E [] p::= Postoji putanja na kojoj je p istinito za sva stanja. Odnosno, postavlja se pitanje da li postoji najvea putanja, takva da je p uvijek istinito. Pri emu se najvea putanja definie kao putanja koja je ili beskonana ili kod koje posljednje stanje nema izlaznih tranzicija. Ovo su tzv. 'Potencijalna' svojstva. 32

Npr. A [] not deadloack znai da u sistemu ne postoji niti jedan deadlock. 3. Liveness svojstva Ova vrsta kvatifikatora oznaava da e se neto desiti u konanici. To znai da bilo koja poruka koja je poslana treba biti na kraju i primljena. p - - > f ::= p uvijek vodi ka f, to se moe oznaiti kao p A <> f. To znai da kad god je p zadovljeno, na kraju e i f biti zadovoljeno. Ovo su tzv. 'Vodi ka' svojstva. Na sljedeoj slici su prikazane formule putanja koje podrava UPPAAL.

Sl.2. 6 Formule putanje [7]

Na slici 2.6 je prikazano stablo stanja za pet razliitih vrsta svojstava, tj. svojstva sigurnosti, dostupnosti i liveness svojstva. Stanja koja zadovoljavaju p su oznaena utim vorovima, dok su tranzicije koje odgovaraju putanjama, na kojima se procjenjuju ova svojstva, oznaene podebljanim strelicama. U gornjem lijevom dijelu slike razmatra se sluaj kada je A [ ] p, to znai da je p istinito u svim dostignutim stanjima. U ovom sluaju p treba da vrijedi za sve putanje prikazanog stanja, te da sva stanja na pojedinanoj putanji zadovaljavaju p. Zbog toga su svi vorovi u stablu stanja oznaeni utom bojom. Tranzicije koje odgovaraju putanjama su predstavljene podebljanim strelicama.

33

U gornjem dijelu u sredini se razmatra sluaj E < > p, to znai da postoji barem jedno stanje za koje je p istinito. U ovom sluaju p treba da vrijedi za barem jednu putanju iz prikazanog stabla, te da barem jedno stanje u stablu zadovoljava p. Zbog toga je samo jedan vor u drvu stanja oznaen utom bojom. Tranzicije koje odgovaraju toj putanji su predstavljene podebljanim strelicama. U gornjem desnom dijelu slike razmatra se sluaj kada je p -- > f ili p A <> f , to znai da ukoliko je p istinito u nekom stanju postoji nekoliko stanja na svim putanja u stablu za koje je f istinito. Zbog toga je stanje p i stanja f na ostalim putanjama oznaena utom bojom. . Tranzicije koje odgovaraju putanjama su predstavljene podebljanim strelicama. Na slici dole desno razmatra se sluaj kada je A < > p, to znai da postoji nekoliko stanja na svim putanja u stablu za koje je p istinito. U ovom sluaju p treba da vrijedi za sve putanje stabla, te da barem jedno stanje pojedinane putanje u drvu zadovoljava p. Zbog toga je samo jedan vor svake putanje u stablu oznaen utom bojom. Tranzicije koje odgovaraju putanjama su predstavljene podebljanim strelicama. Na slici dole desno razmatra se sluaj kada je E [ ] p, to znai da postoji putanja na kojoj je p istinito za sva stanja. U ovom sluaju p treba da vrijedi za barem jednu putanju iz prikazanog stabla, te da sva stanja te putanje zadovoljavaju p. Zbog toga su svi vorovi odgovarajue putanje oznaeni utom bojom. Tranzicije koje odgovaraju toj putanji su predstavljene podebljanim strelicama.

34

3. Verifikacija Subscriber protokola

U ovom poglavlju opisan je postupak verifikacije Subscriber protokola pomou UPPAAL alata. Kako je ve reeno UPPAAL predstavlja alat koji koristi metod verifikacije pomou provjere modela, te stoga prvi korak ka verifikaciji Subscriber protokola je modeliranje ovog protokola. Nakon modeliranja protokola izvrena je simulacija datog modela. Nakon uspjene simulacije mogue je prei na posljednji korak postupka verifikacije, a to je verifikacija pomou TCTL query jezika.

3.1. Opis protokola

Subscriber je protokol za uspostavu IP telefonskog poziva. Za slanje i prijem poruka preko mree koristi se TCP protokol, ime je osigurana pouzdana isporuka poruka. Protokol treba osigurati funkcionalnosti pozivanja korisnika (unosom IP adrese i porta korisnika), odbijanja poziva, prihvatanja poziva i raskida veze. U sluaju nejavljanja korisnika u roku od 2 minute, osigurati automatsku obustavu procedure uspostave poziva. Kao interne poruke koristit e se: Call - poruka koja pokree proceduru pozivanja korisnika na strani pozivaoca, Accept - poruka koja slui za prihvatanje poziva na pozvanoj strani, Decline - poruka koja slui za odbijanje poziva na pozvanoj strani, OnHook - poruka koja pokree proceduru prekida uspostavljenog poziva ili prekida proceduru uspostave poziva, T_Expired - poruka koju alje Timer kada istekne predefinisano vrijeme,

Kao eksterne poruke koristit e se: SETUP - poruka koju alje pozivaoc prema pozvanoj strani kada eli uspostaviti poziv, RING - poruka koju alje pozvana strana prema pozivaocu kada primi zahtjev za novi poziv, ANSWER - poruka koju alje pozvana strana prema pozivaocu kada eli prihvatiti dolazni poziv,

35

RELEASE(REJECT) - poruka koju alje pozvana strana prema pozivaocu kada eli odbiti dolazni poziv, RELEASE(NO_ANSWER) - poruka koju alje pozvana strana prema pozivaocu ako se korisnik ne javi u roku od 2 minute, DISCONNECT - poruka koju alje bilo koja strana kada eli prekinuti ve uspostavljeni poziv.

3.2. Model Subscriber protokola

Prva faza kod verifikacije ispravnosti provjerom modela je oblikovanje formalnog modela. Model mora sadravati opis svojstava koje se ele provjeriti prilikom verifikacije. S druge strane, model mora apstrahirati one detalje koji ne utiu na provjeru eljenih karakteristika, a poveavaju kompleksnost postupka verifikacije. Ako se provjerava aspekt komunikacijskih protokola vezan za proceduralna pravila, tada nije interesantan format poruka koje se razmjenjuju. Model Subscriber protokola u UPPAAL-u sastoji se od etiri paralelna automata, realiziranih pomou template-a nazvanih LamijaApplication, Lamija, ErmaApplication, Erma. Dva automata predstavljaju uesnike komunikacije (Lamija i Erma), koji imaju mogunost iniciranja i raskida poziva. Automati koji diktiraju iniciranje i prekidanje poziva uesnicima komunikacije predstavljaju druga dva automata i igraju ulogu aplikacije za prva dva automata. Rad automata je kontroliran pomou dva sata x i y, koji su globalno deklarisani. Kako bi se osiguralo da obje strane ne poalju istovremeno zahtjev za uspostavu poziva, deklarisani su logiki flag-ovi Aactive i Bactive, inicijalno postavljeni na false. Ovi flag-ovi oznaavaju koja strana je ustvari inicijator poziva i samo jedan flag moe imati vrijednost true u nekom trenutku, tj. nikada ne mogu oba postati istinita. Oni imaju i dodatnu ulogu u procesu sinhronizacije automata. Pomou njih se osigurava da poruke koje alje automat, koji predstavlja aplikaciju jednog od automata, prima samo njemu odgovarajui automat, a ne automat pridruen drugoj aplikaciji. Nakon pokretanja UPPAAL alata pojavit e se Editor kao na slici 2.2. Samim pokretanjem ve je otvoren jedan template, te crtanje prvog automata moe odmah poeti. Editor ima etiri alata za crtanje pomou kojih se grade automati, nazvani Select, Location, Edge i Nail (slika 3.1).

36

Sl.3. 1 etiri alata za crtanje automata

Select alat se koristi za selektovanje, pomjeranje, modificiranje i brisanje elemenata. Location alat se koristi za dodavanje novih lokacija. Jednostavnim klikom na lijevo dugme mia dodaje se nova lokacija. Nakon dodavanja nove lokacije pomou alata select mogue je dodijeli lokaciji ime, tip (initial, urgent, committed, ukoliko nije selektovan nijedan tip podrazumijeva se da je lokacija obina (engl. ordinary)), vrijednost za polje Rate of Exponential i polja invariant (slika 3.2).

Sl.3. 2 Editovanje lokacije

Edge alat se koristi za dodavanje novih edge-eva izmeu lokacija. Takoer, pomou alata select mogue je dodijeliti vrijednosti poljima select, guards, sync i update.

37

Sl.3. 3 Editovanje edge-a

Nail alat se koristi za dodavanje novih nail-ova na edge-eve, odnosno mjesta gdje edge moe promijeniti usmjerenost. Za na model nail-ovi nisu potrebni. Kao prvi template kreirali smo LamijaApplication, dakle automat koji diktira iniciranje i raskid sesije automatu Lamija. Izged LamijaApplication template-a je dat na slijedeoj slici.

Sl.3. 4 LamijaApplication template

38

Kako je pokazano na slici 3.4, ovaj automat ima tri lokacije: Idle, Busy i Processing. Lokacija Idle je inicijalna lokacija s invarijantom x<2, to omoguava da se sistem sam automatski pokrene, jer nakon isteka dvije vremenske jedinice LamijaApplication automat e poslati poruku CallA, samo u sluaju da automat ErmaApplication nije ve poslao zahtjev za uspostavu poziva. Nakon slanja CallA poruke, automat postavlja flag Aactive na true i prelazi u lokaciju Busy koja predstavlja obinu lokaciju s invarijantom x<5000. Invarijant lokacije Busy omoguava da se poziv zavri nakon isteka 5000 vremenskih jedinica, ime se osigurava da automat ne zaglavi u ovoj lokaciji. Nakon isteka 5000 vremenskih jedinica ovaj automat alje onHookA! poruku automatu Lamija, resetira sat x, postavlja flag Aactive na false i prelazi u Idle lokaciju. Takoer, automat moe napustiti lokaciju Busy po prijemu poruke PrekiniA od automata Lamija za x<5000 i prei u Idle lokaciju. Ukoliko, automat Lamija nije inicijator poziva ve odredite, onda e automat LamijaApplication u Idle lokaciji primiti poruku zoveB od automata Lamija, kojom se zahtjeva odgovor pozivajue aplikacione strane u obliku jedne od tri poruke Accept, Decline ili T_expired. Poruka zoveB je uvedena iz razloga da se na neki nain obavijesti aplikacija pozvanog automata na dolazei poziv. Prijemom zoveB poruke automat LamijaApplication prelazi u Processing lokaciju s invarijantom x<120 (120 predstavlja 2 minute). Ovisno o vrijednosti sata x automat e poslati jednu od tri mogue poruke. Za 1<x<35 automat alje Accept!, za 35 <=x<110 automat alje Decline i za x>=110 alje T_expired i prelazi u Idle lokaciju. Da bi kreirali novi template potrebno je kliknuti na Edit->Insert Template. Slijedei template koji smo kreirali je automat Lamija, koji igra ulogu uesnika komunikacije. Izgled ovog template-a je dat na slijedeoj slici.

39

Sl.3. 5 Template Lamija automata

Ovaj automat moe biti u jednoj od slijedeih lokacija: Idle, Call_initiated, Ringing_A i Call_established. Invarijanti na ove lokacije nisu potrebni, jer sistemom upravljaju automati koji igraju ulogu aplikacije. Postoje dva mogua sluaja: automat Lamija je pozivajua strana ili automat Lamija je pozvana strana. Prvo emo razmotriti sluaj kada je automat Lamija pozivajua strana. Ako

LamijaApplication inicira poziv i poalje poruku CallA, automat Lamija e se sinhronizovati s ovom porukom pomou oznake CallA?, i napustit e Idle lokaciju. Poziv prema drugoj strani se inicira slanjem SETUP poruke. Da bi se obezbjedilo da se poziv inicira bez ikakavog kanjenja, dodate su nove lokacije tipa committed. Nazive za ove lokacije nije potrebno navoditi jer automat u njima boravi x<=0. Uvoenjem committed lokacija postignuta je 40

sinhronizacija obje strane komunikacije, tj. onemogueno je nenormalno ponaanje sistema. Dakle, prijemom CallA poruke, automat Lamija alje SETUP poruku na koju se sinhronizuje automat Erma, i prelazi u lokaciju Call_initiated u kojoj oekuje prijem poruke RING. Po prijemu poruke RING automat Lamija prelazi u Ringing_A lokaciju, u kojoj takoer eka na prijem jedne od tri mogue poruke ANSWER, RELEASE_NO_ANSWER ili RELEASE_REJECT. Prijemom zadnje dvije poruke, alje PrekiniA poruku automatu LamijaApplication, te prelazi u Idle lokaciju i resetira sat x i flag Aactive postavlja na false. Prijemom ANSWER poruke prelazi u Call_established lokaciju. Bitno je napomenuti da edgevi koji se odnose na ove poruke imaju guard u obliku Aactive==true && Bactive==false, ovim je osigurano da automat moe primiti ove poruke samo u sluaju da je on pozivajua strana. Automat Lamija iz lokacije Call_established moe prei u Idle lokaciju na dva mogua naina. Prvi nain jeste da dobije DISCONNECT poruku od automata Erma, po ijem prijemu odmah generie poruku PrekiniA, resetira sat x, postavlja Aactive flag na false i prelazi u stanje Idle lokaciju.Drugi nain predstavlja istek tajmera u lokaciji Busy automata LamijaApplication ime se generie poruka onHook. Po prijemu ove poruke, automat Lamija alje DISCONNECT poruku automatu Erma, resetira sat x, postavlja Aactive flag na false i prelazi u stanje Idle lokaciju. U sluaju da je automat Lamija pozvana strana, u lokaciji Idle ovaj automat oekuje prijem poruke SETUP. Po prijemu ove poruke, pomou committed lokacija omogueno je istovremeno slanje RING poruke automatu Erma, kao i zoveB poruke automatu LamijaApplication. Takoer, na edge-u koji se odnosi na prijem SETUP poruke resetuje se sat x ime je omogueno da automat LamijaApplication u stanju Processing ima tano na raspolaganju 120 vremenskih jedinica. Isporukom navedenih poruka, automat prelazi u stanje RINGING_A, u kojem oekuje prijem jedne od tri mogue poruke: Accept, Decline i T_expired. Edge-evi koji se odnose na ove poruke imaju guard u obliku Aactive==false && Bactive==true, ime se osigurava prijem ovih poruka samo u sluaju da je automat Lamija pozvana strana. Po prijemu Accept poruke automat istovremeno preko committed lokacije alje ANSWER poruku na koju se sinhronizuje automat Erma, resetuje sat x ime se dozvaljava automatu LamijaApplication boravak u stanju Busy tano 5000 vremenskih jedinica, te prelazi u Call_established lokaciju. Ponaanje automata u ovoj lokaciji je isto kao za prethodni sluaj. Prijemom Decline poruke automat Lamija generie poruku RELEASE_REJECT, resetira sat x i postavlja flag Aactive na false. U sluaju da primi

41

T_expired alje poruku RELEASE_NO_ANSWER, resetira sat x i postavlja flag Aactive na false. Na RELEASE_REJECT i RELEASE_NO_ANSWER se sinhronizuje automat Erma. Pratei istu logiku, kreirani su template za automate Erma i ErmaApplication. Struktura ova dva template data su na slijedeim slikama. Ovim automatima upravlja sat y. Razlike u odnosu na prola dva automata je samo u pojedinim nazivima poruka: CallB, PrekiniB i zoveA. Ove poruke su uvedene samo kao indikacija komunikacije izmeu automata i pridruene im aplikacije.

Sl.3. 6 Template ErmaApplication automata

42

Sl.3. 7 Template Erma automata

Nakon kreiranja svih template-a, prije pokretanja simulacije potrebno je deklarisati koritene satove, flag-ove, poruke, procese i dodjeliti sistemu kreirane procese. Deklaracija satova, flagova i poruka je izvrena globalno i vri se tako to se u lijevom uglu Editor-a klikne na Declarations i u prozoru koji se otvori napiu deklaracije navedenog, kao to je uraeno na slijedeoj slici. U UPPAAL-u, kako je ve reeno slanje i primanje poruke se odnosi na kanale, te se deklaracija poruka poistovjeuje s deklaracijom kanala.

43

Sl.3. 8 Deklaracija varijabli sata, kanala i flag-ova

Takoer, neophodno je kreirane template-e automata pridruiti odgovarajuim procesima, potom deklarisati sistem, ime se template instanciraju u procese. To se postie sistemskom deklaracijom, kliknuti na System Declarations u lijevom uglu Editor-a i unijeti vrijednosti kao na slijedeoj slici.

Sl.3. 9 Sistemska deklaracija

Dakle, procesu ApplicationA dodjeljena je instanca template-a automata LamijaApplication, procesu ApplicationB dodjeljena je instanca template-a automata ErmaApplication, procesu A dodjeljena je instanca template-a automata Lamija, a procesu B dodjeljena je instanca template-a automata Erma. Sistemu koji se modelira dodjeljena su etiri ve navedena procesa.

44

3.3. Simulacija modela Subscriber protokola

Nakon to je kreiran model Subscriber protokola, moe se prei na slijedei korak verifikacije protokola na bazi provjere modela, a to je simulacija. Klikom na ikonu Simulator u gornjem lijevom uglu, pojavit e se prozor kao na slijedeoj slici. Klikom na ovu ikonu automatski se vri provjera sintakse modela, te u sluaju greke pojavit e se poruka da postoje greke sintakse, koje su locirane unutar Editor-a u donjem dijelu prozora s tano definisanom pozicijom greke, kao i njenim opisom. Provjera sintakse moe se izvrti i pritiskom na dugme F7 na tastaturi ili pak preko Tools->Check Syntax.

Sl.3. 10 Simulator modela Subscriber protokola

Kako pokazuje slika 3.10, a kako je ve reeno u poglavlju 2.3. Simulator omoguava uvid u mogue tranzicije (u sluaju Subscriber protokola dvije su mogue inicijalne tranzicije), uvid u stanje varijabli, pogled na sistem, odabir moguih tranzicija (Simulation Trace) i MSC dijagram. Drag out pokazuje stanja varijabli, inicijalno za model Subscriber protokola flagovi su postavljeni na false (Aactive=0, Bactive=0), sat x i y pripadaju intervalu od 0 do 2 (odreeni invarijantom lokacije Idle procesa ApplicationA i ApplicationB). Inicijalne

45

tranzicije su CallA:ApplicationA->A i CallB:ApplicationB->B, koja od ove dvije tranzicije e se prva desiti nedeterministiki je definisano. Ukoliko se aktivira Random simulacija, u Simulatoru se moe vidjeti koje tranzicije se deavaju, kako varijable mjenjaju vrijednosti, te kako automati mjenjaju lokacije na tranzicije (slika 3.11). Izmjena poruka izmeu automata i posljedina prelaenja u lokacije mogu se vidjeti na kreiranom MSC dijagramu (slika 3.12). Ako se Random simulacija beskonano vrti bez naznake na deadlock, to je dobar znak da bi verifikacija mogla biti potvrdna.

Sl.3. 11 Random simulacija modela Subscriber protokola

46

Sl.3. 12 MSC dijagram za random scenarij

3.4. Verifikacija modela Subscriber protokola

Posljednji korak pri verifikaciji protokola na bazi provjere modela, predstavlja verifikacija pomou TCTL query jezika. Klikom na ikonu Verifier u gornjem lijevom uglu UPPAAL GUI-a, pojavit e se prozor kao na slici 2.5. Postavke verifikacije su default-ne kako je ve navedeno u poglavlju 2.1.5, ovo se moe provjeriti klikom na Options u gornjem uglu UPPAAL GUI-a. Na slijedeoj slici dato je nekoliko Query-a koji su uspjeno verifikovani (zelena loptica), a neki od njih e biti objanjeni u nastavku.

47

Sl.3. 13 Verifikacija nekih TCTL Query-ija

1. Svojstva dostupnosti Iz klase ovih svojstava verificirali smo slijedee: A <> A.Call_established imply A.Idle - odnosi se na injenicu da e automat A iz lokacije Call_established uvijek prei u lokaciju Idle, ovo je neizbjeno; E<> (A.Ringing_A && B.Ringing_B) mogue je pronai trenutak u kojem je automat A u lokaciji Ringing_A , a automat B u lokaciji Ringing_B; E<> (y==5000 || x==4999) vrijednost sata x dostie makar u jednom trenutku vrijednost 4999, ili vrijednost sata y dostie makar u jednom trenutku vrijednost 5000; E<> B.Ringing_B imply B.Idle mogue je da automat B iz lokacije Ringing_B pree u lokaciju Idle. 2. Svojstva sigurnosti Iz klase ovih svojstava verificirali smo slijedee: A[] not deadlock ne postoji niti jedan deadlock u sistemu;

48

A[] A.Call_initiated+ B.Call_initiated<=1 u sistemu je mogue da samo jedan ili pak nijedan automat bude u lokaciji Call_initiated, ne moe se desiti sluaj da dva automata istovremeno budu u lokaciji Call_initiated:

A[] A.Call_initiated imply Aactive==true ako je automat A u lokaciji Call_initiated onda to implicira da je flag Aactive postavljen na true; A[] x<=1 && x>=35 not B.Call_established ako je vrijednost sata x manja ili jednaka od 1 i vea ili jednaka 35, tada automat ApplicationA nee generisati poruku Accept, te stoga automat B nee prei u lokaciju Call_established;

E[] not A.Call_initiated mogue je pronai putanju u prostoru stanja na kojoj automat A ne dostie lokaciju Call_initiated, ovo je posljedica toga da i automat B moe inicirati poziv;

A[] AplicationA.Processing+ApplicationB.Processing<=1 u sistemu je mogue samo da automat ApplicationA bude u lokaciji Processing ili pak samo automat ApplicationB ili nijedan.

3. Liveness svojstva Iz klase ovih svojstava verificirali smo slijedee: A.Call_initiated (A.Ringing_A && B.Ringing_B) ako je automat A u lokaciji Call_initiated, onda e sigurno automat A prei u lokaciju Ringing_A kao i automat B u lokaciju Ringing_B; ApplicationA.Processing A.Idle ako je automat ApplicationA u lokaciji Processing tada e sigurno automat A u konanici prei u lokaciju Idle. Ovo su samo neki od hiljade moguih TCTL Query-ja, no u sutini svi ispitani query-ji su istiniti i u skladu s funkcionisanjem Subscriber protokola, ime je postupak verifikacije Subscriber protokola uspjeno zavren.

49

Zakljuak
Vremenski automati su efikasan formalni jezik za opis ponaanja sistema, pogotovo sistema koji imaju izraene uvjete u vremenskoj domeni. Upotrebom vremenskih automata mogue je opisati ponaanje sistema slino dijagramima stanja, uz dodatak vremenskih ogranienja. Vremenska ogranienja ponaanja opisuju se upotrebom varijabli sata. Varijable sata opisuju prolazak vremena u prostoru realnih brojeva i mogu odrediti npr. trajanje pojedinog stanja ili uslove prelaza izmeu stanja. Stanje sistema odreeno je s dvije komponente diskretnom (lokacijom u kojoj se sistem nalazi) i kontinuiranom (vrijednou varijabli sata). Formalna analiza sistema opisanog vremenskim automatom otkriva mogunost ulaska u nedozvoljeno stanje, ime se mogu otkriti skrivene vremenske zavisnosti. U ovom radu je pokazano kako se teorija vremenskih automata efikasnom moe primjeniti na jedan od alata za automatsku provjeru modela, odnosno kod UPPAAL-a. Cilj razvoja UPPAAL-a je uvijek bio da poslui kao platforma u istraivanju vremenskih automata. Kao takav, vrlo je vaan alat koji obezbjeuje fleksibilnu arhitekturu za eksperimentisanje. Osim gustog vremena, alat podrava jednostavne i sloene tipove podataka, kao to su ogranieni brojevi i nizovi, kao i sinhronizaciju putem zajednikih varijabli i akcija. Specifikacija jezika podrava sigurnost, mogunost mrtvog stanja, tj. deadlock, kao i svojstva odziva. Na primjeru Subscriber protokola, opisan je postupak verifikacije u ovom alatu koji omoguava provjeru modela na bazi TCTL query-ija. Na osnovu izloenog, moe se zakljuiti da postupak verifikacije u UPPAAL-u je efikasan i jednostavan, iz razloga to je sistemom mogue upravljati pomou satova a i injenicom da je omoguena potpuna automatizacija sistema.

50

Literatura
[1] Rajeev Alur i David L. Dill. A theory of timed automata. Theoretical Computer Science Department, Stanford University, CA 94305, 1994. Link [2] Johan Bengtsson i Wang Yi. Timed Automata: Semantics, Algorithms and Tools. Uppsala University [3] [4] Luca Tesei. Specification and Verification using Timed Automata, Ph.D.Thesis. J. Bengtsson, K. Larsen, F. Larsson, P. Petterson, W. Yi. UPPAAL a Tool Suite for Automatic Verification of Real-Time Systems. Uppsala & Aalborg University. [5] J. Bengtsson, F. Larsson. UPPAAL A Tool for Automatic Verification of Real-Time Systems. Master Thesis, 1996. [6] [7] K. Larsen, Petterson, W. Yi. UPPAAL in a Nutshell. Uppsala & Aalborg University. Gerd Behrmann, Alexandre David, Kim G. Larsen, A Tutorial on Uppaal,

Department of Computer Science, Aalborg University, November 2006. Link [8] Edgar P., Formalna verifikacija komunikacijskih protokola u raspodijeljenim

sustavima, Magistarski rad, Zagreb 2005. [9] Claus T., Uffe S., Slicing and Predicate Abstraction for the Uppaal Modeling Language, Aalborg Universitet, Department of Computer Science Dec. 2006 [10] S. Balaguer, Specifcation of properties using live sequence charts, Computer Science Department, Center for Embedded Software Systems (CISS) September 17, 2009.

51

Skraenice
FDT GUI HyTECH ISO J2SE JRE OS OSI RM SGM TA TCTL TLMCT Formal Description Techniques Graphic User Interface The Hybrid TECHnology International Organization for Standardization Java to Platform Standard Edition Java Runtime Environment Operation Semantics Open Systems Interconnection Reference Model State Graph Timed Automata Timed Computation Temporal Logic Temporal Logic Model Checking

52