1 / 14

Formalne metode

Formalne metode. Zašto su potrebne formalne metode u oblikovanju sklopovlja i programskih produkata?. Sklopovlje. Potrebno vrijeme za potpunu simulaciju sklopovlja : Oblikovanje: 256-bit RAM 2 256 = 10 80 mogućih kombinacija početnih stanja i ulaza Pretpostavimo:

verlee
Download Presentation

Formalne metode

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Formalne metode Zašto su potrebne formalne metode u oblikovanju sklopovlja i programskih produkata?

  2. Sklopovlje Potrebno vrijeme za potpunu simulaciju sklopovlja: Oblikovanje:256-bit RAM 2256 = 1080mogućih kombinacija početnih stanja i ulaza Pretpostavimo: Uporabimo svu bližu vidljivu materiju u našoj galaksiji (1017kg) za izradu računala. Svako računalo je veličine jednog elektrona (10-30 kg). Svako računalo izvede 1012 simulacija u sekundi. Započinjemo sa simulacijama u trenutku Big Banga (prije oko 1010 godina). Danas bi dosegli tek mali dio zadatka (0.05%).

  3. Sklopovlje 1011 zvijezda u galaksiji 10100 000 stanja Slike preuzete iz: http://ceit.aut.ac.ir/~szamani/index_files/vhdl_slides/15_2_formal%20verification.ppt

  4. Sklopovlje Pritisak tržišta uvjetuje sve složenije sklopove. Intel: 8000 pogrešaka u Pentuim IV procesoru (prvi procesor koji je bio formalno verificiran). Četverostruko povećanje broja pogrešaka sa svakom generacijom procesora. FDIV pogreška stajala je $500M u ponovnom oblikovanju Pentium procesora.

  5. Programski produkti Primjer 1: Therac – 25

  6. Programski produkti Primjer 1:Therac – 25 Linearni akcelerator za terapiju zračenjem. Projektiran i realiziran: Atomic Energy Canada Ltd. (AEC) Raniji modeli: Therac-6 i Therac-20 s vrlo ograničenom programskom potporom bili su vrlo uspješni. U modelu Therac-25 uvedeno nadgledanje i upravljanje programom. Vjerovalo se da je program pouzdaniji od sklopovlja (ne kvari se). 1985 – prvi incident Pacijent previše ozračen, odrezana dojka i paralizirano rame i ruka. Proizvođač: "To nije bila pogreška uređaja nego rukovatelja!". 1985 – drugi incident Pacijent je umro. Proizvođač promijenio mikro prekidač na koji se sumnjalo da je uzrok. Obavještava korisnike da je uređaj sigurniji 5 redova veličine.

  7. Programski produkti 1985 – treći incident Abnormalna reakcija kože pacijenta. Proizvođač: Izvješće na dvije stranice kojim otklanja pogrešku rukovatelja ili uređaja. 1986 – četvrti incident Kod pacijenta izgubljena funkcija nogu, ruku i vokalnog trakta. Umro je 5 mjeseci kasnije. Proizvođač: Otklanja svaku odgovornost i sugerira da je problem u strujnoj napojnoj mreži a ne u uređaju. 1986 – peti incident Smrt pacijenta 3 tjedna nakon zračenja. Proizvođač: Objavljuje da je pronašao i ispravio pogrešku u rutini sučelja za unos podataka. FDA traži korektivni akcijski plan (CAP).

  8. Programski produkti 1987 – šesti incident Previsoka doza zračenja. FDA proglašava Therac-25 neispravnim. Proizvođač: Ispravlja programske pogreške, ugrađuje dodatnu provjeru sklopovlja. FDA dozvoljava uporabu sustava nakon 5te revizije CAP-a. Uzrok: Upravljački program je dozvolio višestruki pristup zajedničkoj memoriji bez sinkronizacije. (Vrlo slični primjeri rješavat će se u okviru domaćih zadaća i laboratorija.)

  9. Programski produkti Primjer 2: Raketa Ariane 5 (1996.g.)

  10. Programski produkti Primjer 2:Raketa Ariane 5 (1996.g.) Europska raketa za lansiranje komercijalnog tereta. Nasljednik uspješne Ariane 4. Namjena Ariane 5: lansirati teži teret od Ariane 4. 37 sekundi nakon uspješnog lansiranja Ariane je izgubila upravljanje i raspala se. Neispravni upravljački signali poslani su raketnim motorima koji su doveli do neodrživog stresa rakete. Zatajenje sustava izravna je posljedica pogreške u programu. Kvar programa uzrokovao je gašenje radnog programa (kao i pomoćnog programa). Motorima su poslane dijagnostičke naredbe koje su interpretirane kao stvarne što je dovelo do njihanja rakete oko ekstremnih vrijednosti i konačnog raspada.

  11. Programski produkti Primjer 2:Raketa Ariane 5 Pogreška u programu: Pretvorba 64 bitnog broja u pomičnom zarezu u 16 bitni cijeli broj s predznakom dovelo do preljeva ("overflow"). Nije postojao rukovatelj iznimkom za tu specifičnu vrst pogreške. Kako nije postojao specifičan rukovatelj iznimkom, pogrešku preuzima sistemski rukovatelj iznimkom i gasi program. Pomoćni program ("backup") je oblikovan na jednak način te je i posljedica bila jednaka, ugašen je.

  12. Programski produkti Što je dovelo do pogreške u programu: Program koji je zatajio preuzet je od ranije rakete Ariane 4. Poštovan je princip ponovnog korištenja ("reuse") u programskom inženjerstvu. Vrijednost varijable u Ariane 4 nikad ne doseže razinu koja uzrokuje preljev. Rukovanje iznimkom na preljev nije ugrađeno jer je procesor ionako bio jako opterećen. Smatralo se da treba ostaviti malo slobodnog kapaciteta procesora. Ariene 4 ima manju inicijalnu akceleraciju i kasnije povećanje brzine od Ariane 5. Kako je taj dio programa preuzet ("reused"), nije postojao pridruženi nefunkcionalni zahtjev, pa ni mogućnost otkrivanja problema pri korištenju u Ariane 5. Za vrijeme ispitivanja sustava, referentna simulacijska računala nikada nisu generirala pogrešku jer nije bilo zahtjeva temeljem kojih bi se oblikovali testni slučajevi.

  13. Programski produkti Da li se zatajenje moglo izbjeći ? Pogreška nije vezana za uporabljeni programski jezik niti način kodiranja (za razliku od Therac-25). Rigorozna formalna verifikacija te rigorozna analiza zahtjeva pokazala bi pogrešku. Potrebno je verificirati modele na više razina. Uzročne veze u u akcidentu mogu se otkriti samo uporabom logike. Takav pristup zahtjeva strpljivost i vještine savladavanja formalne logike. Mnogi primjeri pokazuju da je ponašanje sustava u svim okolnostima teško predvidjeti (Npr. Izraelski avioni su se rušili kad su letjeli iznad Mrtvog mora; tamo je moguća visina niža od nulte visine razine mora; nije bilo u zahtjevima pa ni u ispitivanju). Konačno: Potrebno je uporabiti FORMALNE METODE U OBLIKOVANJU SUSTAVA ne samo za provjeru što bi sustav trebao raditi nego i za provjeru što sustav ne bi smio raditi.

  14. Preporučena literatura (neobvezna) The Verified Software Initiative: A Manifesto Tony Hoare1, Jayadev Misra2, Gary T. Leavens3, and Natarajan Shankar4 April 16, 2007 1Microsoft Research 2Dept. of Computer Science, The Univ. of Texas at Austin 3Dept. of Computer Science, Iowa State University 4SRI International Computer Science Laboratory

More Related