Tarkvarasüsteemi ohutus

Allikas: Vikipeedia

Tarkvarasüsteemi ohutus on üks tarkvaratehnika haru. See üritab tõhustada tarkvarasüsteemide ohutust, sekkudes süsteemide, eelkõige niiöelda ohutus-kriitiliste(safety critical) süsteemide disainimisse, ehitusse, kasutusse ning hooldusesse. Eelkõige on siin tähelepanu all süsteemid, mis võivad otseselt vigastada või ohtu seada inimeste elud või kahjustada märgataval määral keskkonda. Nagu ala nimigi ütleb, on tegelikult ohutuse tagamiseks vaja selgeks teha seosed kogu süsteemi ulatuses, kuivõrd muudatusi füüsilisse maailmasse teevad lõpuks muud süsteemi osad, kui seda kõike juhtiv tarkvara ning neil võib esineda ka koosmõjusid. Arvutite ning mikrokontrollerite, mis on niiõelda ühekiibi arvutid, võidukäigust näeb igaüks, et kellegi poolt koostatud juhtprogrammid kontrollivad ja juhivad järjest rohkem asju meie ümber ning, et neile on usaldatud ka süsteemid, kus vigadega kaasnevad väga tõsised tagajärjed. Samas pole ohutuse pool tarkvara arenduses üldsegi mitte hästi arenenud. Ohutustehnika tegeleb põhiliselt süsteemi töö selle poolega, kui süsteemi tekib viga ning see ei tööta nii nagu eeldatud.

Tarkvarast vigadest põhjustatud õnnetusi[muuda | redigeeri lähteteksti]

Üks tuntuim õnnetustesari, mis oli põhjustanud põhiliselt vigadest tarkvaras, on Therac-25 juhtum. See oli kiiritusteraapia masin, mille kasutamisel 1985-1987 aastal sai vähemalt kuus inimest 100 korda võimsama radiotsiooni doosi kui ettenähtud ja kellest kolm surid selle tagajärjel. Masin opereeris kahel viisil, esiteks tegi madala võimsusega otse väljastatud elektronkiir teraapiat ning teiseks teraapiaks väljastas rõntgenkiiri. Need saadi kui suure võimusega väljastatud elekronkiirtele seati ette konverter, mis selle rõntgenkiirteks muutis, filter mis need suurele pinnale laiali suunas ning kamber mis suunas ning mõõtis röntgenkiirte tugevust. Õnnetus juhtus, kui operaator oli ekslikult valinud kõrgema väljundvõimsuse „x” klahviga, märganud seda ning sellele järgnevalt valinud „nool üles” ning „e” korrektse viisi jaoks ning vajutanud „enter”-it. Seejärel said patsiendid justkui suure elektrilöögi ning arvasid, et midagi läks valesti, operaatorid usaldasid liigselt masinat ning arvasid, et kõik on siiski korras. Antud juhul oli masin väljastanud selle suure võimsusega elektronkiire otse väiksele alale, sest väljundviis jäi muutmata, aga ka vahepealseid muutvaid seadmeid ei olnud kiirel ees. Järgnenud juurdlused leidsid : et tootja polnud lasknud koodi eraldi ülekontrollida ; oli taaskasutatud eelmise mudeli koodipõhja, millel olid sisemised riistvara blokeeringud, et kaks viisi segamini ei töötaks ; süsteem sai aru, et midagi on valesti, aga kuvas ainult teksti „viga” , millele järgnes number 1-st 64-ni, seda polnud kasutusmanuaalis mainitud, ning sai vajutada „p” nuppu, mis tühistas lihtsalt selle ning sai jätkata. Enamik tänapäeva meditsiini aparatuuri sisaldab arvutisüsteeme ning pea kõik nende tagasikutsumised või väljatulnud vead on just tarkvara vigade pärast. Välja on toodud, et põhjus seisneb selles, et kuigi osatähtsus süsteemi korrektses töötamises on võrdne riistvaraga, siis erinevalt masinaehitusest pole tarkvara arenduses väljatöötatud ning järjepidevas kasutamises tarkvara ohutust tagavaid meetodeid ega eeskirju. Tarkvaratööstus on viimase ajani seadnud põhiliselt esile ainult produktiivsuse ning keskmiselt jääb 1000 koodirea kohta sisse algselt 50 viga, 75% vigadest avastatakse testimise käigus, ülejäänud 25% jääb kasutajate avastada. Kvaliteetseks loetakse koodi, millel on 1 kuni 5 viga tuhande koodi rea kohta. Mikrolaine ahju juhtprogramm koosneb aga juba mõnesajast või tuhandest koodireast ning suuremad süsteemid nagu lennuki juhtimis süsteemid koosnevad mitmest sajast tuhandest või lausa miljonist koodireast. Kui tavaliselt teeb personaalarvuti kasutaja programmi vea järel lihtsalt restardi, teeb oma töö uuesti või laseb inimesel arvuti möödapaneku parandada, siis ohutus-kriitilistes süsteemides see võimalik pole ning veale järgneb tavaliselt õnnetus. Peamised ohutuskriitilised süsteemid on juba mainitud meditsiin, lennundus, muud liiklusvahendid nagu autod ja rongid, energeetika valdkond(kaasaarvatud tuumaenergia) ning relvad. Katastroofe on aga ka kaasnenud ka tavapärasemate tarkvaraprogrammide vigadest, näiteks üks naftaplatvorm(Sleipner A) varises paigaldamisel kokku, kuna ei arvuatud käsitsi üle modellerimisprogrammi tugevusarvutusi, milles esines viga ning raudbetoon alus ehitati liiga õhuke merepõhjas olevale rõhule vastapidamiseks. Näiteid juhtumistest, mis tarkvara vigadest oli põhjustatud:

  • Meditsiinis kasutatavad pumbad, mis peale nulli väärtuseks panemist ikka endistviisi edasi insuliini pumpasid;
  • Vereanalüsaator, millel oli kalibratsiooni võrrandis lahutamise asemel liitmine;
  • Patsiendile erinevaid gaase edastav venilaator, mille patsiendi lahtiühenduse alarm ei helisenud, samuti kui gaaside(näiteks hapniku) edastamine langes ilma et vastav alarm oleks tööle hakanud või seda kasvõi ekraanil näidatud.
  • Lahesõja ajal jooksis tarkvara vea tõttu õhukaitse patarei kokku ning iraagi rakett lendas ameeriklaste baasi, põhjustes suurima ühekordse kaotuse selles sõjas.
  • Ariane 5 kosmoseraketi esimene katsetus ebaõnnetus ning hävis, tekitades mitme miljardi kroonise kahju, kuna lennutee andmete konverteerimine tekitas vea, üritati liiga suurt 64 bitist ujukoma arvu mahutada 16 bitisesse signeeritud integraali.
  • Samasugune mitme miljardi kroonine kahju tekkis, kui Mars Climate Orbiter sisenes liiga madalale orbiidile navigeerimistarkvara vea tõttu, mis tekkis kuna alltöövõtja oli kasutanud inglise ühikuid ning kosmoselaev ootas meeter ühikuid. Siin oli viga ka selles, et jällegi ei oldud piisavalt süsteemi eelnevalt testitud ja kasutatud oli eelmise versiooni tarkvara.

Mida teha tarkvara süsteemide ohutuse tõstmiseks ?[muuda | redigeeri lähteteksti]

Põhiline on parandada programeerijal iseenda tööd ning olla teadlik, et programeerimisel tehakse tavaliselt palju vigu. Neid esineb ka suurte ning tähtsate süsteemide seas, mis mõnevõrra juba testitud võivad kellegi poolt olla. Inglismaa kaitseministeeriumi uuring näiteks selgitas välja, et isegi juba kasutusel olnud sõjaväe relvade ja masinate juhtsüsteemides, esines siiski ikka vigu, mis oleks suutnud kaks maksimaalset äärmust ära vahetada. Samuti tuleb arendajatel pidevalt endale meelde tuletada, kuivõrd katastrofaalsed võivad mõne juhtprogrammi vead olla ja vajalikul määral ka ohutusele tähelepanu pöörata, kuigi funktsionaalsus tundub lõpuks olevat see mida müüakse. Inglismaal on ka seadus nimega „Masinate ohutus direktiiv”, mis määrab, et firma direktor või osakonnajuht, kes on hooletusse jätnud ohutusetagamise masina disainil või ehitusel, mis põhjustab vigastusi, võidakse vastva õnnetuse põhjustamise eest kriminaalvastusele võtta. On küll mitmeid nii tegevusalade kui üldisi (IEEE STD 1228-1994 Software Safety Plans) tarkvara ohutust tagada püüdvaid tegevusjuhiseid, kuid on need enamuses ainult väga üldised meetodite kirjeldused. Tähtis on, et ohutus-kriitilistes süsteemides oleks ohtuse pool kohe algusest sisse disinitud ning ehitatud põhiosa, mitte eraldi lisatud funktsioon ning et selle täideviimist pidevalt jälgitaks ja juhitaks mõne eraldi kõrgemal positsioonil oleva isiku poolt. Samuti, et toodete funktsioneerimine oleks pidevalt ülevaadatud tellija poolt ning ka tema vastutavaks tehtud vigade tekkimise korral, sest klient teab võimalikke ohusituatsioone ja vigasid paremini. Siin on oluline ka korraliku tegelikkusele vastava dokumentatsiooni loomine arendusprotsessi käigus, et klient saaks õigesti asjadest aru. Therac-25-l loodi kah korraliku mahuga dokumentatsioon, kuid ülevaatamisel selgus, et see oli vaid nõ ilus jutt. Samuti pole hea kui mindakse kogu süsteemi koondamise teed, nagu antud kiiritusteraapia masinal ning kogu tavapärane mitmetahuline kontrollsüsteem on usaldatud vaid ühe arvuti hoolde. See toob kaasa oluliselt suurema riski, et kui mingis väikses osas tekib tõrge, siis kantakse see sealt kogu süsteemile üle. See rikub ohutus tehnika(safety engineering) põhimõteid, millega peaks kah ohutus-kriitiliste süsteemide tarkvara insener tuttav olema, kuid pahatihti see nii pole. Kõikides teistes inseneerteaduste harudes vaadatakse ja kontrollitakse kõik plaanid ning tööd eraldi veelkord üle suure kogemustepagasiga vanem-inseneri poolt, nii peaks see ka olema tarkvara arenduses. On olnud arutelusi ka selle üle, et kõik insenerid peavad olema läbinud oma ameti kutsekvalfikatsiooni eksamid, et äkki peaks see olema nii ka tarkvaratehnikutel, kes ennast insenerideks peavad.

Formaalsed meetodid[muuda | redigeeri lähteteksti]

Kui üldiselt on tarkvara ohutuse ala alles arengu algusfaasis ning pole väljatöötatud meetmeid, mis suudaks suure tõenäosusega ohutuse tagada, siis on siiski üks laiemalt levinud ja tunnustust leidnud tehnikate kogum nimega formaalsed meetodid. See sisaldab meetodeid nagu B-method, Lustre, Abstract State Macine jne. Need kõik on mõnevõrra varieeruvad oma käsitlusviisidelt ja lõppeesmärkide osas. Ühine on neil see, et juba programmi spesifikatioon kirjutatakse üles matemaatika ning loogika tehteid kasutades ning üritatakse selle põhjal siis analüüsides väljaselgitada kõikvõimalikud programmi käitumisviisid, programeerimisel lähtutakse ja kasutatakse spetsifikatiooni osasid ning lõpus võrreldakse programmi ning spetsifikatsioonide põhjal koostatud lõpptulemusi. Formaalsete meetodite kasutamine on äärmiselt kallis ning selle vastaste arvates ei anna vajalikku tulemust. Samas järjest enam nõutakse seda suuremate ohutus-kriitiliste süsteemide korral(näiteks lennunduses), sest see suudab parandada arusaamist programmi tööst, enam ei selgu programmi käitumine arendamise lõppjärgus testimise käigus ning ühtlasi sunnib kasutama lihtsamaid/arusaadavamaid osi.

Vaata ka[muuda | redigeeri lähteteksti]

Välislingid[muuda | redigeeri lähteteksti]