Arto Salminen,

11. Luento: Vikasietoisuus Arto Salminen, arto.salminen@tut.fi

Agenda Vikasietoisuuden käsitteistöä Vikasietoisuuden saavuttaminen Ohjelmisto- ja laitteistovioista Vika-analyysi Esimerkkejä Vikasietoisuuden luokittelua Käynnistys ja uudelleenkäynnistys Ohjelmistotyö ja ylläpito suorituksen aikana Yhteenveto

Käsitteistö ei vakiintunut kaikilta osin Vika (fault): Matalimman tason poikkeuksellinen toiminta Virhe/virhetila (error): Vian seurauksena aiheutuva järjestelmän poikkeuksellinen tila Virhetoiminto (failure): Järjestelmän väärä toiminta virhetilanteessa Entä bug ja defect?

Turvallisuus- ja elävyysominaisuudet Turvallisuus (safety): Järjestelmä ei tee mitään sellaista mitä se ei saisi tehdä Elävyys (liveness ~ availability): Laite tekee jotakin Alpern and Schneider (Inf. Proc. Letters, 1985) "Any specification can be expressed as the conjunction of a safety property and a liveness property."

Mistä viat aiheutuvat? Virheet speksissä Virheet toteutuksessa Ulkoiset tekijät Laitteisto HUOM! Vikaisietoisuus määritellään jotain tiettyä ominaisuutta kohti

Ei vikasietoisuutta Toisin sanoen kyseistä tapahtumaa ei osata odottaa Pillastuminen Täydellinen jumiutuminen (Onnekas sattuma) Sekä elävyys että turvallisuus rikkoutuvat

Ei-peittävä vikasietoisuus Jotain edelleen tapahtuu, mutta tulokset eivät välttämättä ole luotettavia Ei kovin houkutteleva vaihtoehto; yhdistettynä itsestabiloituvuuden kanssa kuitenkin mahdollinen Turvallisuus rikkoutuu, elävyys säilyy Myös itsestabiloituvuuden kanssa turvallisuusominaisuudet ovat hetken rikki

Vikaturvallisuus Järjestelmä lopettaa toimintansa kun tulee ongelmia Siis: Mitään pahaa ei tapahdu, mutta ei välttämättä mitään hyvääkään Turvallisuus säilyy, elävyys rikkoutuu Yleisin vikasietoisuuden muoto (varmaankin siksi että peittävästi vikasietoinen järjestelmä on niin paljon vaikeampi tehdä)

Peittävä vikasietoisuus Virhetilassa käyntiä ei huomata lainkaan Käytännössä tietysti vaaditaan diagnostiikka- ja toipumisrutiineja, mutta nämä on kätketty normaalitoimintaan niin, ettei niitä huomata Sekä turvallisuus että elävyys säilyvät

Vikasietoisuuden eri muodot: Summary Turvallisuus säilyy Elävyys säilyy Peittävä vikasietoisuus Elävyys ei säily Vikaturvallinen Turvallisuus ei säily Ei-peittävä vikasietoisuus Ei vikasietoisuutta

Vikasietoisuuden eri muodot: Summary Vikasietoisuus Attributes Availability Safety Reliability Means Tolerance, prevention, removal, forecasting Impairments Faults, errors, failures

Vikasietoisuuden saavuttaminen Välttämätön ehto on varautua vikaan; geneeristä vikasietoisuusmoduulia ei ole! Tapoja useita Datan redundanssi (kaikkea tietoa ei tarvita suorituksessa); erilaiset pariteettijärjestelmät, tarkistussummat jne. Ohjelmakoodin redundanssi (erilaiset vikaantumistestit); tyypillisesti koodissa haaroja jotka ovat ylimääräisiä, defensiivinen ohjelmointi yleisenä käytäntönä

Vikojen havaitsemisesta Virhetarkastelut Tarkistussummat Assertiot Vahtikoira (watchdog)/pulssi (heartbeat) Joskus molemmat; toinen tarkkailee ohjelman suorituksessa oloa ja toinen laskennan etenemistä tms.

Ongelmia Jatkuva tarkistussummalaskenta vie aikaa Virhetarkastelut rikkovat helposti ohjelmalogiikan, kun yhtenään joudutaan tarkastelemaan tuliko virheitä Poikkeuskäsittely on kallista Esim. normaali paluu 1/10000 ajasta verrattuna paluuseen poikkeuskäsittelijän kautta

Try Catch vaikutus suorituskykyyn C:\>Main.exe without try/catch 250ms with try/catch 1332ms without try/catch 261ms with try/catch 1322ms C:\>java -classpath. Main without try/catch 80ms with try/catch 321ms without try/catch 70ms with try/catch 320ms Windows still uses longjmp... Similar hardware, Linux: int i = 0; public void foo() { ++i; } public void foo1() { foo(); } public void foo2() { try { foo(); } catch (RuntimeException re) { System.out.println("caught "+re); } } without try/catch 207ms with try/catch 227ms without try/catch 202ms with try/catch 209ms private static int LOOP_COUNT = 10000000;

Laitteistovioista Tyypillisesti transientti (toiminto ei onnistu yhdellä kertaa esim. ulkoisten häiriöiden takia mutta laitteessa ei kuitenkaan vikaa) Laitteisto voi sisältää logiikan tämän hoitamiselle Redundanssi vaatii laitteiden monistamista tai suunnittelua siten että yksittäisen signaalin virhe ei aiheuta virhettä Yleensä siis ylimääräistä laitteistoa! Ongelma: Jos 2 laitetta jotka ovat eri mieltä, kumpi oikeassa?

N+1- ja 2Nvaralaitteistomallit N+1: Varalaite on yleensä kylmä joten se pitää lämmittää ; vain 1 varalaite koko järjestelmälle 2N: Varalaite voi suoraan matkia päälaitetta; jokaisella laitteella oma kopionsa

Ohjelmistoviat Ohjelmiston sisäinen redundanssi Suunnitteluvirheisiin varautumista Vaatii täydellisyyteen saakka vietynä eri menetelmiin perustuvan toteutuksen Sitten äänestys oikeasta tuloksesta Defensiivinen ohjelmointi Kattava testaus Ajonaikainen diagnostiikka

Defensiivinen ohjelmointi Laatu yleensä: Lähtökohtainen pyrkimys korkeaan laatuun; ei tilaa ohjelmointivirheille Ohjelmakoodin luettavuus: Toiminta pystytään varmentamaan helpommin esimerkiksi katselmoinnein Oletusten vähyys: Minimoidaan oletukset, joiden varaan ohjelman toiminta rakentuu; esim. varmistetaan että ohjelma toimii kaikilla syötearvoilla HUOM: Defensiivinen ohjelmointi ei välttämättä pure täysin aikakäyttäytymiseen, jossa oletuksia joudutaan väistämättä tekemään!

Esimerkki int i = 0; while (1) { // Jotain ihmeellistä tekemistä i++ if (i == 10) break; // Ihmeellinen laskenta jatkuu }

Esimerkki int i = 0; while (1) { // Jotain ihmeellistä tekemistä i++ if (i >= 10) break; // Ihmeellinen laskenta jatkuu }

Esimerkki 2 int risky_programming(char *input){ // one more for the null character char str[1000+1]; //... strcpy(str, input); // copy input } //...

Esimerkki 2 int secure_programming(char *input){ char str[1000]; //... } // copy input without exceeding the length of // the destination strncpy(str, input, sizeof(str)); // if strlen(input) == sizeof(str) // then strncpy won't NUL terminate str[sizeof(str) - 1] = '\0'; //...

Vika-analyysi Vikasietoisuus vain etukäteen tunnistettuja vikoja kohtaan Analysoidaan mahdolliset viat Miten vikaan voidaan reagoida Miten viasta voidaan toipua

Esimerkki Sähkönsyöttö katoaa Akut kunnossa Aggrekaatti käynnistyy Aggrekaatti käynnistyy Siirrytään käsiajanottoon OK OK 30min jonka jälkeen käsiajanotto Pieni katkos, Ei ongelmia tuloksissa Tulokset viivästyvät mutta ne saadaan Tuloksia katoaa, kisoja tai sarjoja hylätään

Joitakin esimerkkijärjestelmiä Avaruussukkula 5 tietokonetta (laitteistoviat) 2 valmistajan ohjelmat (ohjelmistoviat) http://www1.nasa.gov/mission_pages/shuttle/flyout/flyfeature_shuttlecomputers.html Ariane 5 avaruusraketti Alun perin määrittelyvirhe; raja-arvon ylittyminen johti siihen että laitteiston uskottiin olevan vialla ja se sammutettiin Syöksyi lopulta turvallisesti mereen

Vikaturvallisuuden luokittelua Taso 1: Normaalin toiminnan vikatilanteet Normaalit pikkuviat, esim. muistitilan ylittyminen, levyn täyttyminen Laitteistoviat transientteja Diagnostiikkajärjestelmä; käynnistystestit ainakin muisteille Taso 2: Vikaturvallinen toipuminen Vaatii tyypillisesti uudelleenkäynnistämisen vian havaitsemisen ja siitä toipumisen jälkeen Käyttöjännitteen seuranta, vahtikoira tms.

Luokittelu jatkuu Taso 3: ei-peittävä itsestabiloituva vikasietoisuus Esimerkkitapaus vikaantuneen muistin hallinta: Virhe tunnistetaan pariteettikentästä, ja vikaantunut muisti poistetaan käytöstä. Korjaus pysyvä jos muistin vaihto vaikeaa, muuten laite voi ilmoittaa huoltotarpeesta Muita vastaavia tapauksia ovat esim. ohjausvirheet ja ympäristön yllättävä käytös. Taso 4: peittävä vikasietoisuus Tärkeimät laitteet (tai osa niistä) monistettu Ongelmatilanteessa varayksikkö olemassa ja valmis astumaan remmiin nopeasti Esim. RAID, tietoliikenneyhteyksien monistaminen

Luokittelu jatkuu edelleen Taso 5: Korjaus konetta sammuttamatta Vain pieni parannus edelliseen; myös lopullinen korjaus konetta sammuttamatta Taso 6: Kaikkien laitteiden varmistus Kaikki laitteet monistettu Esim. Suurehko puhelinkeskus (pienemmät tasoja 4 ja 5) Taso 7: Koneiden monistaminen Eli siis kuten 6 mutta joka yksikkö laskee oman tuloksen ja valittu tulos saadaan äänestämällä tms. Käytännössä harvinaisia

Käynnistys ja uudelleenkäynnistys Käynnistys on aina erikoistilanne Oheislaitteet eivät ole käynnissä -> Ohjauselektroniikka saattaa tulkita tiloja miten haluaa (kytkennöistä toki riippuen, hyvällä elektroniikkasuunnittelulla voidaan saada ihmeitä aikaan!) Ulkoisten liittymien tulee toimia turvallisesti; ei satunnaiskäyttäytymistä edes käynnistyksen aikana Yleissääntöä turvalliseen käynnistämiseen ilman laitteistotukea ei ole; ohjelmoija voi toki luoda lisää ongelmia väärillä alustusrutiineilla Ajossa olevan järjestelmän käynnistys (varsinkin esim. jotain aktiivisesti ohjaavan) on muutenkin harkittava huolellisesti vaikkei ohjelmoijien mielenkiinto ja ohjelmointityyli työläitä tarkistuksia suosisikaan

Ohjelmistotyö ohjelman suorituksen aikana Järjestelmä voi olla jatkuvasti käytössä Alasajo ei vaihtoehto, jos toimintaa ei saa keskeyttää Ainoa mahdollisuus toteuttaa ylläpitotoimenpiteen ajon aikana Ääritapauksisssa sekä ohjelmisto- että laitteistotuki tarpeen

Ohjelmiston muuntelu suorituksen aikana Yksinkertainen tapaus: Parametrein tapahtuva ohjaus Esim. joku diagnostiikkaa häiritsevä toiminto kytketään pois päältä diagnostiikan käytön ajaksi Paikko-ohjelmistot (patch) Joku muistialue varataan patcheille Uudelleenkäynnistys/initialisointi jolloin patchit ladataan käyttöön Joskus voidaan toteuttaa komponentti kerrallaan, jolloin saadaan aikaiseksi hienorakeisempi päivitettävyys Joskus koko ohjelmiston uudelleenlataus ja uudelleenkäynnistys DISCLAIMER: Lähtökohtaisesti mitä ilmeisimmin virheherkkää eikä missään nimessä suositeltava yleinen käytäntö

Laitteistotuesta Laitteisto voi olla rakennettu siten, että se sallii kahden ohjelmiston ajamisen rinnakkaisesti kahdella eri tietokoneella Tällöin ohjelmisto voidaan päivittää tietokoneeseen A, ja päivityksen + toiminnan varmentamisen aikana tietokone B hoitaa toimintaa Jos A vaikuttaa toimivan hyvin, myös B voidaan päivittää Yleensä huomioitu järjestelmätason vaatimuksissa Ongelma: Mitä jos vanhaa versiota ajava B vikaantuu kun A:ta ollaan päivittämässä?

Yhteenveto Vikasietoinen järjestelmä kykenee jatkamaan toimintaansa itsenäisesti myös silloin kun siinä on vikaa Vikaturvallisen järjestelmän suunnittelussa on huomioitu erikseen ettei vikaantumisesta ettei tule vaaraa Vikasietoisuus voi kohdistua vain vikoihin jotka on otettu huomioon osana suunnittelua Ohjelmistojen sisäisen vikasietoisuuden toteutuskeinoina Ohjelman toiminnan tarkkailu Defensiivinen ohjelmointi