Systemy krytyczne i HAZOP -...

1

Zaawansowana inżynieria oprogramowania

Systemy krytyczne i HAZOP

Koncepcja wykładu:Slajdy/Lektor/Montaż:

Jerzy NawrockiŁukasz Olek

Szanowni Państwo!Kolejny wykład z kursu zaawansowanej inżynierii wymagań poświęcony jestsystemom krytycznym i metodzie HAZOP.

2


Systemy krytyczne i HAZOP (2)

Plan wykładów

Standardy serii ISO 9000Model dojrzałości CMMIZarządzanie przedsięwzięciami i PRINCE2, cz. IZarządzanie przedsięwzięciami i PRINCE2, cz. IIPersonal Software Process, cz. IPersonal Software Process, cz. IIMetodyki programowania: TSP i RUPPozyskiwanie i dokumentowanie wymagań (IEEE 830)Wymagania pozafunkcyjne i ISO 9126Zarządzanie ryzykiemSystemy krytyczne i HAZOPSzacowanie rozmiaru oprogramowaniaSzacowanie pracochłonności

Wykład ten pokaże zupełnie inne spojrzenie na wymagania systemuinformatycznego - spojrzenie z punktu widzenia systemów krytycznych.Zanim przejdziemy do szczegółów muszę wyjaśnić czym jest systemkrytyczny i czym różni się tworzenie takiego systemu od zwykłych systemówinformatycznych, jakie spotykamy na codzień.

3



Wprowadzenie

• System krytyczny?– system, którego awaria lub niewłaściwe

funkcjonowanie może spowodować:• stratę życia, lub poważny uszczerbek na zdrowiu• duże straty materialne• zanieczyszczenie środowiska

– life/safety-critical

źródło: Wikipedia(Safety Critical System)

Wg Wikipedii system krytyczny to system, którego awaria, lub niewłaściwefunkcjonowanie może być bardzo poważne w skutkach. Może powodowaćstratę życia użytkowników, lub uszczerbek na zdrowiu. Może powodowaćrównież duże straty materialne lub poważne zanieczyszczenie środowiska.Systemy takie można podzielić na krytyczne dla życia (life-critical system) lubbezpieczeństwa (safety-critical system). Mówi się, że system krytyczny dlażycia dopuszcza stratę 1 życia ludzkiego w ciągu miliarda godzin, czyli ponad11000 lat (110 wieków).Jak widać poprzeczka dla tego typu systemów podniesiona jest bardzowysoko. Czy jesteśmy w stanie wytworzyć system o takiej niezawodności woparciu o dotychczas poznane sposoby wytwarzania oprogramowania? Amoże potrzebne nam jest inne podejście do wytwarzania takich systemów?Ten wykład powinien odpowiedzieć Państwu na powyższe pytania.Jeszcze do niedawna (kilkanaście lat temu) większość systemów krytycznychbyła systemami jedynie sprzętowymi. Ostatnio jednak prawie każdy systemkrytyczny zawiera w sobie oprogramowanie, dlatego też takie systemy leżą wzainteresowaniu inżynierii oprogramowania.Na początku przyjrzyjmy się przykładom systemów krytycznych, aby zobaczyćich różnorodność.

4



Wprowadzenie - przykłady systemów krytycznych

• Sztucznepłuco-serce:

źródło: Wikipedia

Sztuczne płuco-serce, to urządzenie wykorzystywane podczasskomplikowanych operacji na sercu. Jego rolą jest przejęcie czynności serca ipłuc, tak aby serce można było na chwilę wyłączyć, gdyż operowanie nabijącym sercu jest bardzo skomplikowane. Przy normalnej temperaturze ciałamózg umiera po 3-4 minutach od ustania krążenia, więc niezawodnośćtakiego urządzenia jest sprawą krytyczną.

5




• Reaktornuklearne -systemysterowania


Zupełnie innego rodzaju systemami są reaktory nuklearne. Urządzenia teinicjują łańcuchową reakcję atomową, kontrolują i utrzymują ją na stałympoziomie. Reaktory są wykorzystywane np. w elektrowniach jądrowych.Reaktory to duże systemy złożone z paliwa, cieczy, osłon i wszelkichinstrumentów służących do monitorowania i kontrolowania jego pracy, jakrównież oprogramowania sterującego wszystkimi jego procesami.Po zapoczątkowaniu reakcji łańcuchowej wyzwala się ogromna ilość energii.Oprogramowanie reaktora musi w odpowiedni sposób sterować cieczą, któryprzepływa pomiędzy prętami z paliwem i chłodzi je. W przypadku awariisystemu chłodzenia reaktor może wybuchnąć, gdyż wyzwoli się zbyt dużailość energii.

6




• Poduszkapowietrzna


Kolejny przykład to poduszka powietrzna - system krytyczny, który musizadziałać niezawodnie w ciągu ułamka sekundy. Zbudowana jest ona zelastycznej membrany wypełnianej powietrzem, która w razie wypadkubłyskawicznie się nadmuchuje i chroni kierowcę (coraz częściej równieżpasażerów) przed uderzeniem głową o kierownicę. Zmniejsza również ryzykozranienia poprzez rozłożenie siły uderzenia równomiernie na ciało kierowcy.System ten jest jednak trochę bardziej skomplikowany. Nie wystarczyzapewnienie, że poduszka napełni się powietrzem w ciągu ułamka sekundy odzderzenia. Producenci muszą również zapewnić, że nie nastąpi samoczynneuruchomienie mechanizmu, gdyż wtedy można stracić życie właśnie w wynikuuderzenia poduszką. Jest to szczególnie istotne po wypadku, który niespowodował wystrzału poduszki. Strażacy, którzy ratują ofiary używajączasem narzędzi, które wprowadzają samochód w wibracje. Wibracje temogłyby wywołać wystrzał poduszki, co byłoby dla nich szczególnieniebezpieczne.

7



Wprowadzenie

• Paris Air Show1989:– zawiódł system

krytyczny wsamolocie

– na szczęście systemkrytyczny katapultyzadziałał

Czasem jednak systemy krytyczne zawodzą. Taka sytuacja miała miejsce w1989 roku w Paryżu podczas „Paris Air Show”. Zawiódł jeden z systemówkrytycznych samolotu. Pilot w ostatnim momencie zdążył się katapultować - naszczęście system katapulty zadziałał. Podczas tego wypadku nie było żadnychofiar śmiertelnych.

8



Plan wykładu

• Wprowadzenie• Dobre praktyki IW dla

systemów krytycznych• HAZOP:

– Wprowadzenie do metody– Słowa kluczowe– Procedura

Po tym krótkim wprowadzeniu do systemów krytycznych i przedstawieniu kilkuprzykładów przejdziemy do sposobu konstruowania wymagań - czyli dobrychpraktyk IW dla systemów krytycznych, a następnie metody HAZOP -usystematyzowanej metody przeglądu różnego rodzaju artefaktów.

9



Dobre praktyki inżynierii wymagań

432IW dla systemów krytycznych234Zarządzanie wymaganiami134Walidacja wymagań-33Modelowanie systemu-14Opisywanie wymagań125Analiza i negocjacja wym.166Zbieranie wymagań--8Dokument wymagań

Zaaw.9

Pośred.21

Podst.36Obszar

Systemy krytyczne są bardzo kosztowne, gdyż mają bardzo wygórowanewymagania pozafunkcjonalne. Ich proces analizy i implementacji powinien byćtak zaprojektowany, aby zapobiegać wprowadzaniu wszelkich błędów.Dodatkowo systemy te powinny być dokładnie sprawdzone po stworzeniu.Sommerville i Sawyer zdawali sobie sprawę z wagi systemów krytycznych iróżnic podczas analizowania wymagań takich systemów. W swojej książceuwzględnili szereg praktyk poświęconych systemom krytycznym w osobnymrozdziale.

10



Czy to jest opłacalne?

• Większość to praktyki pośrednie izaawansowane => kosztowne

• Czy to się opłaca?• paliwo dla elektrowni jądrowej (1000MW) kosztuje

120 mln zł/rok• 20 osób * 12 miesięcy * 10 tyś. zł = 2,4 mln zł

432IW dla systemów krytycznych

Jak widać, większość z nich jest typu pośredniego lub zaawansowanego, cooznacza, że są one bardzo kosztowne. Lecz to co byłoby zbyt kosztowne wprzypadku zwykłych systemów informacyjnych, okazuje się opłacalne wprzypadku systemów krytycznych.Dlaczego?Dla przykładu: paliwo dla jednej elektrowni jądrowej o mocy 1000MW, kosztujeokoło 10mln zł/miesiąc.Ile może kosztować dokładna analiza wymagań i weryfikacja.Załóżmy, że mamy zatrudnionych 20 osób, przez rok, każdy kosztuje 10 tyś.zł/miesiąc.Awaria takich systemów byłaby katastrofą, natomiast koszt dobrych praktykmoże się okazać znikomy w porównaniu do kosztów użytkowania systemu.

Wszystkie praktyki zaprezentowane w dalszej części dotyczą systemówkrytycznych, lecz również pozostałe praktyki mają zastosowanie w przypadkutego typu systemów.

11



IW dla systemów krytycznych

• Dobre praktyki -podstawowe:– Włącz do procesu walidacji

zewnętrznych ekspertów– Utwórz listę kontrolną dla

wymagań dotyczącychbezpieczeństwa

Basic

HAZOP

Pierwsze dwie praktyki są praktykamiprostymi. Dotyczą one procesuprzeglądu wymagań.-„Włącz do procesu walidacji zewnętrznych ekspertów” - osoby zaangażowanew projekt często mają już myślenie ograniczone. Osoby z zewnątrz wnosząświeże spojrzenie na walidację systemu, dzięki czemu są w stanie wykryćproblemy, których nie dostrzegłby nikt z zespołu. Dlatego w processprawdzania poprawności wymagań (walidacji) musimy starać się włączyćzewnętrznych ekspertów.

-„Utwórz listę kontrolną dla wymagańdotyczących bezpieczeństwa” - zalecastworzenie takiej wzorcowej listykontrolnej. Pytania na liście kontrolnejmuszą być tworzone zawsze w oparciu odoświadczenie i informacje na tematproblemów w poprzednich projektach.Jak może wyglądać taka lista?

12



Przykładowa lista kontrolna

• Czy system startuje w stanie bezpiecznym?• Czy ważne zmienne mają nadane wart. pocz?• Co się dzieje, gdy system jest odłączony?• Co się dzieje, gdy reakcja jest spóźniona?• Jaki wpływ mają nieoczekiwane wejścia?• Jak można wycofać komendę operatora?• Jak przechodzi się do stanu fail-safe?

Autorzy książki proponują m.in.następujące pytania:Czy system startuje w staniebezpiecznym?Czy ważne zmienne mają nadane wart.pocz?Co się dzieje, gdy system jestodłączony?Co się dzieje, gdy reakcja jestspóźniona?Jaki wpływ mają nieoczekiwane wejścia?Jak można wycofać komendęoperatora?Jak przechodzi się do stanu fail-safe?

Jaki jest koszt stworzenia takiej listykontrolnej? Jeżeli firma posiadadoświadczonych ekspertów, którzy braliudział w podobnych projektach, to kosztpowinien być stosunkowo niski. Możnają wtedy przygotować w ciągu kilkuosobo-dni. Jeżeli jednak takich ludzi niema, to trzeba zacząć z taką listąprzykładową, a w trakcie zdobywaniadoświadczenia dostosowywać listę doswoich potrzeb.Koszty zastosowania są również niskiew przypadku gdy listą posługujemy się wsposób nieformalny. Jeżeli natomiastchcemy przechowywać szczegółowezapisy, nt. tego, w jaki sposóbwymagania są sprawdzane z pytaniami zlisty, to koszty będą stosunkowo wyższe.Ogólny problem dotyczący wszelkich listkontrolnych jest taki, iż ludzie w takichsytuacjach mają tendencję do skupianiasię tylko na aspektach pokrytych przezlistę kontrolną, a zaniedbują inne, niewspomniane tam.Podsumowując: lista kontrolna stanowiwiedzę organizacji i jest wykorzystywanapodczas każdego przeglądu. Dlategowarto zainwestować trochę energii wprzygotowanie takiej listy.Dobrym sposobem przygotowaniakompleksowej listy kontrolnej jestmetoda HAZOP, która będzieprzedstawiona w dalszej części wykładu.

13




• Dobre praktyki - pośrednie:– Zidentyfikuj i zanalizuj

hazardy– Na podstawie analizy

hazardów formułujwymagania dot.bezpieczeństwa

– Konfrontuj wymaganiafunkcjonalne i operacyjne zwymaganiami dot.bezpieczeństwa

Int.

Kolejne praktyki - pośrednie. Pierwsza to „Zidentyfikuj i zanalizuj hazardy”.Hazardem jest zbiór warunków, który może prowadzić do niebezpiecznejsytuacji.Włączenie w proces powstawania systemów krytycznych osobnej czynnościmającej na celu zidentyfikowanie hazardów i ich potencjalnych skutków jestistotnym krokiem zapewnienia bezpieczeństwa systemu. Tylko dziękiznajomości hazardów jesteśmy w stanie napisać wymagania, które będą imzapobiegać, lub minimalizować skutki.Analiza hazardów to dobrze rozwinięta praktyka inżynierii systemów, któradotyczy nie tylko systemów krytycznych. Są różne metody analizy hazardów,np: analiza drzewa uszkodzeń (fault-tree analysis), analiza drzew zdarzeń(event-tree), przyczynowo-skutkowa (ang. cause-consequence), lub HAZOP.Analiza hazardów jest kosztowna, jednak zazwyczaj dużo mniej kosztowna niżwypadek, który mógłby mieć miejsce.

14







– Konfrontuj wymaganiafunkcjonalne i operacyjne zwymaganiami dot.bezpieczeństwa

Int.

Druga praktyka brzmi „Na podstawie analizy hazardów formułuj wymaganiadot. bezpieczeństwa”.Oznacza to, iż wykorzystując informację z identyfikacji hazardów i własnegodoświadczenia, należy stworzyć wymagania bezpieczeństwa dla każdegohazardu. Wymagania te mogą być w stylu: „System nie może…”. Jeżeli jakiśhazard jest trudny do wyeliminowania można wprowadzić wymaganiadotyczące tego, w jaki sposób zminimalizować skutek hazardu.W takim podejściu jest mniejsze prawdopodobieństwo przeoczenia ważnychwymagań bezpieczeństwa.

15



Cel formułowania wymagań

• System jest tak zaprojektowany, że:– zidentyfikowane hazardy nie wystąpią

podczas normalnego korzystania zsystemu

– hazardy zostaną wykryte, zanimspowodują wypadek i zostanie wykonanaakcja, która przeciwdziała wypadkowi

– jeżeli wystąpi wypadek, wtedyniebezpieczne konsekwencje wypadku sąminimalizowane

Celem formułowania wymagań systemu krytycznego jest takie jegozaprojektowanie, aby:-zidentyfikowane hazardy nie wystąpiły podczas normalnego korzystania zsystemu. Przykładowo: gilotyna do papieru może być tak zaprojektowana,żeby przycinała papier tylko wtedy gdy wszystkie przyciski bezpieczeństwabędą wciśnięte - zabezpiecza to przed włożeniem ręki pod ostrze.-w przypadku wykrycia hazardu, wykonywana jest akcja, która jest w staniezapobiec wypadkowi. Na przykład: gilotyna do papieru może zawieraćwymaganie, że powinien być dodatkowy system czujników, który zablokujesystem w przypadku wykrycia obiektu na linii ostrza.-w przypadku wystąpienia wypadku, system minimalizuje niebezpiecznekonsekwencje wypadku. Przykładowo: w systemie jakim jest samochód,sterowanie poduszką powietrzną może również odcinać zasilanie pompypaliwa w przypadku wypadku - w ten sposób minimalizuje sięniebezpieczeństwo pożaru.

16







– Konfrontuj wymaganiafunkcjonalne i operacyjnez wymaganiami dot.bezpieczeństwa

Int.

Ostatnia pośrednia praktyka: „Konfrontuj wymagania funkcjonalne ioperacyjne z wymaganiami dotyczącymi bezpieczeństwa”.Systematyczne sprawdzenie krzyżowe wymagań bezpieczeństwa zwymaganiami funkcjonalnymi i operacyjnymi pozwala ocenić, czy wymaganiemoże się stać przyczyną hazardu lub wypadku będącego skutkiem hazardu.W skrócie: należy sprawdzić wymagania, mówiące o tym co system powinienrobić, z wymaganiami bezpieczeństwa, czyli mówiącymi, czego system niemoże zrobić.Dzięki temu podejściu zwiększamy prawdopodobieństwo wykrycia problemówzwiązanych z bezpieczeństwem.

17




• Dobre praktyki -zaawansowane:– Specyfikuj systemy

korzystając z metodformalnych

– Zbieraj informację oincydentach

– Wyciągaj wnioski zincydentów

– Ustanów w organizacjikulturę bezpieczeństwa

Adv.

Ostatnie cztery praktyki to praktyki zaawansowane. Ich wprowadzenie jestnajbardziej kosztowne, lecz inwestycja ta często zwraca się bardzo szybko wprzypadku systemów krytycznych.Pierwsza praktyka: „Specyfikuj systemy za pomocą metod formalnych”.Metody formalne posiadają notację, której składnia i semantyka jest formalniezdefiniowana. Dzięki temu modele, które powstają są dużo bardziejjednoznaczne.Specyfikacja formalna powinna powstać po analizie wymagań. Czynność tawymaga bardzo dogłębnej analizy tych wymagań, przez co znalezieniebłędów i niejasności jest bardzo prawdopodobne.Dodatkową zaletą metod formalnych jest możliwość udowodnieniakompletności i braku niejednoznaczności.Wprowadzanie takich metod jest kosztowne. Wielu inżynierów ich nie zna,stąd duże środki są wymagane do przeszkolenia ludzi.Głównym problemem w stosowaniu notacji formalnych jest fakt, iż mogą byćniezrozumiałe dla ekspertów dziedzinowych. Czyli takie osoby nie będą wstanie analizować modelu np. pod względem bezpieczeństwa.

18









Adv.

Druga praktyka, to „Zbieraj informację o incydentach”.Organizacja zajmująca się systemami krytycznymi powinna stworzyć systemdla zbierania i zarządzania informacją na temat wypadków związanych zbezpieczeństwem, czy niezawodnością, które miały miejsce w systemachwdrożonych dla klientów. System powinien również zarządzać informacją natemat tego, jak zapobiegać takim zdarzeniom w przyszłości.Nauka poprzez doświadczenie jest szczególnie istotna w przypadkusystemów krytycznych. Baza danych doświadczenia z wypadków, którewystąpiły w poprzednich systemach służy jako „pamięć” w firmie i pomagazredukować szanse wystąpienia podobnych błędów w przyszłości.Nie wystarczy tutaj wdrożenie narzędzia do obsługi takiej informacji. Potrzebarównież dostosować procesy w firmie i przeszkolić pracowników, tak abyosoby zajmujące się specyfikacją wiedziały co i kiedy zapisywać.

19









Adv.

Kolejna praktyka to: „Wyciągaj wnioski z incydentów”Wykorzystując informację o incydentach, powinno się sprawdzić krzyżowowymagania z informacją o incydentach. W ten sposób zmniejszymy znacznieprawdopodobieństwo dopuszczenia możliwości wystąpienia znanychproblemów w nowych projektach.Takie podejście jest szczególnie istotne jeżeli weźmiemy pod uwagę rotacjępracowników w firmie, co skutkuje pojawianiem się nowych,niedoświadczonych pracowników.Oczywistym jest, że zanim będzie możliwość skorzystania z tej praktyki,musimy najpierw stworzyć bazę danych incydentów, czyli „Zbierać informacjęo incydentach”.W momencie kiedy mamy już taką bazę danych napotykamy szeregproblemów, np. wielkość tej bazy danych może nie pozwolić na efektywnesprawdzenie wymagań.To wszystko sprawia, iż praktyka ta jest bardzo kosztowna, zarówno napoczątku - podczas jej wprowadzania do organizacji, jak i później - w trakciezastosowania.

20









Adv.

Ostatnia praktyka IW dla systemów krytycznych to „Ustanów w organizacjikulturę bezpieczeństwa”.

Kultura bezpieczeństwa oznacza, że każda osoba w organizacji zdaje sobiesprawę z bezpieczeństwa i czuje się odpowiedzialna, za to żeby systemyprzez nią tworzone były bezpieczne.

Proces zmiany kultury w organizacji jest bardzo złożony. Opiera się nazmianie priorytetów. Firma, stawiająca na bezpieczeństwo, powinnanagradzać pracowników, za tworzenie bezpiecznych systemów, a nie zaich produktywność.

21



Plan wykładu



– Wprowadzenie dometody

– Słowa kluczowe– Procedura

Przejdziemy teraz do omówienia metody HAZOP. Jak już powiedzieliśmywcześniej, metoda HAZOP służy do identyfikacji i analizowania hazardów, jakrównież jest to dobry sposób do formułowania list kontrolnych dot.bezpieczeństwa systemu.

22



Wprowadzenie do metody HAZOP

HAZOP: HAZard and OPerability study; ICI Chemicals, UK, ‘70

Cel: ‘wykrycie potencjalnych hazardów i problemówoperacyjnych wynikacjących z odchyleń od zamierzeńprojektowych zarówno nowych jak i istniejących instalacji[Mike Lihou, Hazard & Operability Studies].

Metoda HAZOP została zapoczątkowana w Anglii w latach 70 w ICI (ang.Imperial Chemical Industries), jednym z większych producentów artykułówchemicznych na świecie.HAZOPS jest skrótem od: HAZard and OPerability study, czyli studiumhazardu i operacyjności, natomiast celem metody jest: „wykryciepotencjalnych hazardów i problemów operacyjnych wynikających z odchyleńod zamierzeń projektowych zarówno nowych jak i istniejących instalacji”.W definicji tej pada wiele terminów, które mogą być na pierwszy rzut okaniezrozumiałe. Zastanówmy się nad nią krok po kroku.

23




Cel: ‘wykrycie potencjalnych hazardów i problemówoperacyjnych wynikacjących z odchyleń od zamierzeńprojektowych zarówno nowych jak i istniejących instalacji.

Instalacja grzewczaUrządzenie naświetlające

Akceleratorelektronowy

Zacznijmy od końca. Czym jest instalacja?Instalacja to właśnie system krytyczny - czyli system, który ma nałożonepewne wymagania dotyczące bezpieczeństwa. Jeżeli te wymagania nie będąspełnione, to system może wyrządzić krzywdę użytkownikowi.Zatem instalacją może być np. sterowanie instalacją grzewczą, lub urządzenienaświetlające.

24




Przejazd kolejowy System sterowania samolotem

Cel: ‘wykrycie potencjalnych hazardów i problemówoperacyjnych wynikacjących z odchyleń od zamierzeń

projektowych zarówno nowych jak i istniejących instalacji.

Instalacjami mogą być również systemy bardziej skomplikowane, np.sterowanie oświetleniem (+ew. zaporami) na przejeździe kolejowym, czy teżbardzo złożony system sterowania samolotem.

25




Istniejące Nowe


HAZOP może być wykorzystywany zarówno do przeprowadzania przeglądówistniejących systemów, jak i systemów, których jeszcze nie ma, czyli ichprojektów. W jednym i drugim przypadku można znaleźć hazardy, które mogąstać się przyczyną awarii w przyszłości.

26





Instalacja grzewczaUrządzenie naświetlające

Akceleratorelektronowy~ 200 rad

do 50℃

Czym są zamierzenia projektowe? To wszelkie ograniczenia wynikające zwymagań bezpieczeństwa. Takim ograniczeniem może być np. założenie, żeurządzenie naświetlające nie naświetli pacjenta dawką większą niż 200 radjednorazowo, np. instalacja grzewcza nie dopuści do temperatury wyższej niż50 stopni Celsjusza.

27





Instalacja grzewczaAwaria Therac-25

Akceleratorelektronowy15000 rad

90℃Auch!

Natomiast odchylenia od zamierzeń projektowych to naruszenia takichwymagań.Klasycznym już przykładem takiego odchylenia, które było katastrofalne wskutkach to awaria urządzenia Therac-25.Urządzenia te służyły do radioterapii nowotworów.Dla osoby dorosłej napromieniowanie rzędu 1000-2000 rad grozi śmiercią. Wlatach 85-87 przynajmniej sześciu pacjentów otrzymało bardzo wysokie dawkipromieniowania (rzędu dziesiątek tysięcy radów). Wszystkie osoby zmarły.Główną przyczyną nieprawidłowego funkcjonowania urządzeń był trudny dowykrycia błąd typu „race condition”. Polegał na tym, że przy odpowiednioszybkiej pracy operatora pewne parametry zabiegu nie były prawidłowoinicjowane. Przed takim problemem można się było zabezpieczyć stosującmechaniczne zabezpieczenie (takie były wykorzystywane we wcześniejszychsystemach Therac), lecz ze względu na redukcję kosztów, nie zdecydowanosię na to.

28




Hazard = zbiór warunków, które mogą prowadzić do wypadku


Akceleratorelektronowy15000 rad

90℃

Hazard, to zbiór warunków, które mogą prowadzić do wypadku. Tak więchazard to dopuszczenie przez urządzenie naświetlające do wypromieniowaniadawki większej niż dopuszczalna. Hazardem również byłyby warunki, któremogą dopuścić do temperatury wyższej niż dopuszczalna w instalacjigrzewczej.

29




O kurcze!


Hazardem jest również sytuacja, w której będzie zielone światło, lubpodniesiona zapora na przejeździe kolejowym przez który przejeżdża pociąg.

30




Wysokościomierzprzestał działać!


Problemy operacyjne natomiast mają trochę inny charakter. To problemy zprawidłowym funkcjonowaniem systemu - przykładowo jak w samolocieprzestanie działać wysokościomierz - nie prowadzi to bezpośrednio dowypadku, lecz utrudnia prowadzenie samolotu.

31




Przeprowadzona przez zespółekspertów z różnych dziedzin.

Strukturalna burza mózgów


Tak więc przeczytajmy jeszcze raz z pełnym zrozumieniem, jaki jest celmetody HAZOP: „wykrycie potencjalnych hazardów i problemów operacyjnychwynikających z odchyleń od zamierzeń projektowych zarówno nowych jak iistniejących instalacji.”Analiza taka, aby była skuteczna musi być przeprowadzona przez zespółekspertów z różnych dziedzin i ma postać strukturalnej burzy mózgów.

32




Opisprocesu

Jakie odchylenia mogą powstać?Jak mogą wpłynąć na bezpieczeństwo i operacyjność?

Jakie akcje są konieczne?

Eksperci analizujący system zadają sobie następujące pytania:1. Jakie odchylenia mogą powstać?2. Jak mogą wpłynąć na bezpieczeństwo i operacyjność?3. Jakie akcje są konieczne, aby temu zapobiec?

33




... zachęca zespół do zastanowienia się nad mniejoczywistymi sposobami wystąpienia dewiacji (…)Dzięki temu analiza staje się czymś więcej, niżtylko mechanicznym przeglądem w oparciu olistę kontrolną. [Mike Lihou, Hazard & OperabilityStudies]

Eksperci od HAZOPa, chwalą sobie tą metodę, gdyż ich zdaniem pozwala nazastanowienie się nad mniej oczywistymi sposobami wystąpienia dewiacji.

34



Plan wykładu



– Wprowadzenie dometody

– Słowa kluczowe– Procedura

Metoda HAZOP opiera się na słowach kluczowych dwojakiego rodzaju.Wyróżnia główne i pomocnicze słowa kluczowe.

35



Słowa kluczowe

Słowa kluczowe

Główne Pomocnicze

Temperatura

Ciśnienie

Przepływ

Brak

Za duże

Za małe

Odwrotne

…

…

Przyczynadewiacji

Słowa kluczowe główne oznaczają jakiś parametr urządzenia, natomiast słowakluczowe pomocnicze, pewne problemy związane z parametrami. Popołączeniu obu otrzymujemy możliwą dewiację (np. temperatura jest za duża),następnie eksperci sprawdzają, czy taka dewiacja jest możliwa w systemie ibadają jej przyczynę.W dalszej części wykładu trzeba mieć na uwadze, że metoda HAZOP jakotaka została stworzona do przeglądu układów chemicznych, dlatego wszystkiesłowa kluczowe dotyczą tego rodzaju urządzeń. Jednak nic nie stoi naprzeszkodzie, aby doświadczenia metody przenieść na inny grunt, np. gruntoprogramowania dla systemów krytycznych.

36



Słowa kluczowe

Główne słowa kluczowe: szczególny aspekt zamierzeniaprojektowego (parametr procesu).

Bezpieczeństwo: Operacyjność:

Flow Start-upTemperature ShutdownPressure DrainLevel MaintainCorrode InspectAbsorb Purge... Isolate

...

W jaki sposób korozjawpływa na zamierzenia

projektowe?

Wchodząc bardziej w szczegóły, główne słowo kluczowe to szczególny aspektzamierzenia projektowego. Metoda HAZOP wymienia szereg takich słów.Część z nich jest związana z bezpieczeństwem, np:-Flow - przepływ-Temperature - temperatura-Pressure - ciśnienie-Level - poziom-Corrode - korozja-Absorb - absorbcjaInne dotyczą operacyjności.

Zbiorem głównych słów kluczowych można manipulować i w ten sposóbdostosowywać metodę HAZOP do innych zastosowań.

37



Słowa kluczowe

NoLessMore

ReverseAlso

OtherFluctuation

EarlyLate

Zbiór ten jest raczej stały.

No: Dany aspekt jest prawie wyeliminowany(zablokowany) lub nieosiągalny.

Przykłady:

Flow/No

Isolate/No

Response/No

Pomoc. słowa kluczowe: możliwe dewiacje (problemy)

Pomocnicze słowa kluczowe, to możliwe dewiacje (problemy) dotyczącegłównych słów kluczowych. Zbiór ten jest raczej stały.Przeanalizujmy je po kolei.Pierwsze: „No” oznacza, że dany aspekt jest praktycznie wyeliminowany, lubnieosiągalny.Dokładniejszy sens otrzymujemy po połączeniu z głównym słowemkluczowym, np:-Flow/No - oznacza, że w danym fragmencie urządzenia (np rurze) nie maprzepływu-Isolate/No - to brak izolacjiNa końcu każdego kolejnego slajdu będzie przykład słowa kluczowego, którema zastosowanie w systemach krytycznych. Przykładowo:-Response/No - brak odpowiedzi systemu

38



Słowa kluczowe

Less: Wartość parametru jest mniejsza odoczekiwanej.

Przykłady:

Flow/Less

Temperature/Less

Throughput/Less

Pomoc. słowa kluczowe: możliwe dewiacje (problemy)No

LessMore

ReverseAlso

OtherFluctuation

EarlyLate

„Less” oznacza sytuację, w której wartość parametru jest mniejsza odoczekiwanej, np:-Flow/Less - zbyt mały przepływ, np w systemie podgrzewania wody welektrowni cieplnej-Temperature/Less - za niska temperatura, np w systemie sterującym piecemhutniczym-Throughput/Less - za słaba przepustowość

39



Słowa kluczowe

More: Wartość parametru jest większa odoczekiwanej.

Przykłady:

Pressure/More

Transaction Rate/More


NoLess

MoreReverse

AlsoOther

FluctuationEarlyLate

„More” występuje gdy wartość parametru jest większa od oczekiwanej, np:-Pressure/More - zbyt duże ciśnienie-Transaction Rate/More - zbyt duża liczba transakcji w określonym czasie

40



Słowa kluczowe

Reverse: Przeciwny kierunek.

Przykłady:

Flow/Reverse

??? / Reverse


NoLessMore

ReverseAlso

OtherFluctuation

EarlyLate

Dewiacja „reverse” występuje w przypadku kiedy dany parametr ma odwrotnykierunek.Jedyne sensowne połączenie tej dewiacji z głównym słowem kluczowym to„Flow/Reverse” - oznacza, że przepływ w danym fragmencie systemu jest wodwrotną stronę, niż się spodziewano.W systemach informatycznych dewiacja „Reverse” wydaje się nie miećzastosowania.

41



Słowa kluczowe

Also: Główne słowo kluczowe jest OK., ale jest cośdodatkowego.

Przykłady:

Flow/Also = zanieczyszczenie

Action/Also = efekt uboczny


NoLessMore

Reverse

AlsoOther


„Also” oznacza, że główne słowo kluczowe jest w porządku, lecz pojawia sięjakiś inny problem z tym związany.Przykładowo:-Flow/Also może oznaczać, że szybkość przepływu jest OK, lecz opróczcieczy, która powinna przepływać pojawiają się również zanieczyszczenia.-Action/Also - to negatywny efekt uboczny wykonywanej akcji, która sama wsobie jest poprawna

42



Słowa kluczowe

Other: Parametr występuje ale w inny sposób.

Przykłady:

Flow/Other = Przepływ do nieprzewidzianego miejsca

Value/Other = Przepełnienie


LessMore

ReverseAlso

OtherFluctuation

EarlyLate

„Other” - oznacza, że analizowany parametr występuje, lecz w inny sposób,np:-Flow/Other - przepływ cieczy do nieprzewidzianego miejsca-Value/Other - może oznaczać przepełnienie zmiennej

43



Słowa kluczowe

Fluctuation: Właściwe zachowanie osiągane tylkoczasami.

Przykłady:

Flow/Fluctuation = Czasami płynie, czasami nie.

Temperature/Fluctuation = Czasami zimne.

Throughput/Fluctuation = Czasami za niska.

Pomoc. słowa kluczowe: możliwe dewiacjeNo

LessMore

ReverseAlso

Other


„Fluctuation” - oznacza, że właściwe zachowanie parametru będzie miałomiejsce sporadycznie, np:-Flow/Fluctuation - może oznaczać, że w analizowanym układzie cieczczasami będzie płynąć, a czasem nie-Temperature/Fluctuation - czasem temperatura będzie zbyt niska (lub zbytwysoka)-Throughput/Fluctuation - przepustowość czasem za niska

44



Słowa kluczowe

Early: Za wcześnie.

Przykłady:

Flow/Early = płynie za wcześnie.

Temperature/Early = Temperatura jest osiągana zawcześnie.

State/Early = Za wczesne przejście do stanu


LessMore

ReverseAlso

OtherFluctuation

EarlyLate

„Early” - parametr występuje zbyt wcześnie, np-Flow/Early - ciecz płynie w układzie, zanim powinna (np. zanim system zdążyłsię zinicjalizować po starcie)-Temperature/Early - wysoka temperatura jest osiągana zbyt wcześnie-State/Early - za wczesne przejście do określonego stanu aplikacji

45



Słowa kluczowe

Late: Za późno.

Przykłady:

Level/Late = Poziom w zbiorniku osiągnięty za późno.

Activity/Late = Czynność wykonana za późno


NoLessMore

ReverseAlso

OtherFluctuation

Early

Late

„Late” - dewiacja polegająca na tym, że wartość pewnego parametru zostałaosiągnięta zbyt późno, np:-Level/Late - poziom w zbiorniku osiągnięty zbyt późno-Activity/Late - konkretna czynność może zostać wykonana za późno

46



Słowa kluczowe

Czy wszystkie kombinacjesłów mają sens?

Temperature/No ???

Corrode/Reverse ???

State/Reverse ???


LessMore

ReverseAlso

OtherFluctuation

EarlyLate

Okazuje się, że nie wszystkie kombinacje słów kluczowych mają sens, np:-Temperature/No - może być za niska, lub za wysoka, ale jakaś temperaturajest zawsze-Corode/Reverse - nawet jeżeli byłaby możliwość cofnięcia korozji (np. zapomocą pewnych środków chemicznych), to na pewno nie byłoby to szkodliwedla systemu

47



Formularz HAZOP-u

AkcjaZabezpiecz.SkutkiPrzyczynaDewiacja

E.g.State/No

Potencjalnaprzyczynadewiacji

Konsekwencjewystąpienia

dewiacji

Istniejąceurządzenia

zabezpieczająceprzed wystąpie-niem przyczynylub łagodzące

skutki

Akcje jakienależy podjąć,

aby usunąćprzyczynę lub

złagodzićskutki

W trakcie przeglądu HAZOP eksperci powinni wypełnić następujący formularzzłożony z tabeli, która ma kilka kolumn. Każdy wiersz tej tabeli opisuje jedenproblem i posiada następujące atrybuty:-Dewiacja - oznacza rodzaj dewiacji wyrażony przez połączenie 2 słówkluczowych, np.. State/No-Potencjalna przyczyna dewiacji - opis warunków/akcji, które muszą byćspełnione, aby doszło do danej dewiacji-Skutki - zawiera konsekwencje wystąpienia dewiacji-Zabezpieczenie - w jaki sposób system się przed tym zabezpiecza, lubłagodzi skutki?-Akcja - jakie akcje należy podjąć aby usunąć przyczynę lub złagodzić skutki?

48



Proces analizy

Wybierz fragment instalacjiDla każdego głównego słowa kluczowego:

Dla każdego pomocniczego słowa kluczowego:

Pomyśl o skutkach i zapisz je;Zapisz zidentyfikowane zabezpieczenia;Pomyśl o koniecznych akcjach i zapisz je;

Dla każdej wykrytej przyczyny dewiacji

AkcjaZabezpiecz.SkutkiPrzyczynaDewiacja

ProblemState/No

Schemat spotkania wg. HAZOP’a wygląda następująco:1. Eksperci wybierają pewien fragment instalacji - w przypadku systemów

informatycznych może to być np. projekt architektoniczny2. Dla każdego głównego słowa kluczowego, eksperci wybierają te

pomocnicze słowa kluczowe, których połączenie ma sens.3. Dla każdego pomocniczego słowa kluczowego, eksperci szukają

możliwych przyczyn dewiacji.4. Dla każdej wykrytej przyczyny dewiacji, eksperci zastanawiają się nad

skutkami, istniejącymi zabezpieczeniami oraz koniecznymi akcjami, któretrzeba podjąć.

Wszystko zapisują w formularzu, który jest podstawą dalszych działań.

49



Zespół HAZOP-u

Optimum: 6 osóbMaksimum: 9 osób

Równa reprezentacjaklienta i dostawcy

Eksperci z różnychdyscyplin

Skład zespołu: Natychmiasto-we odpowiedzi na pytaniazadawane w trakcie spotkania.

Przewodniczący i sekretarz

Osoby, które stosowały HAZOPa w praktyce zalecają, aby zespół ekspertównie był zbyt duży - maksymalnie może zawierać 9 osób - praca w większejgrupie jest nieefektywna, gdyż osiąganie kompromisów staje się trudne.Należy zadbać, aby w zespole była taka sama reprezentacja klienta, jak idostawcy, oraz żeby eksperci pochodzili z różnych dziedzin. Skład zespołupowinien być taki, aby można było udzielić natychmiastowej odpowiedzi nazadawane pytania, czyli w przypadku systemów informatycznych powinni wnim brać udział analitycy lub architekci.W celu łatwiejszego zachowania porządku na spotkaniu powinny być równieżustalone role przewodniczącego i sekretarza.

50



Podsumowanie

• Systemy krytyczne to szczególnyrodzaj systemów, który maszczególnie wyśrubowanewymagania bezpieczeństwa

• HAZOP jest strukturalną formąburzy mózgów zorientowaną naanalizę ryzyka technicznego

• HAZOP ma różne zastosowania(np. UML-HAZOP)

• Stosowana przez: UK Ministry ofDefence, Motorola, firmychemiczne, etc.

Podsumowując wykład:•Systemy krytyczne to taki rodzaj systemów, który ma szczególniewyśrubowane wymagania bezpieczeństwa•HAZOP jest strukturalną formą burzy mózgów zorientowaną na analizęryzyka technicznego, poprzez wyszukiwanie dewiacji w systemach napodstawie kombinacji głównych i pomocniczych słów kluczowych•HAZOP ma różne zastosowania, np istnieje metoda UML-HAZOPdostosowana do przeglądów diagramów UML•Metoda ta jest obecnie stosowana przez niektóre organizacje, np: UK Ministryof Defence, Motorola, firmy chemiczne, i inne.

51



Literatura

• Mike Lihou, Hazard & Operability Studies, LihouTechnical & Software Services,www.lihoutech.com/hzp1frm.htm, 3.06.2003.

• N. Leveson, C. Turner, An investigation of theTherac-25 Accidents, Computer, July 1993

• F. Redmill, M. Chudleigh, J.Catmur, SystemSafety: HAZOP and Software HAZOP, JohnWiley & Sons, 1999

• J.Górski, A.Jarzębowicz, Wykrywanie anomalii wmodelach obiektowych za pomocą metody UML-HAZOP, IV KKIO

Systemy krytyczne i HAZOP -...

Documents

Transcript of Systemy krytyczne i HAZOP -...