Niezawodnosc i odpornosc na b ledy systemow

informatycznych

Witold PaluszynskiKatedra Cybernetyki i Robotyki

Wydzia l Elektroniki, Politechnika Wroc lawskahttp://www.kcir.pwr.edu.pl/~witold/

2011–2017Ten utwor jest dostepny na licencjiCreative Commons Uznanie autorstwa-Na tych samych warunkach 3.0 Unported

Utwor udostepniany na licencji Creative Commons: uznanie autorstwa, na tychsamych warunkach. Udziela sie zezwolenia do kopiowania, rozpowszechniania i/lubmodyfikacji tresci utworu zgodnie z zasadami w/w licencji opublikowanej przezCreative Commons. Licencja wymaga podania oryginalnego autora utworu,a dystrybucja materia low pochodnych moze odbywac sie tylko na tych samychwarunkach (nie mozna zastrzec, w jakikolwiek sposob ograniczyc, ani rozszerzycpraw do nich).

Obs luga b ledow

Jesli”zwyk ly”program napotka b lad, ktorego nie potrafi rozwiazac albo naprawic,

to typowym i normalnie stosowanym zachowaniem programu jest zakonczeniepracy, z mozliwie starannym i dok ladnym poinformowaniem uzytkownika (jesli takiistnieje) o powstaniu b ledu i jego okolicznosciach.

Systemy czasu rzeczywistego i systemy wbudowane maja inne wymagania i innepodejscie do traktowania i obs lugi b ledow, i powyzsze podejscie jest zwykle nie doprzyjecia. Na przyk lad, system sterujacy procesem przemys lowym, po napotkaniub ledu fatalnego, nie moze po prostu zatrzymac procesu, poniewaz mog loby to byckosztowne i/lub niebezpieczne. Zamiast tego, powinien przejsc do trybupodtrzymania minimalnej funkcjonalnosci, unikajac ca lkowitej awarii.

Niezawodnosc i odpornosc na b ledy systemow informatycznych 3

Niezawodnosc i odpornosc na b ledy

Systemy czasu rzeczywistego i systemy wbudowane maja rowniez specjalnewymagania dotyczace niezawodnosci. W celu ich osiagniecia stosuje sie ca ly zestawtechnik:

• minimalizm w specyfikacji wymagan i projektowaniu systemow,

• specjalne metody projektowania i budowy oprogramowania, m.in. uzywaniebezpiecznych jezykow programowania, odpowiednie szkolenie programistow, itp.,

• weryfikacja i testowanie,

• odpornosc na b ledy,

• efektywne usuwanie skutkow awarii.

Niezawodnosc i odpornosc na b ledy systemow informatycznych 4

Metryki z lozonosci oprogramowania

Niezawodnosc systemu oprogramowania jest zwiazana z jego z lozonoscia. Bardzoz lozone oprogramowanie jest kosztowne do wytworzenia, i trudno zapewnic jegoniezawodnosc. Stosuje sie rozne miary z lozonosci systemow oprogramowania, zwanemetrykami.

W czasie projektowania nowego systemu oszacowanie z lozonosci pomagaw przewidywaniu kosztow, niezbednego nak ladu czasu, oraz innych potrzebnychzasobow.

Po zakonczeniu budowy systemu obliczenie jego metryk i innych charakterystykpomaga w zbudowaniu bazy doswiadczen dla przysz lych projektow.

Stosowane metryki z lozonosci oprogramowania:

• Liczba wierszy programu (Lines of Code, KLOC), czesto liczona z pominieciemkomentarzy, plikow nag lowkowych, itp. W oczywisty sposob metryka ta niebierze pod uwage z lozonosci samego programu. Ponadto, czesto trudno obliczycja dla dopiero projektowanego systemu.

Niezawodnosc i odpornosc na b ledy systemow informatycznych — metryki z lozonosci oprogramowania 5

• Z lozonosc cyklomatyczna (cyclomatic complexity) C, obliczona na podstawieschematu blokowego programu (flow graph), gdzie e — liczba krawedzi grafu,a n — liczba wierzcho lkow:

C = e− n+ 2

Ilustracja z lozonosci cyklomatycznej dla prostych fragmentow programow sanastepujace schematy blokowe:

Obliczenia z lozonosci cyklomatycznej mozna dokonac automatycznie, w trakciekompilacji programu, lub przez analize kodu zrod lowego.

Niezawodnosc i odpornosc na b ledy systemow informatycznych — metryki z lozonosci oprogramowania 6

• Punkty funkcyjne (Function Points) jest innego rodzaju metryka, probujacaoszacowac interakcje pomiedzy modu lami projektowanej aplikacji, opartao pewne jej parametry zewnetrzne. Wielka jej zaleta jest mozliwosc obliczenia naetapie projektowania, gdy zaden kod nie jest jeszcze napisany. Wykorzystujetakie parametry:

– liczba zrode l wejsciowych (I)– liczba wyjsc (O)– liczba dialogow z uzytkownikiem (Q)– liczba uzywanych plikow (F )– liczba zewnetrznych interfejsow (X)

FP = 4I + 4O + 5Q+ 10F + 7X

Istnieja bardziej rozbudowane wzory na FP , biorace pod uwage dodatkoweaspekty projektowanej aplikacji.

Niezawodnosc i odpornosc na b ledy systemow informatycznych — metryki z lozonosci oprogramowania 7

• Poprzednie metryki nie uwzglednia ly specyfiki programow obiektowych. Definiujesie metryki podobne do FP , uwzgledniajace w przypadku aplikacji obiektowychtakie parametry jak:

– wazona liczba metod na klase– g lebokosc drzewa dziedziczenia– liczba potomkow w drzewie dziedziczenia– zwiazki miedzy klasami– brak spojnosci miedzy metodami

Nalezy podkreslic, ze stosowanie metryk ma ograniczone zastosowanie. Naprzyk lad, przyk ladanie nadmiernej wagi do metryki KLOC moze doprowadzic dosytuacji, w ktorej programisci, lub ca la firma realizujaca projekt, beda tworzylioprogramowanie o zawyzonej KLOC, w celu wykazania sie i podniesienia rangiswojego produktu, z oczywista szkoda dla projektu.

Niezawodnosc i odpornosc na b ledy systemow informatycznych — metryki z lozonosci oprogramowania 8

Terminologia niezawodnosci

Defektem (fault) nazywamy wade programu, b ledny fragment kodu, np. braksprawdzenia wielkosci bufora przed wczytaniem do niego danych nieznanejwielkosci. Istnienie defektu w programie nie oznacza, ze b ledny kod zostaniekiedykolwiek wykonany, gdy bedzie wykonany to czy nastapi sytuacja b ledna (np.dane przekrocza rozmiar bufora), a gdy wystapi, to czy spowoduje to jakiekolwieknegatywne konsekwencje.

B ledem (error) nazywamy sytuacje, gdy program znajdzie sie w stanie roznym nizstan pozadany i poprawny. Np. przypadek, odwo lanie sie programu do adresu spozadozwolonego zakresu jest b ledem. B lad taki moze byc jednak zauwazony przezsystem, ktory moze wys lac programowi sygna l. Jesli program jest wyposazonyw handler obs lugujacy sygna l danego typu, to program ma szanse poprawnegozachowania sie w przypadku takiego b ledu, i podjecia w lasciwych dzia lan.

Awaria (failure) nazywamy sytuacje, kiedy program nie jest w stanie realizowacswojej funkcji wskutek wystapienia b ledu.

Niezawodnoscia bedziemy nazywac zdolnosc programu takiego radzenia sobiez defektami, a takze b ledami, ktore nie dopuszcza do wystapienia awarii.

Niezawodnosc i odpornosc na b ledy systemow informatycznych — terminologia niezawodnosci 9

B ledy

B ledy mozna podzielic na dwie istotne kategorie:

• b ledy powtarzalne — takie, dla ktorych znana jest przynajmniej jedna sciezkaprowadzaca do ich wystapienia,

• b ledy ulotne — (transient error) to takie, dla ktorego nie mozna precyzyjnieokreslic warunkow jego wystapienia, a zatem nie ma mozliwosci wywo lania gow prosty i powtarzalny sposob.

Znaczenie powyzszego rozroznienia b ledow jest takie, ze procedury zwiazanez wykrywaniem b ledow sa inne dla tych kategorii.

Niezawodnosc i odpornosc na b ledy systemow informatycznych — terminologia niezawodnosci 10

Zapobieganie defektom

Zapobieganie defektom (fault prevention) sprowadza sie do dwoch grup procedur:

• unikanie defektow (fault avoidance)

– rygorystyczna i/lub formalna specyfikacja wymagan– zastosowanie sprawdzonych metod projektowania– uzycie jezykow z mechanizmami wspierajacymi abstrakcje, weryfikacje, itp.– uzycie narzedzi inzynierii oprogramowania

• usuwanie defektow (fault removal)

– weryfikacja– walidacja– testowanie

Niezawodnosc i odpornosc na b ledy systemow informatycznych — terminologia niezawodnosci 11

Niezawodnosc i odpornosc na b ledy systemow informatycznych — terminologia niezawodnosci 12

Weryfikacja, walidacja, i testowanie

Weryfikacja jest procesem realizowanym na wielu etapach cyklu rozwojuoprogramowania, w celu potwierdzenia poprawnosci i zgodnosci ze specyfikacjadanego modu lu, i ca lego systemu. Do weryfikacji mozna wykorzystac wiele narzedzi,w tym narzedzi analizy formalnej.

Walidacja jest procesem analizy ukonczonego produktu, lub prototypu, dlastwierdzenia czy jest zgodny z wszystkimi wymaganiami, w tym rowniez czyformalna specyfikacja jest zgodna z intencja i oczekiwaniami uzytkownika, oraz czyuruchomiony w srodowisku produkcyjnym program realizuje swoje funkcje.

Podstawowym narzedziem walidacji jest testowanie.

Niezawodnosc i odpornosc na b ledy systemow informatycznych — weryfikacja, walidacja, i testowanie 13

Testowanie

Testowanie jest procesem powtarzalnego uruchamiania programu z okreslonymidanymi wejsciowymi, w celu stwierdzenia, czy program produkuje w lasciwe sygna lywyjsciowe.

Jakkolwiek w trakcie testowania ujawniaja sie defekty i b ledy, ktore powinnynastepnie byc korygowane, wykrywanie i poprawianie b ledow nie jest jedynym celemtestowania. Ogolnie, testowanie nie jest w stanie ani wykryc wszystkich b ledow, anipotwierdzic ich braku. Na odwrot, za pomoca testowania mozna jedynie wykrywacistniejace b ledy. Natomiast dodatkowa rola testowania jest wytworzenie zaufania doprogramu, jesli zachowuje sie on poprawnie w dobrze zaprojektowanych,wszechstronnych testach.

Niezawodnosc i odpornosc na b ledy systemow informatycznych — weryfikacja, walidacja, i testowanie 14

Testowanie oprogramowaniaTestowanie moze przeanalizowac jedynie ma la czesc ca lej przestrzeni mozliwychdanych wejsciowych. Powinno ono byc zatem tak przeprowadzone, aby jego wynikiw przekonujacy sposob potwierdzi ly hipoteze, ze system bedzie dzia la l poprawniedla wszystkich danych. Metody wyboru danych wejsciowych:

• wybor losowy,• pokrycie wymagan — dla kazdego z wymagan zestawy danych potwierdzajace

spe lnienie danego wymagania,• testowanie white-box — realizowane jest pokrycie wed lug jakiegos kryterium

wynikajacego z analizy programu, np. przejscie wszystkich rozga lezien logicznychw programie,

• wybor oparty na modelu — dane sa generowane z modelu systemu pracujacegow po laczeniu z modelem obiektu fizycznego,

• profil operacyjny — baza do wyboru danych testowych jest profil operacyjny,• szczytowe obciazenie — generowane jest ekstremalne obciazenie systemu,

i w takich warunkach sprawdzane spe lnienie wymagan czasowych,• przypadek najgorszego czasu wykonania (WCET) — dane generowane na

podstawie analizy kodu w kierunku WCET,• mechanizmy tolerancji defektow — testowanie z zastosowaniem

”wstrzykiwania

defektow”,• systemy cykliczne — testowanie w zakresie jednego pe lnego cyklu.

Niezawodnosc i odpornosc na b ledy systemow informatycznych — weryfikacja, walidacja, i testowanie 15

Testowanie sprzetu

• testowanie CPU

• testowanie pamieci ROM

• testowanie pamieci RAM

• testowanie innych urzadzen

Niezawodnosc i odpornosc na b ledy systemow informatycznych — weryfikacja, walidacja, i testowanie 16

Odpornosc na b ledy

Podstawa zbudowania odpornosci systemu na b ledy (software fault tolerance) jestsformu lowanie hipotezy defektow okreslajacej jakie rodzaje defektow maja byctolerowane przez system. Hipoteza dzieli przestrzen stanow systemu na trzy regiony:

Dodatkowo: strategia NGU (Never Give Up — Nigdy Nie Rezygnuj).

Niezawodnosc i odpornosc na b ledy systemow informatycznych — odpornosc na b ledy 17

Redundancja

Redundancja (nadmiarowosc) jest jedna z g lownych technik budowaniaodpornosci na b ledy, zarowno w sprzecie jak i oprogramowaniu. W oczywistysposob, poniewaz prowadzi ona do budowy bardziej z lozonych systemow, mozesama w sobie wprowadzac ryzyko dalszych defektow i zwiazanych z nimi awarii.

Redundancja statyczna (maskujaca) jest wbudowana wewnatrz systemu, ktoryusi luje dzieki niej utrzymac poprawne dzia lanie maskujac wystepujace b ledy. Jednaz podstawowych technik jest TMR (Triple Modular Redundancy), polegajaca nazastosowaniu trzech identycznych elementow, i uk ladu g losowania, ktoryporownuje sygna ly na wyjsciach wszystkich elementow, i jesli jeden rozni sie oddwoch pozosta lych to na wyjscie uk ladu kierowany jest sygna l wyjsciowy wybranywiekszosciowo. TMR ma g lownie zastosowanie do uodpornianie na b ledy sprzetu.

Redundancja dynamiczna polega na wbudowaniu w system elementuoceniajacego, czy nie wystepuja b ledy. W przypadku wykrycia b ledu, uk ladsygnalizuje to, pozostawiajac jednak elementom zewnetrznym podjecieodpowiednich dzia lan. Redundancja dynamiczna jest zatem metoda wykrywaniab ledow. Przyk ladami moga byc bity parzystosci pamieci, albo sumy kontrolnew pakietach komunikacji.

Niezawodnosc i odpornosc na b ledy systemow informatycznych — odpornosc na b ledy 18

Programowanie N-wersji

Zastosowanie redundancji typu TMR opiera sie na za lozeniu, ze b lad powstaniewewnatrz jednego z uk ladow, i bedzie to b lad przypadkowy, albo wynikajacy zestarzenia sie sprzetu. Poniewaz systemy programowe nie starzeja sie, a b ledyprzypadkowe nie sa najwazniejszymi b ledami, na ktore system powinien bycodporny, zatem podejscie typu TMR ma ograniczone zastosowanie do systemowoprogramowania.

Zamiast tego, budowanie odpornosci koncentruje sie na mozliwych b ledachprogramowych. Metoda zwana programowaniem N-wersji (N-versionprogramming) polega na stworzeniu N funkcjonalnie rownowaznych programowodpowiadajacych jednej specyfikacji. Programy powinny byc budowane przez Nroznych programistow (lub grup), bez komunikowania sie miedzy soba. Programynastepnie wykonywane sa jednoczesnie w systemie, i dodatkowy proces driveraporownuje uzyskane wyniki i wybiera jeden metoda g losowania.

Skutecznosc tej metody opiera sie na za lozeniu, ze programy stworzone niezaleznie,maja rozne defekty, i beda powodowa ly b ledy niezaleznie od siebie. To za lozeniemoze byc nies luszne, jesli np. programy zosta ly napisane w tym samym jezykuprogramowania, i skompilowane tym samym kompilatorem.

Niezawodnosc i odpornosc na b ledy systemow informatycznych — odpornosc na b ledy 19

Dublowanie procesow

Technika znacznie prostsza niz programowanie N-wersji jest dublowanieprocesow. Ma ona zastosowanie do uodporniania systemu na b ledy ulotne.

Metoda polega na tworzeniu nadmiarowego podprocesu do wykonywania obliczen,a w przypadku gdyby napotka l on na jakis b lad, zamyka sie on zwracajacodpowiedni kod b ledu. Proces nadzorujacy stwierdza wystapienie b ledu, i tworzyidentyczny proces do ponownego wykonania tych samych obliczen.

Niezawodnosc i odpornosc na b ledy systemow informatycznych — odpornosc na b ledy 20

Dublowanie procesow moze byc stosowane wielokrotnie na roznych poziomach. Naprzyk lad procedura moze najpierw inicjalizowac srodowisko obliczen, pozyskiwacdane, itp., a dopiero potem inicjowac zasadnicze obliczenia. Zarowno pierwsza fazajak i druga moga podlegac oddzielnemu dublowaniu. W oczywisty sposob,dublowanie drugiej fazy jest mniej uciazliwe i nie powoduje konsekwencjiwykraczajacej poza program.

Zastosowanie tego podejscia jest szczegolnie latwe i atrakcyjne w systemachUnikso-podobnych, wykorzystujacych model tworzenia procesu przez klonowaniefunkcja fork.

Niezawodnosc i odpornosc na b ledy systemow informatycznych — odpornosc na b ledy 21

Punkty kontrolne

Metoda polega ona na tworzeniu w programie punktow bezpiecznego wycofania sie.Jezeli program w trakcie pracy sam wykryje b lad, to znaczy jakis niepoprawny stan,to najlepiej by loby cofnac sie o kilka krokow, kiedy stan by l jeszcze poprawny,i powtorzyc ma la porcje obliczen.

Aby to by lo mozliwe, nalezy w trakcie pracy okresowo, po zweryfikowaniu, ze stanprogramu jest poprawny, zapamietac go w sposob umozliwiajacy cofniecieprogramu do tego stanu. W ten sposob program tworzy punkt kontrolny. Powykryciu b ledu, program cofa sie do ostatniego takiego punktu, i wznawiaobliczenia tak jakby nic sie nie sta lo. Za lozeniem tej metody jest, ze ponownewykonanie pewnej fazy obliczen da tym razem inne wyniki. Za lozenie jest poprawnejesli b lad by l wywo lany czynnikami zewnetrznymi, albo jakas kombinacjamikrostanow programu, ktora nie zostanie powtorzona.

Niezawodnosc i odpornosc na b ledy systemow informatycznych — odpornosc na b ledy 22

Bloki wznawiania (recovery blocks)

Metoda blokow wznawiania wykorzystuje zwyk le bloki programowe uzupe lnioneo punkt wznawiania umieszczony na poczatku bloku, i test akceptowalnoscina koncu. Test jest wykonywany dla stwierdzenia czy system znajduje siew akceptowalnym stanie po wykonaniu bloku. Jesli nie, to wykonanie programuwraca do stanu na wejsciu do bloku.

Po wznowieniu obliczen, program powinien wykorzystac alternatywny modu lobliczeniowy. (Jesli obliczenia zostana wznowione z uzyciem tego samego modu lu,to ta metoda mozna sie zabezpieczyc jedynie przed b ledami ulotnymi.) Gdybyobliczenia wszystkich alternatywnych modu low zawiod ly, to sterowanie wraca domodu lu nadrzednego, ktory tez moze miec swoj blok wznawiania.

Metoda blokow wznawiania jest popularna technika, jednak jej zastosowaniew systemach czasu rzeczywistego jest ograniczone do przypadkow, w ktorychograniczenia czasowe pozwalaja na ponawianie obliczen, i wynik uzyskany pododatkowym nak ladzie obliczen jest nadal przydatny.

Zastosowanie tego podejscia w systemach Unikso-podobnych, wykorzystuje na ogo lfunkcje setjmp i longjmp do zachowywania stanu i wznawiania obliczen.

Niezawodnosc i odpornosc na b ledy systemow informatycznych — odpornosc na b ledy 23

Odm ladzanie

Metoda odm ladzania procesow opiera sie na za lozeniu, ze stan poczatkowy pouruchomieniu jest zawsze najlepiej przetestowany, i przez jakis czas po starciesystem pracuje bezawaryjnie.

Metoda jest ograniczona przez tzw. stan twardy systemu, to jest stan poinicjalizacji, komunikacji z urzadzeniami zewnetrznymi, itp. Ten stan zwykle niepowinien byc utracony w procesie odm ladzania. Jednak idea odm ladzania polega naporzuceniu poprzedniego stanu, i zainicjowaniu go od nowa!!

Niezawodnosc i odpornosc na b ledy systemow informatycznych — odpornosc na b ledy 24

Mikro restarty

Restart systemu moze byc srodkiem zapobiegania b ledom, albo metodaprzywrocenia systemu do stanu poprawnego. O ile jednak restart ca lego systemuczesto powoduje zaburzenie lub utrudnienie w pracy, to metoda moze byc podzia lsystemu na szereg mniejszych elementow, ktore mozna restartowac niezaleznie odinnych.

Zauwazmy, ze w niektorych systemach, jak Windows, po operacjach takich jakinstalacja lub reinstalacja jakiegos programu wymagany jest restart ca lego systemu.Wynika to z faktu, ze bezposrednio po starcie system konfiguruje sobie ca ledostepne oprogramowanie. Gdyby te warstwe konfiguracji oprogramowania wydzielicjako osobny podsystem, ktory mog lby byc restartowany samodzielnie, nie by lobykoniecznosci restartu ca lego systemu. Metoda ta jest szeroko stosowana w innychsystemach operacyjnych.

Niezawodnosc i odpornosc na b ledy systemow informatycznych — odpornosc na b ledy 25

Watchdog

W systemach czasu rzeczywistego procedura restartu powystapieniu i wykryciu awarii jest czesto zautomatyzowanai rutynowo implementowana. Jedna ze stosowanych metodjest tzw. watchdog, czyli system monitorujacy pracesystemu, i wykonujacy fizyczny restart po zauwazeniunieprawid lowosci.

Watchdog moze (powinien) byc zrealizowany sprzetowoi niezalezny od reszty systemu, co daje gwarancje jegopoprawnej pracy nawet jesli awaria systemu wy lacza z akcjiinne jego mechanizmy odpornosciowe.

Po uruchomieniu watchdog cyklicznie uruchamia timer nazaprogramowany odcinek czasu (np. 100 milisekund), poktorym inicjuje restart systemu, o ile nie zostanie zresetowanyzaprogramowanym kodem wpisanym na wejscie. Restartsystemu nastepuje rowniez w przypadku zaniku zasilaniawatchdoga.

Niezawodnosc i odpornosc na b ledy systemow informatycznych — odpornosc na b ledy 26

Poprawianie stanu

Poprawianie stanu polega na podjeciu dzia lan doraznych, w przypadku wykrycianieprawid lowosci. Jednak zamiast poszukiwania jej zrode l, i podjecia probyradykalnej naprawy sytuacji, likwidowane sa tylko objawy.

Jest to wiec podobne do objawowego leczenia choroby. Zamiast podawacantybiotyk, podajemy lekarstwo zbijajace goraczke. Jak wiemy, takie leczeniestosuje sie, i jest to s luszna metoda, jesli nic innego w danej chwili nie moznazrobic, a poprawienie stanu moze spowodowac niedopuszczenie do natychmiastowejawarii, i dalsze dzia lanie systemu, przynajmniej przez jakis czas.

Niezawodnosc i odpornosc na b ledy systemow informatycznych — odpornosc na b ledy 27