Kritinių sistemų kūrimas

©Ian Sommerville 2015 Dependable systems specification Slide 1

Kritinių sistemų kūrimas


Tikslai• Paaiškinti kaip klaidų toleravimas ir klaidų

vengimas prisideda prie pasikliautinų sistemų kūrimo.

• Aprašyti pasikliautinų programų kūrimo proceso charakteristikas.

• Apibūdinti programavimo metodus klaidoms vengti.

• Aprašyti klaidų toleravimo mechanizmus ir naudojimo įvairovė bei pertekliškumą.


Įžanga• Kritinių sistemų kūrimas Įžanga (Tikslai, temos,

pasikliautinumas, įvairovė ir pertekliškumas, programos be klaidų, jų kūrimas, klaidų ištaisymo kaštai)


Temos• Pasikliautinas procesas• Pasikliautinas programavimas• Klaidų toleravimas• Klaidų toleravimo architektūros


Programinės įrangos pasikliautinumas

• Apskritai PĮ vartotojai tikisi, kad visa PĮ būtų patikima. Kad ir kaip bebūtų, nekritines taikomąsias programas jie gali būti pasiruošę priimti ir su kai kuriais trūkumais

• Tačiau kai kurioms taikomosioms programoms keliami labai aukšti patikimumo reikalavimai, ir kad programos juos išpildytų, privalo būti naudojamos specialios programavimo technikos


Kaip pasiekti reikiamą pasikliautinumą

• Defektų vengimas» PĮ kuriama taip, kad būtų išvengta žmogaus klaidų

ir taip būtų sumažintas sistemos defektų kiekis» Kūrimo procesas organizuojamas taip, kad PĮ

defektai būtų aptikti ir ištaisyti iki jos pristatymo vartotojui

• Defektų toleravimas» PĮ projektuojama taip, kad defektai pristatytoje PĮ

nesukeltų sistemoje klaidų


Programos be klaidų• Dabartiniai metodai gali užtikrinti gauti santykinai mažas

sistemas be klaidų.• Programos be klaidų suprantamos kaip programos

programos , kurios atitinka specifikaciją. Bet gali būti specifikacijos klaidų.

• Programos be klaidų daug kainuoja tai gali apsimokėti tik išskirtinėse situacijose. Dažnai pigiau priimti programos klaidas ir taisyti pasekmes negu skirti pakankamai resursų programoms be klaidų.


Programinės įrangos be defektų kūrimas

• Reikalinga tiksli (pageidautina formali) specifikacija• Reikalauja organizacinių priemonių kokybei pasiekti• Informacijos slėpimas ir inkapsuliacija yra būtini dalykai

PĮ projektavime• Turėtų būti naudojama programavimo kalba su griežta

kintamųjų tipų kontrole (strict typing) ir klaidų tikrinimu kodo rašymo metu (compile-time checking)

• Turėtų būti išvengta klaidas sąlygojančių struktūrų• Patikimas ir pakartojamas kūrimo procesas


Programų be klaidų kūrimo požymiai

• Pasikliautinas kūrimo procesas• Kokybės valdymas• Formalios specifikacijos• Statinis tikrinimas • Griežti kintamųjų tipai• Saugus programavimas• Informacijos apsauga


Klaidų ištaisymo kaštai

Mažai

Neišaiškintų klaidų kiekis

Daug Labaimažai

Vienos klaidos

pašalinimo

kaštai


Temos• Pasikliautinas procesas (kūrimo procesas,

charakteristikos, atestavimo veiklos) • Pasikliautinas programavimas• Klaidų toleravimas• Klaidų toleravimo architektūros


Patikimas programinės įrangos kūrimo procesas

• Tam, kad užtikrinti minimalų PĮ defektų skaičių, svarbu turėti gerai apibrėžtą, pakartojamą PĮ kūrimo procesą

• Gerai apibrėžtas pakartojamas procesas yra toks, kuris nepriklauso vien tik nuo individualių sugebėjimų, bet gali būti įvykdytas skirtingų žmonių

• Aišku, kad defektų sumažinimo procesui labai svarbus turėtų būti tikrinimas ir atestavimas


Pasikliautino proceso charakteristikos

Dokumentuojamas The process should have a defined process model that sets out the activities in the process and the documentation that is to be produced during these activities.

Standartizuotas A comprehensive set of software development standards that define how the software is to be produced and documented should be available.

Audituotas The process should be understandable by people apart from process participants who can check that process standards are being followed and make suggestions for process improvement.

Su išsamiu testavimu The process should include redundant and diverse verification and validation activities.

Atsparus klaidoms The process should be able to recover from failures of individual process activities.


Temos• Pasikliautinas procesas• Pasikliautinas programavimas (informacijos

saugojimas, saugus programavimas, klaidas sąlygojančios struktūros, išimčių apdorojimas)

• Klaidų toleravimas• Klaidų toleravimo architektūros


Pasikliautinas programavimas• Naudoti programavimo konstrukcijas ir metodus

kurie prisideda prie klaidų vengimo ir toleravimo. • Projekto paprastumas;• Apsaugoti informaciją nuo nesankcionuoto priėjimo; • Minimizuoti nesaugių programavimo konstrukcijų naudojimą.


Informacijos saugojimas• Informacija neapsaugojama tik tose programos dalyse,

kur reikia ją pasiekti. Tam reikia naudoti objektus arba abstrakčius duomenų tipus, kurie palaiko būvį ir pagal jį atlieka operacijas.

• Taip išvengiama klaidų dėl trijų priežasčių:• Sumažinama tikimybė atsitiktinio informacijos pažeidimo;• Informacija apsupama “ugniasienių, todėl mažiau tikėtina , kad

problemos persikels į kitas programos dalis; • Kadangi informacija lokalizuota, mažiau bus padaroma klaidų ir

recenzentai tikriausiai suras klaidas.


Saugus programavimas• Klaidos programoje yra programuotojų

suklydimų pasekmė. • Dažnai klaidos įvyksta, kai žmonės pameta

susietumą tarp programos kintamųjų.• Kai kurios programavimo konstrukcijos turi

polinkį klaidoms, tai jų vengimas sumažina klaidų kiekį.

• Struktūrinis programavimas


Klaidas sąlygojančios (error-prone) struktūros

• Slankaus taško skaičiai• Pagal savo prigimtį netikslūs. Netikslumas gali sąlygoti neteisingus

palyginimus• Rodyklės (Pointers)

• Rodyklės, nukreiptos į klaidingas atminties sritis, gali išgadinti duomenis. Pseudonimų naudojimas vietoj tikrų rodyklių vardų (aliasing) gali padaryti programas sunkiai suprantamas ir sunkiai pakeičiamas

• Dinaminės atminties paskirstymas• Paskirstymas programos vykdymo metu gali iššaukti atminties

perpildymą• Lygiagretumas

• Gali pasireikšti subtiliomis veiksmų sinchronizavimo klaidomis (timing errors) dėl nenumatytos sąveikos tarp lygiagrečių procesų


Klaidas sąlygojančios (error-prone) struktūros

• Rekursija• Klaidos rekursijoje gali iššaukti atminties perpildymą

• Pertrauktys• Pertrauktys gali sukelti kritinės operacijos pabaigą ir padaryti

programą sunkiai suprantamą. Jos gali būti palyginamos su ‘goto’ sakiniais

• Paveldimumas• Kodas nėra lokalizuotas. Tai gali pasireikšti netikėtu elgesiu, kai

padaromi pakeitimai, ir suprantamumo problemomis• Šių struktūrų neturėtų būti vengiama, bet jas naudoti

reikėtų labai atidžiai


Išimčių (exception) apdorojimo operatoriai

• Programos išimtis yra klaida arba kažkokie nenumatyti įvykiai, tokie kaip blogas energijos tiekimas

• Išimties apdorojimo konstrukcijos leidžia apdoroti tokius įvykius be nuolatinio būsenos tikrinimo, kuris yra reikalingas, kad būtų aptiktos išimtys

• Normalių kontrolės konstrukcijų naudojimas, norint aptikti išimtis eilėje kreipinių į įterptinę procedūrą (nested procedure), reikalauja įdėti į programą daug papildomų operatorių ir padidina laiko sąnaudas


Temos• Pasikliautinas procesas• Pasikliautinas programavimas• Klaidų toleravimas (klaidų toleravimo veiksmai,

metodai, klaidos aptikimas, žalos įvertinimo metodai, klaidos toleravimas, saugios tvarkymų procedūros)

• Klaidų toleravimo architektūros


Klaidų toleravimas• Kritinėse situacijose PĮ sistemos turėtų toleruoti klaidas.

Klaidų toleravimas yra būtinas ten, kur yra aukšti reikalavimai parengtumui (availability) arba kur dėl neteisingo sistemos veikimo patiriami labai dideli nuostoliai

• Klaidų toleravimas reiškia, kad sistema gali tęsti operaciją nežiūrint blogo PĮ veikimo

• Net jei atrodo, kad sistema yra be klaidų, vis tiek jos turėtų būti toleruojami, nes gali būti specifikacijų klaidų arba atestavimas gali būti neteisingas


Klaidų toleravimo veiksmai• Klaidų aptikimas

Sistema turi aptikti, kad defektas (neteisinga sistemos būsena) pasirodė

• Žalos įvertinimas Sistemos dalys, kurias paveikė defektas, turėtų būti surastos

• Klaidos atstatymas (recovery) Sistema turi atstatyti savo būseną į žinomą saugią būseną

• Klaidos taisymas (repair) Sistema gali būti modifikuota taip, kad būtų užkirstas kelias

defektų pasikartojimui. Kadangi daugelis PĮ defektų yra trumpalaikiai (transitory), tai dažnai yra nereikalinga


Klaidų toleravimo metodai• Gynybinis programavimas (defensive programming)

Programuotojai įtaria, kad gali būti defektų sistemos kode, todėl įdeda į jį perteklingą kodą (redundant code), tikrinantį sistemos būseną po modifikacijų, tam, kad garantuotų modifikacijos teisingumą

Defektus toleruojančios architektūros PĮ ir Aparatūrinės Įrangos (AĮ) sistemų architektūros, kurios

palaiko AĮ ir PĮ perteklingumą bei defektų toleravimo kontrolerį, aptinkantį problemas ir palaikantį defektų atstatymą

Tai yra labiau vienas kitą papildantys negu prieštaraujantys metodai


Klaidų aptikimas

• Pirmas žingsnis klaidų toleravime yra nustatyti, kad klaida (klaidinga sistemos būsena) įvyko ar įvyks.

• Klaidos aptikimui reikia apibrėžti apribojimus, kurie turi būti išlaikyti visoms legalioms būsenoms ir patikrinti ar visos būsenos išpildo šiuos apribojimus.


Pažeidimų nustatymas• Analizuoti sistemos būseną, kad spręsti apie

pažeidimus sąlygotus sistemos sutrikimo. • Įvertinimas turi nustatyti, kokia būsenų dalis buvo

paveikta sutrikimo.• Bendru atveju tikrinamos visos būsenos, kad

nustatyti ar jų reikšmės yra užduotam intervale.


• Kontrolinės sumos naudojamos pažeidimų nustatymui perduodant duomenis.

• Perteklinės nuorodos gali būti naudojamos duomenų struktūros vientisumo tikrinimui.

• Užsiciklinimą tikrina “Watch dog timers”. Jeigu per užduotą laiką negaunamas atsakymas, konstatuojamas pažeidimas.

Pažeidimų nustatymo metodai


• Tiesioginis koregavimas• Taisomas pažeistas sistemos būvis.

• Atstatomasis koregavimas• Atstatomas sistemos būvis į žinomą saugų būvį.

• Tiesioginiam koregavimui paprastai reikalingos specialios tos srities žinios, kad paskaičiuoti galimus būvio koregavimus.

• Atstatomasis koregavimas yra paprastesnis. Išsaugomi saugūs būviai ir jais pakeičiami pažeisti sistemos būviai.

Klaidos koregavimas ir taisymas


Temos• Pasikliautinas procesas• Pasikliautinas programavimas• Klaidų toleravimas• Klaidų toleravimo architektūros (aparatūros

tolerantiškumas klaidoms, programinės įrangos tolerantiškumas klaidoms, programavimo įvairovė, N-versijų programavimas, įvairovės problemos, koregavimo blokai, specifikacijos priklausomybė, pertekliškumas)


Klaidoms tolerantiška architektūra

• Gynybinis programavimas negali susidoroti su defektais, kurie susidaro dėl sąveikų tarp AĮ ir PĮ

• Neteisingai suprasti reikalavimai gali reikšti, jog tikrinimai (checks) ir su šiais susijęs kodas yra neteisingi

• Sistemoms, kurioms keliami aukšti tinkamumo reikalavimai, gali būti reikalinga specifinė architektūra, suprojektuota tam, kad palaikytų klaidų toleravimą

• Ši architektūra turėtų toleruoti tiek aparatūrinės, tiek ir programinės įrangos sutrikimus


Aparatūrinės įrangos tolerantiškumas klaidoms

• Priklauso nuo trigubo modulinio perteklingumo (triple-modular redundancy - TMR)

• Yra 3 identiškos komponentų kopijos, kurios priima tokius pačius duomenis ir kurių rezultatai yra palyginami

• Jeigu vienas iš trijų rezultatų yra kitoks, jis yra ignoruojamas, ir daroma išvada, kad įvyko modulio trikis

• Paremtas labiau atskirų komponentų sutrikimais nei projektavimo defektais, ir žema tikimybe, kad komponentai pradės veikti neteisingai vienu metu


Aparatūrinės įrangos patikimumas naudojant TMR

komparatorius

Klaidų

A2

A1

A3

Išėjimųpalyginimas


Išėjimo rezultatų parinkimas• Išėjimai palyginami aparatūriškai. • Teisingi išėjimo rezultatai parenkami daugumos

balsavimu.• Klaidingas mazgas gali būti taisomas arba

išjungiamas.


Klaidas toleruojančios programinės įrangos architektūros

TMR sėkmė, užtikrinant klaidų toleravimą, pagrįsta dviem pagrindinėm prielaidom: Techninės įrangos komponentai neturi bendrų projektavimo

defektų Komponentai sutrinka atsitiktinai ir yra maža tikimybė, kad

komponentų klaidos susidarys vienu metu Nė viena iš šių prielaidų netinka programinei įrangai:

Nėra taip paprasta atkartoti tą patį komponentą, nes jo kopijos turės bendrų projektavimo klaidų

Todėl faktiškai yra neišvengiama, kad komponentų trikiai susidarys vienu metu

Todėl programinės įrangos sistemos turėtų būti skirtingos


Projektavimo įvairovė Skirtingos sistemos versijos yra suprojektuotos ir

realizuotos skirtingais būdais. Dėl to jos turėtų turėti skirtingų tipų klaidas

Skirtingi projektavimo metodai (pvz., objektiškai orientuotas ir funkcinės paskirties (function oriented))

Realizavimas skirtingomis programavimo kalbomisSkirtingų įrankių ir vystymo aplinkų naudojimasRealizacijai naudojami skirtingi algoritmai


TMR analogai programinei įrangai

N – versijų (N-version) programavimas Ta pati specifikacija realizuojama skirtingose

versijose skirtingų darbo grupių. Visos versijos skaičiuoja vienu metu ir dauguma išėjimų rezultatų yra išrenkami naudojant balsavimo sistemą

Paprastai tai yra labiausiai naudojamas metodas, pavyzdžiui, Airbus 320


N-versijų programavimas

Versija 1

Versija 3

Išėjimų komparatorius

N - versijų

Sutartasrezultatas

Versija 2


Išvesčių palyginimas AĮ sistemose, išvesčių komparatorius yra paprasta

programėlė, kuris naudoja balsavimo mechanizmą atrenkant išvesties rezultatus

Realaus laiko sistemose gali būti reikalaujama, kad skirtingų versijų rezultatai būtų pateikti tam tikruose laiko rėmuose


N – versijų programavimas Skirtingos sistemos versijos yra suprojektuotos ir

realizuotos skirtingų darbo grupių. Manoma, kad egzistuoja maža tikimybė, jog jos padarys tokias pačias klaidas. Naudojami algoritmai turėtų būti skirtingi, bet gali būti ir kitaip

Yra keletas bandymais paremtų įrodymų, kad paprastai darbo grupės tokiu pačiu būdu klaidingai interpretuoja specifikacijas ir pasirenka tuos pačius algoritmus savo sistemoms


Projektavimo įvairovės problemos

Darbo grupės nėra kultūriškai skirtingos, taigi jos linkusios spręsti problemas tuo pačiu būdu

Būdingos klaidos Skirtingos komandos daro tas pačias klaidas. Kai kurios

realizacijos dalys yra sudėtingesnės nei kitos, taigi visos komandos linkusios daryti klaidas tose pačiose vietose

Specifikacijos klaidos Jei jau specifikacijoje yra klaida, tai atsispindi visose

realizacijose Tai gali būti išspręsta iki tam tikro laipsnio, naudojant įvairias

specifikacijų reprezentacijas


Specifikacijos priklausomybė Abu programinės įrangos pertekliškumo būdai jautrūs

specifikacijos klaidoms. Jei specifikacija neteisinga, sistema gali žlugti

Tokia pati problema egzistuoja ir su technine įranga, bet PĮ specifikacijos paprastai yra sudėtingesnės ir jas sunkiau atestuoti

Kai kuriais atvejais tai buvo išspręsta, sukuriant atskiras PĮ specifikacijas pagal tą pačią vartotojo specifikaciją


Ar reikalingas programinės įrangos pertekliškumas?

Priešingai nei AĮ, programinės įrangos defektai nėra neišvengiamas realaus pasaulio padarinys

Todėl kai kurie žmonės mano, kad aukštesnis patikimumo ir tinkamumo lygis gali būti pasiektas stengiantis mažinti programinės įrangos sudėtingumą

Perteklinė programinė įranga yra žymiai sudėtingesnė, taigi dėl klaidas toleruojančių kontrolerių atsiranda papildomos klaidos, kurios veikia sistemos patikimumą


Esminiai aspektai• Sistemos pasikliautinumas gali būti pasiektas

išvengiant klaidų ir jas toleruojant• Pertekliškumo ir įvairovės naudojimas yra

esminiai kuriant pasikliautinas sistemas.• Kai kurios programavimo kalbų konstrukcijos,

tokios kaip goto, rekursija ir rodyklės, yra neatsparios loginėms klaidoms

• Griežti duomenų tipai leidžia aptikti klaidas kompiliavimo metu


Esminiai aspektai• Klaidų toleravimo architektūra priklauso nuo

trigubo modulinio perteklingumo (triple-modular redundancy - TMR)

• N-versijų programavimas yra naudojamas projektuojant klaidų toleravimą programinės įrangos architektūroje

• Projektavimo įvairumas - būtina sąlyga, naudojant programinės įrangos pertekliškumą


Esminiai aspektai• Kritinių sistemų kūrimas Esminiai aspektai

( Pasikliautinumas, pertekliškumas, kalbos konstrukcijos, duomenų tipai, klaidų toleravimo architektūra, N- versijų programavimas, projektavimo įvairumas)


Klausimas 9.1• Kaip pasiekiamas sistemų pasikliautinumas?


Klausimas 9.2• Kokia klaidų toleravimo architektūra?


Klausimas 9.3• Kodėl reikalinga programavimo įvairovė?


Klausimas 9.4• Kas tai yra gynybinis programavimas?


Klausimas 9.5• Požiūris į pertekliškumo ir pasikliautinumo

santykį?

Documents

Kritinių sistemų kūrimas