Formális verifikáció Modellezés és modellellenőrzés

Átírás

1 Formális verifikáció Modellezés és modellellenőrzés Rendszertervezés és -integráció előadás dr. Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék BME-MIT

2 Célkitűzések BME-MIT 2.

3 Ellenőrzések a tervezési fázisban Követelmények elemzése Rendszer specifikálás Üzemeltetés, karbantartás Rendszer validáció Statikus analízis: modellek, tervek, kód vizsgálata Veszély analízis Formális verifikáció: Rendszer verifikáció formális modellek esetén Architektúra tervezés Rendszer integrálás Modul tervezés Modul verifikáció Modul implementáció BME-MIT 3.

4 IEC 61508: Functional safety in electrical / electronic / programmable electronic safety-related systems Példa: Szoftver architektúra tervezés Módszerek és intézkedések BME-MIT 4.

5 Mit szeretnénk elérni? Rendszer modellje Követelmény megadása i Automatikus modellellenőrző n OK Ellenpélda BME-MIT 5.

6 Modellezés: Időzített automaták BME-MIT 6.

7 Mit szeretnénk elérni? Modellezés időzített automatákkal Magasabb szintű modellekből automatikus transzformációval származtatható Rendszer modellje Követelmény megadása i Automatikus modellellenőrző n OK Ellenpélda BME-MIT 7.

8 Automaták és változók Cél: Állapot alapú viselkedés modellezése Alap formalizmus: Véges állapotú automata (FSM) o Állapotok (névvel hivatkozhatók) o Állapotátmenetek Kiterjesztés: Egész értékű változók használata o Változók értéktartománya megadható o Konstansok definiálhatók o Egész aritmetika használható Állapotátmenetek kiterjesztése: o Őrfeltétel hozzárendelése: A változókon kiértékelhető predikátum Az átmenet bekövetkezéséhez igaz kell legyen o Akció hozzárendelése: Értékadás változóknak BME-MIT 8.

9 Kiterjesztések óraváltozókkal Cél: Idő függvényében változó viselkedés vizsgálata o Idő telik az állapotokban o Eltelt időtől (nem csak az állapottól) függő viselkedés o Ellenőrizhető: Adott időn belül elérhető állapotok Modellezési kiterjesztés: Óraváltozók o Azonos rátával haladó konkurens órák (időzítők) o Relatív időmérés (pl. time-out): Időzítők resetelése és leolvasása Használat állapotátmenetekben: o Akciók: Óraváltozók nullázása (resetelés), egymástól függetlenül o Őrfeltételek: Óraváltozók és konstansok a feltételekben Használat állapotokban: o Állapot invariánsok: Óraváltozók és konstansok segítségével megadja, meddig állhat fenn az adott állapot BME-MIT 9.

10 Időzített automata Állapot név clock x; Őrfeltétel Invariáns Akció BME-MIT 10.

11 Az invariánsok és őrfeltételek szerepe clock x; Őrfeltétel Invariáns Az open állapot elhagyásakor a [4, 8] tartományban lehet x értéke 4 8 t BME-MIT 11.

12 Kiterjesztések elosztott rendszerekhez Cél: Együttműködő automaták hálózatának modellezése o Szinkronizáció az egyes automaták között o Együttlépő átmenetek (randevú): szinkron kommunikáció Üzenet küldés és fogadás csak együtt valósulhat meg (küldő vár) (Ezzel aszinkron kommunikáció is leírható) Kiterjesztés: Szinkronizált akciók o Csatornák definiálása (szinkron csatorna) o Üzenetküldés:! operátor a csatornára Üzenetfogadás:? operátor a csatornára Pl: az a nevű csatorna esetén a! és a? akciók a! a? chan a BME-MIT 12.

13 Példa óraváltozókra és szinkronizálásra Deklarációk: clock t, u; chan press; Kapcsoló: Üzenet fogadás Felhasználó: Üzenet küldés BME-MIT 13.

14 További lehetőségek Committed állapot: Atomi végrehajtást ír elő o A kimenő átmenet végrehajtása előtt más automata átmenete nem lehet végrehajtva: bemenő és kimenő átmenet egy atomi műveletként végrehajtva Urgent állapot: késleltetés korlátozása o Nem telhet idő az adott állapotban, ha anélkül lehetséges a kilépés Urgent csatorna: késleltetés korlátozása o Késleltetés nélkül, azonnal végrehajtandó szinkronizáció (de előtte átlapolt végrehajtás lehet) urgent chan a; a! C Nem szerepelhet itt invariáns U Nem szerepelhet itt időzítés őrfeltétel Broadcast csatorna o Egy küldő (mindig tud küldeni) o Több fogadó (ha éppen tud, akkor szinkronizál a küldővel) broadcast chan a; a! a? a? a? BME-MIT 14.

15 Az UPPAAL eszköz Fejlesztése (1999-): o Uppsala University, Svédország o Aalborg University, Dánia Web lap (információk, letöltés, példák): Kapcsolódó eszközök: o UPPAAL CoVer: Tesztgenerálás o UPPAAL TRON: On-line tesztelés o UPPAAL PORT: Komponens alapú rendszerek tervezése o Kereskedelmi verzió: BME-MIT 15.

16 Automata modell BME-MIT 16.

17 Szimulátor BME-MIT 17.

18 Követelmények formalizálása: Temporális logikák --> BME-MIT 18.

19 Mit szeretnénk elérni? Automatikusan ellenőrizhető, precíz követelmények megadása Rendszer modellje Követelmény megadása i Automatikus modellellenőrző n OK Ellenpélda BME-MIT 19.

20 Ellenőrizendő követelmények (példa) Egy példa az ellenőrizendő követelmények jellegére: Egy klímaberendezés állapotai: o Kikapcsolva, bekapcsolva, elromlott, gyengén hűt, erősen hűt, fűt, szellőztet A klíma néhány működési követelménye: o Bekapcsolás után szellőztetést kezd o Erős hűtés csak gyenge hűtés után következhet o A fűtési fázis befejezése után szellőztetni kell o Ha a klíma elromlott, nem fűthet o... BME-MIT 20.

21 Állapotokra vonatkozó követelmények Lokális: Egy-egy állapotra vonatkozó o Az adott állapotban eldönthető a teljesítése (pl. az állapotváltozók értékei alapján) o Példa: A kezdeti állapotban legyen szellőztetés Elérhetőségi: Több állapot bekövetkezési sorrendjére vonatkozó követelmények o Az állapottér vizsgálatával dönthető el a teljesítése o Példa: A fűtési fázis befejezése után szellőztetni kell o Folyamatosan működő rendszerekre is alkalmas o A tipikus követelmények jellege: A rendszer biztonsága A rendszer élő jellege BME-MIT 21.

22 A követelmények típusai Biztonsági jellegű követelmények Veszélyes, nemkívánatos helyzetek elkerülését írják elő: o Minden állapotban kisebb a nyomás a kritikusnál. o A présgép csak becsukott ajtó mellett üzemel. o A processzek között mindig teljesül a kölcsönös kizárás. Formálisan: Invariáns tulajdonság o Minden elérhető állapotban igaz, hogy Élő jellegű követelmények Kívánatos helyzetek elérését írják elő o Az indítás után a présgép kiadja az elkészült terméket. o A zavarás után a folyamat visszakerül stabil állapotba. o Az elküldött üzenet feldolgozása megtörténik a fogadónál. Formálisan: Állapotok elérését fogalmazzák meg: o Elérhető olyan állapot, hogy BME-MIT 22.

23 Követelmények leíró nyelve Elérhetőség: Több állapot bekövetkezési sorrendjére vonatkozó követelmények o Állapotok egymásutánisága mint logikai idő: Jelen időpillanat: Aktuális állapot Következő időpillanat(ok): Rákövetkező állapot(ok) o Temporális (logikai időbeli, sorrendi) operátorok használhatók a követelmények kifejezésére Temporális logikák: o Formális nyelv arra, hogy kijelentések igazságának logikai időbeli változását vizsgálhassuk o Temporális operátorok: mindig, valamikor, mielőtt, addig, amíg, azelőtt, hogy, BME-MIT 23.

24 Temporális logikák Lineáris: Egymás utáni állapotok egy sorozatot alkotnak (minden állapotnak egy rákövetkezője van) logikai idő mint idővonal {Zöld} {Sárga} {Piros} s1 s 2 s 3 {Piros, Sárga} Elágazó: {Zöld} s1 Egymás utáni lehetséges {Villogó} állapotok egy fa struktúrában s5 (minden állapotnak {Piros} s3 több rákövetkezője lehet) logikai idő elágazó idővonalak mentén s4 {Sárga} s5 s2 {Villogó} {Piros} s3 BME-MIT 24.

25 A rendszer működése mint számítási fa {Zöld} {Sárga} {Piros} {Piros, Sárga} s1 s 2 s 3 s4 {Villogó} s5 Automata címkézett állapotokkal s5 {Villogó} {Sárga} s2 {Piros} s3 {Villogó} s5 {Piros,Sárga} s4 {Piros} s3 Számítási fa: Lehetséges elágazások {Zöld} s1 s5 {Piros} s3 {Villogó} s5 {Villogó} {Piros,Sárga} s4 BME-MIT 25.

26 Az utak és állapotok leszámolása Adott állapotból (kezdőállapotból) induló utakat leszámoló operátorok o A: minden útvonalra o E: egy létező útvonalra ( for All ) ( Exists ) Adott úton az egymás után bejárt állapotokat leszámoló operátorok o G: minden állapotra o F: egy jövőbeli állapotra ( Globally) ( Future ) Együtt kell használni ezeket o Utakat mindenképpen le kell számolni o AG, AF, EG, EF összetett operátorok BME-MIT 26.

27 Temporális operátorok Operátor Informális jelentés UPPAAL jelölés AG AF EG EF Minden útvonalon minden állapotra Minden útvonalon a jövőben (előbb-utóbb) Egy létező útvonalon minden állapotra Egy létező útvonalon a jövőben (előbb-utóbb) A[] A<> E[] E<> AG( => AF ) -t követően mindig --> Sehol sincs holtpont A[] not deadlock UPPAAL: és Boole-logikai kifejezések órákon, változókon és állapotokon BME-MIT 27.

28 Minden útvonalra vonatkozó operátorok AG AF AG : Minden útvonalon minden állapotra igaz AF : Minden útvonalon a jövőben előbb-utóbb elérünk olyan állapotba, ahol igaz BME-MIT 28.

29 Egy-egy útvonalra vonatkozó operátorok EG EF EG : Létezik egy útvonal, ahol minden állapotra igaz Van-e kapcsolat AG és EF között? Van-e kapcsolat AF és EG között? EF : Létezik egy útvonal, ahol a jövőben előbbutóbb elérünk olyan állapotba, ahol igaz BME-MIT 29.

30 Feltételes elérhetőség --> AG( => AF ) = --> Minden útvonalra igaz, hogy bekövetkezése esetén előbbutóbb mindig elérünk olyan állapotba, ahol teljesül Időzítéssel együtt: --> ( and x <= t) ahol x egy óraváltozó, amit akkor reseteltünk, amikor igaz lett BME-MIT 30.

31 Néhány példa követelmények formalizálására Adott egy klímaberendezés, aminek a következő üzemmódokat kell biztosítania: {Kikapcsolva, Bekapcsolva, Elromlott, GyengénHűt, ErősenHűt, Fűt, Szellőztet} Ezekre az állapotokra hivatkozhatunk a követelmények formalizálása során A követelményeket a kezdőállapotra fogalmazzuk meg A követelmény formalizálás fázisában a teljes viselkedést még nem ismerjük (azt a modell írja le, amin ellenőrizzük majd a követelmények teljesülését) Példák formalizált követelményekre: A klíma bekapcsolás után előbb-utóbb mindig elromlik: AF (Elromlott) Ha a klíma elromlik, mindig megjavítják: AG(Elromlott => AF ( Elromlott)) vagy Elromlott --> ( Elromlott) Ha a klíma elromlott, nem fűthet: AG ( (Elromlott Fűt)) A klíma előbb-utóbb kikapcsolható, bármilyen működésbe kezdett: AF (Kikapcsolva) BME-MIT 31.

32 A modellellenőrzés működése Időzített automata Temporális logika Rendszer modellje Követelmény megadása i Automatikus modellellenőrző n OK Ellenpélda BME-MIT 32.

33 Az UPPAAL modellellenőrző Követelmények halmaza szerkeszthető Modell ellenőrzés egyenként is indítható Keresés az állapottérben beállítható: o Mélységi, véletlenszerű mélységi o Szélességi Állapottárolás különféle opciókkal: o Redukció o Alul- illetve felülbecslés Ellenpélda generálható invariánsokhoz: o Legrövidebb, leggyorsabb, vagy akármilyen o Betölthető a szimulátorba (végigjátszható) BME-MIT 33.

34 Az UPPAAL modellellenőrző ablaka BME-MIT 34.

35 Ellenpélda a szimulátorban BME-MIT 35.

36 Mintapélda BME-MIT 36.

37 Egy mintapélda: Kölcsönös kizárás 2 résztvevőre, 3 megosztott változóval (H. Hyman, 1966) o blocked0: Első résztvevő (P0) be akar lépni o blocked1: Második résztvevő (P1) be akar lépni o turn: Ki következik belépni (0 esetén P0, 1 esetén P1) while (true) { P0 blocked0 = true; while (turn!=0) { while (blocked1==true) { skip; } turn=0; } // Critical section blocked0 = false; // Do other things } while (true) { P1 blocked1 = true; while (turn!=1) { while (blocked0==true) { skip; } turn=1; } // Critical section blocked1 = false; // Do other things } Helyes-e ez az algoritmus? BME-MIT 37.

38 Ellenőrizendő követelmények Kölcsönös kizárás: o Egyszerre csak az egyik résztvevő lehet a kritikus szakaszban Lehetséges az elvárt viselkedés: o P0 egyáltalán beléphet a kritikus szakaszba o P1 egyáltalán beléphet a kritikus szakaszba Nincs kiéheztetés: o P0 mindenképpen be fog lépni a kritikus szakaszba o P1 mindenképpen be fog lépni a kritikus szakaszba Holtpontmentesség: o Nem alakul ki kölcsönös várakozás (leállás) BME-MIT 38.

39 Hogyan ellenőrizhetjük a követelményeket? Teszteléssel o Létre tudunk-e hozni minden lehetséges végrehajtást lefedő teszt eseteket? o A problémás esetek figyeléséhez külön ellenőrző kell o A hiba csak az implementáció után derül ki, drágán javítható Modellezéssel és szimulációval o Tudunk-e szimulálni minden lehetséges végrehajtást? o A problémás esetek detektálása nagy odafigyelést igényel o A hibák viszont olcsóbban javíthatók modell szinten Modellezéssel és az állapottér teljes ellenőrzésével o Szisztematikus algoritmus az állapottér teljes felvételéhez o Automatikus a követelmények teljesülésének figyelése Formalizálható követelményekre általános módszer a modell alapú ellenőrzésre BME-MIT 39.

40 A modell UPPAAL-ban (első változat) Deklarációk: bool blocked0; bool blocked1; int[0,1] turn=0; system P0, P1; A P0 automata: Kihasznált modellezési lehetőségek: Közös változók rendszerszintű deklarálása Korlátozott értékkészletű változók while (true) { blocked0 = true; while (turn!=0) { while (blocked1==true) { skip; } turn=0; } // Critical section blocked0 = false; // Do other things } P0 BME-MIT 40.

41 A modell UPPAAL-ban (második változat) Deklarációk: bool blocked[2]; int[0,1] turn; P0 = P(0); P1 = P(1); system P0,P1; A P automata (template) pid paraméterrel: Kihasznált modellezési lehetőségek: Közös változók rendszerszintű deklarálása Korlátozott értékkészletű változók Azonos viselkedésű résztvevők azonos automata template alapján Példányosítás paraméterezéssel Változó tömbök (résztvevőkhöz) while (true) { blocked0 = true; while (turn!=0) { while (blocked1==true) { skip; } turn=0; } // Critical section blocked0 = false; // Do other things } P0 BME-MIT 41.

42 UPPAAL: A követelmények formalizálása Kölcsönös kizárás: o Egyszerre csak az egyik résztvevő lehet a kritikus szakaszban: A[] not (P0.cs and P1.cs) Holtpontmentesség: o Nem alakul ki kölcsönös várakozás (leállás): A[] not deadlock Lehetséges az elvárt viselkedés: o P0 egyáltalán beléphet a kritikus szakaszba: E<>(P0.cs) o P1 egyáltalán beléphet a kritikus szakaszba: E<>(P1.cs) Nincs kiéheztetés: o P0 mindenképpen be fog lépni a kritikus szakaszba: A<>(P0.cs) o P1 mindenképpen be fog lépni a kritikus szakaszba: A<>(P1.cs) BME-MIT 42.

43 UPPAAL: A modellellenőrzés eredménye Nincs holtpont Az élő jellegű követelmények teljesülnek o Mindkét processz beléphet a kritikus szakaszba (lehetőség) Kiéheztetés elkerülése időzítések megadása nélkül nem vizsgálható o Kérdés: Mindenképpen belép-e a kritikus szakaszba? (szükségszerűség) o Speciális probléma: Lehet olyan útvonal is, hogy megáll pl. a kezdőállapotban Ez a valósidejű ellenőrzés jellegzetessége A kölcsönös kizárás nem teljesül! o Ellenpélda: Átlapolódás a két résztvevő között (végigjátszható a szimulátorban) BME-MIT 43.

44 Az algoritmus javítása Peterson algoritmusa P0 résztvevőre (P1 értelemszerű): Hyman: Peterson: while (true) { blocked0 = true; while (turn!=0) { while (blocked1==true) { skip; } turn=0; } // Critical section blocked0 = false; // Do other things } while (true) { blocked0 = true; turn=1; while (blocked1==true && turn!=0) { skip; } } // Critical section blocked0 = false; // Do other things BME-MIT 44.

45 A modellellenőrzés tulajdonságai BME-MIT 45.

46 A modellellenőrzés használata Követelmények elemzése Követelmények Üzemeltetés, karbantartás Rendszer validáció Rendszer specifikálás Modellek Rendszer verifikáció Architektúra tervezés Rendszer integrálás Modul tervezés Modul implementáció Modul verifikáció Új alkalmazások: Modellellenőrzés a forráskód alapján (modell visszafejtés, absztrakció) BME-MIT 46.

47 A modellellenőrzés tulajdonságai Kedvező tulajdonságok: o Garantált eredményt ad: Teljes állapottér bejárás o Lehetséges nagy modell állapotteret is kezelni Akár 10 20, de példa van méretű állapottér ellenőrzésére o Teljesen automatikus eszköz, nem szükséges tervezői intuíció és erős matematikai háttérismeret o Ellenpéldát generál, ami segít a hibák javításában Problémák: o Skálázhatóság nem biztosított (explicit állapottér bejárás) o Elsősorban vezérlés-orientált alkalmazásokra hatékony Komplex adatstruktúrák hatalmas állapotteret jelentenek o Nehéz az eredményeket általánosítani Ha egy protokoll helyes 2 résztvevő esetén, akkor helyes-e N esetén? o A követelmények formalizálása nehéz egy átlagos mérnök számára Nyelvjárások alakultak ki különböző alkalmazási területeken BME-MIT 47.

48 Továbblépés Az ellenőrzött modellek felhasználása Forráskód generálás Monitor szintézis futásidőbeli verifikációhoz Dokumentáció készítés BME-MIT 48.