Post on 08-Apr-2018
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
Zaawansowana inżynieria oprogramowania
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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (5)
Wprowadzenie - przykłady systemów krytycznych
• Reaktornuklearne -systemysterowania
źródło: Wikipedia
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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (6)
Wprowadzenie - przykłady systemów krytycznych
• Poduszkapowietrzna
źródło: Wikipedia
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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (13)
IW dla systemów krytycznych
• 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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (14)
IW dla systemów krytycznych
• 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.
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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (16)
IW dla systemów krytycznych
• Dobre praktyki - pośrednie:– Zidentyfikuj i zanalizuj
hazardy– Na podstawie analizy
hazardów formułujwymagania dot.bezpieczeństwa
– 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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (17)
IW dla systemów krytycznych
• 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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (18)
IW dla systemów krytycznych
• Dobre praktyki -zaawansowane:– Specyfikuj systemy
korzystając z metodformalnych
– Zbieraj informację oincydentach
– Wyciągaj wnioski zincydentów
– Ustanów w organizacjikulturę bezpieczeństwa
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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (19)
IW dla systemów krytycznych
• Dobre praktyki -zaawansowane:– Specyfikuj systemy
korzystając z metodformalnych
– Zbieraj informację oincydentach
– Wyciągaj wnioski zincydentów
– Ustanów w organizacjikulturę bezpieczeństwa
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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (20)
IW dla systemów krytycznych
• Dobre praktyki -zaawansowane:– Specyfikuj systemy
korzystając z metodformalnych
– Zbieraj informację oincydentach
– Wyciągaj wnioski zincydentów
– Ustanów w organizacjikulturę bezpieczeństwa
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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (21)
Plan wykładu
• Wprowadzenie• Dobre praktyki IW dla
systemów krytycznych• HAZOP:
– 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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (23)
Wprowadzenie do metody HAZOP
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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (24)
Wprowadzenie do metody HAZOP
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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (25)
Wprowadzenie do metody HAZOP
Istniejące Nowe
Cel: ‘wykrycie potencjalnych hazardów i problemówoperacyjnych wynikacjących z odchyleń od zamierzeńprojektowych zarówno nowych jak i istniejących instalacji.
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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (26)
Wprowadzenie do metody HAZOP
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~ 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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (27)
Wprowadzenie do metody HAZOP
Cel: ‘wykrycie potencjalnych hazardów i problemówoperacyjnych wynikacjących z odchyleń od zamierzeńprojektowych zarówno nowych jak i istniejących instalacji.
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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (28)
Wprowadzenie do metody HAZOP
Hazard = zbiór warunków, które mogą prowadzić do wypadku
Cel: ‘wykrycie potencjalnych hazardów i problemówoperacyjnych wynikacjących z odchyleń od zamierzeńprojektowych zarówno nowych jak i istniejących instalacji.
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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (29)
Wprowadzenie do metody HAZOP
O kurcze!
Cel: ‘wykrycie potencjalnych hazardów i problemówoperacyjnych wynikacjących z odchyleń od zamierzeńprojektowych zarówno nowych jak i istniejących instalacji.
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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (30)
Wprowadzenie do metody HAZOP
Wysokościomierzprzestał działać!
Cel: ‘wykrycie potencjalnych hazardów i problemówoperacyjnych wynikacjących z odchyleń od zamierzeńprojektowych zarówno nowych jak i istniejących instalacji.
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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (31)
Wprowadzenie do metody HAZOP
Przeprowadzona przez zespółekspertów z różnych dziedzin.
Strukturalna burza mózgów
Cel: ‘wykrycie potencjalnych hazardów i problemówoperacyjnych wynikacjących z odchyleń od zamierzeńprojektowych zarówno nowych jak i istniejących instalacji.
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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (32)
Wprowadzenie do metody HAZOP
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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (33)
Wprowadzenie do metody HAZOP
... 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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (34)
Plan wykładu
• Wprowadzenie• Dobre praktyki IW dla
systemów krytycznych• HAZOP:
– 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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (39)
Słowa kluczowe
More: Wartość parametru jest większa odoczekiwanej.
Przykłady:
Pressure/More
Transaction Rate/More
Pomoc. słowa kluczowe: możliwe dewiacje (problemy)
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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (40)
Słowa kluczowe
Reverse: Przeciwny kierunek.
Przykłady:
Flow/Reverse
??? / Reverse
Pomoc. słowa kluczowe: możliwe dewiacje (problemy)
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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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
Pomoc. słowa kluczowe: możliwe dewiacje (problemy)
NoLessMore
Reverse
AlsoOther
FluctuationEarlyLate
„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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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
Pomoc. słowa kluczowe: możliwe dewiacje (problemy)No
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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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
FluctuationEarlyLate
„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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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
Pomoc. słowa kluczowe: możliwe dewiacje (problemy)No
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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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
Pomoc. słowa kluczowe: możliwe dewiacje (problemy)
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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (46)
Słowa kluczowe
Czy wszystkie kombinacjesłów mają sens?
Temperature/No ???
Corrode/Reverse ???
State/Reverse ???
Pomoc. słowa kluczowe: możliwe dewiacje (problemy)No
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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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
Zaawansowana inżynieria oprogramowania
Systemy krytyczne i HAZOP (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