docOcena programów komputerowych do analiz drzew błędów/zdarzeń
download 
Reklamacja Transkrypt
Ocena programów komputerowych do analiz drzew błędów/zdarzeń
Ocena programów komputerowych do analiz drzew błędów/zdarzeń na potrzeby probabilistycznej oceny bezpieczeństwa elektrowni jądrowych M. Borysiewicz1, S. Potempski1, P. Prusiński2, A. Wasiuk1 1 Instytut Energii Atomowej POLATOM 2 Instytut Problemów Jądrowych Świerk, listopad 2010 1 2 Streszczenie Zasadniczym celem niniejszego opracowania było porównanie zakresu możliwości programów komputerowych do projektowania i analiz drzew błędów/zdarzeń. Raport składa się z dwóch części. Pierwsza z nich jest wprowadzeniem do tematu Probabilistycznej Oceny Bezpieczeństwa/Ryzyka (z ang. Probabilistic Safety/Risk Analysis – PSA/PRA). Zawiera ona zatem nie tylko wyjaśnienie znaczenia i zakresu stosowalności teorii, ale także informacje oraz porady z zakresu modelowania instalacji jądrowych podatnych pod kątem wystąpienia uszkodzeń. Przedstawia również dobre praktyki stosowane podczas modelowania sytuacji awaryjnych. Szeroko omawia zagadnienia modelowania błędów ludzkich czy awarii spowodowanych wspólną przyczyną. Druga część tego raportu dotyczy właściwego porównania oprogramowania dostępnego na rynku. Wzięto tu pod uwagę 7 różnych aplikacji i przeanalizowano je pod kątem blisko 30 różnych kategorii. Jednymi z głównych kryteriów były funkcjonalność programu, wieloletnie doświadczenie producenta w branży, faktyczne wykorzystanie jego oprogramowania w przemyśle jądrowym, cena, wymagania sprzętowe i wreszcie jakość interfejsu użytkownika. Efektem tej analizy była sugestia wyboru produktów rekomendowanych z punktu widzenia zastosowania w Polsce. Summary The assessment of fault and event trees analysis software for the NPPs safety evaluation purpose. The main goal of this paper is to compare the functionality of the computer software which is used to create and analyze fault and event trees. The report is divided into two main parts. The first part should be treated as a introduction to the Probabilistic Safety/Risk Analysis (PSA/PRA). Thus, it includes not only the explanation of the meanings and range of applicability of the theory, but also information and hints concerning the modeling of nuclear facilities, especially those working at higher risk of damage. This part shows also good practices that are used for modeling of the emergency situation. It includes also know-how for the human factors and common cause failures. The second part of this paper focuses on the comparison of the software which are currently available in the market. There were, in total, 7 different applications under the consideration and they were analyzed in terms of ca. 30 different criteria. The most important criteria were as follows: software functionality, long-term experience of the software producer in the market, references from the nuclear industry, price, hardware requirements and finally quality of GUI.. As a result of this analysis the choice of the recommended software has been done. That software fulfill the best all the requirements from the point of view of the Polish Nuclear Industry needs. 3 Spis treści: 1. 2. 3. 4. WPROWADZENIE ................................................................................................................... 5 ZASTOSOWANIE DRZEW BŁĘDÓW W ANALIZACH PSA .............................................. 5 OGÓLNE WYMAGANIA DOTYCZĄCE DRZEW BŁĘDÓW DLA ANALIZ RYZYKA EJ7 PODSTAWOWE POJĘCIA I ELEMENTY METODOLOGICZNE........................................ 8 4.1. System jako podmiot analizy ................................................................................................. 8 4.2. Określenie zdarzeń................................................................................................................. 9 4.3. Elementy logiczne drzewa błędów ...................................................................................... 12 4.4. Podstawowe zasady konstruowania drzew błędów.............................................................. 13 5. ZALECENIA DOTYCZĄCE FORMATU DRZEW BŁĘDÓW............................................. 15 5.1. Graficzna reprezentacja drzew błędów....................................................................................... 15 5.1.1. Symbole graficzne....................................................................................................... 15 5.1.2. Kodowe nazwy zdarzeń .............................................................................................. 17 5.2. Wykorzystanie wspomagania komputerowego w analizie drzew błędów........................... 19 6. PRAKTYCZNE WSKAZANIA DOTYCZĄCE ANALIZY SYSTEMÓW EJ ...................... 33 6.1. Modelowanie systemów EJ.................................................................................................. 33 6.1.1. Podstawowe typy systemów........................................................................................ 33 6.1.2. Zasady dekompozycji systemu.................................................................................... 36 6.1.3. Szczegółowość modelu ............................................................................................... 37 6.1.4. Niektóre założenia modelowe ..................................................................................... 38 6.1.5. Identyfikacja istotnych zdarzeń................................................................................... 38 6.1.6. Identyfikacja i usunięcie pętli logicznych ................................................................... 40 6.2. Zdarzenia wierzchołkowe dla systemów EJ ........................................................................ 42 6.3. Dokumentacja modelu ......................................................................................................... 42 7. TECHNIKI UZUPEŁNIAJĄCE STOSOWANE W OSZACOWANIACH ZDARZEŃ AWARYJNYCH ................................................................................................................................... 44 7.1. Podstawy metod ocen błędów ludzkich w aspekcie bezpieczeństwa systemów technicznych 44 7.1.1. Analiza niezawodności człowieka............................................................................... 44 7.1.2. Podstawowe elementy analiz niezawodności człowieka............................................. 45 7.1.3. Rola czynników kształtujących działanie (PSF) w HRA ............................................ 48 7.1.4. Ogólne zasady analizy działań człowieka w aspekcie niezawodności i bezpieczeństwa systemu 51 7.1.5. Zasady selekcji metod i technik analizy niezawodności człowieka ............................ 63 7.2. Błędy o wspólnej przyczynie (CCF).................................................................................... 66 7.2.1. Rodzaje CCF ............................................................................................................... 66 7.2.2. Proste metody uwzględniania CCF w modelach drzew błędów ................................. 68 8. PORÓWNANIE OPROGRAMOWANIA DO ANALIZ PROBABILISTYCZNYCH DLA ENERGETYKI JĄDROWEJ ................................................................................................................ 69 8.1. Krótka charakterystyka analizowanych programów............................................................ 69 8.1.1. RiskSpectrum PSA Professional ................................................................................. 69 8.1.2. SAPHIRE .................................................................................................................... 70 8.1.3. RELEX 2009 ............................................................................................................... 72 8.1.4. ITEM QRAS oraz ITEM Toolkit ................................................................................ 73 8.1.5. FaultTree+ ................................................................................................................... 74 8.1.6. OpenFTA..................................................................................................................... 74 8.2. Analiza porównawcza oprogramowania .............................................................................. 76 8.3. Funkcjonalność oprogramowania referencyjnego ............................................................... 93 9. WNIOSKI KOŃCOWE ......................................................................................................... 113 10. BIBLIOGRAFIA.................................................................................................................... 114 4 1. WPROWADZENIE Niniejsze opracowanie jest jednym z etapów szerszego programu prac związanych z oceną bezpieczeństwa i niezawodności elektrowni jądrowych przy użyciu metod probabilistycznych. Perspektywicznym celem tych prac jest wykonanie probabilistycznych analiz bezpieczeństwa (Probabilistic Safety Assessment - PSA) dla elektrowni jądrowych. Podstawowym etapem analiz jest opracowanie modelu EJ przystosowanego do potrzeb PSA zawierającego dwa podstawowe elementy - drzewa zdarzeń określające zbiór wszystkich możliwych ciągów awaryjnych oraz drzewa błędów dla poszczególnych systemów technologicznych EJ istotnych z punktu widzenia rozwoju sytuacji awaryjnych. W pierwszej części opracowania zawarto informacje porządkowe i pewne wskazania metodologiczne związane z opracowaniem systemowych drzew błędów przez poszczególnych wykonawców tego etapu prac. Wytyczne zamieszczone w opracowaniu powinny przyczynić się do uzyskania spójnego materiału, który będzie mógł być łatwo wykorzystany w dalszych etapach prac. W dalszej części dokumentu dokonano analizy i porównania najczęściej stosowanych programów komputerowych do analiz drzew błędów (FTA – fault tree analysis) dostępnych na rynku. Porównanie to przeprowadzono zarówno pod kątem funkcjonalnym jak i takich czynników jak: cena, możliwości przeprowadzenia szkoleń, referencji firm produkujących oprogramowanie oraz wymagań sprzętowych i programistycznych. 2. ZASTOSOWANIE DRZEW BŁĘDÓW W ANALIZACH PSA Technika drzew błędów jest jedną z najczęściej stosowanych metod analizy systemowej. Analiza ma charakter dedukcyjny i koncentruje się na określonym niepożądanym zdarzeniu (zwykle uszkodzeniu lub niesprawności operacyjnej systemu) a jej celem jest wskazanie jakie są przyczyny zaistnienia niepożądanej sytuacji. Drzewo błędów jest logicznym schematem pokazującym w jaki sposób uszkodzenie lub niesprawność systemu może być spowodowana przez uszkodzenia jego części składowych lub przez inne zdarzenia (np. błędy obsługi eksploatacyjnej). Analiza prowadząca do zbudowania drzewa błędów rozpoczyna się od zdefiniowania tzw. zdarzenia wierzchołkowego (np. uwolnienia produktów radioaktywnych lub niesprawności systemu) i jest prowadzona w sposób systematyczny przez identyfikację wszystkich możliwych przyczyn tego zdarzenia, (uszkodzeń lub innych zdarzeń). Postępowanie takie jest kontynuowane w odniesieniu do wszystkich kolejnych zdarzeń, aż do osiągnięcia właściwego poziomu szczegółowości. W rezultacie zdarzenie wierzchołkowe zostaje wyrażone w kategoriach zdarzeń łatwych do oceny, zarówno jakościowej jak i ilościowej. Zdarzenia te powinny być wybrane w taki sposób, aby możliwe było ich scharakteryzowanie w kategoriach probabilistycznych na podstawie obserwacji eksploatacyjnych, stosowanych w praktyce zasad eksploatacji, systemu, właściwości fizycznych systemu itp. Zdarzenia pierwotne obejmują zwykle różnego rodzaju uszkodzenia i niesprawności, błędy personelu eksploatacyjnego, zdarzenia związane z obsługa i kontrolą i inne zdarzenia lub sytuacje mające istotne znaczenie 5 dla zaistnienia zdarzenia wierzchołkowego. Technika drzew błędów, dzięki precyzyjnie zdefiniowanej logice formalnej oraz przejrzystej formie graficznej, znajduje szerokie zastosowanie w analizach bezpieczeństwa PSA. Właściwie użyta stanowi wygodne narzędzie pozwalające na analizę dużych i złożonych systemów w sposób systematyczny i uporządkowany. W niektórych krajach drzewa błędów stanowią przyjętą formę prezentowania w sposób bardziej sformalizowany różnych istotnych informacji dotyczących bezpieczeństwa obiektu (np. dla wykazania, że rozwiązania technicznoproceduralne zapewniają wystarczającą niezależność określonych systemów lub urządzeń). Bardzo ważną sferą zastosowań są różnego rodzaju analizy jakościowe zmierzające do uzyskania istotnych informacji o potencjalnych możliwościach wystąpienia różnych sytuacji awaryjnych. Technika ta pozwala na identyfikację szeregu realnych sytuacji awaryjnych, stanowiących kombinację stosunkowo prawdopodobnych zdarzeń, które pojedynczo nie stanowią zagrożenia, natomiast w koincydencji z innymi mogą spowodować skutki groźniejsze niż "duże" awarie (tzw. awarie projektowe). W wyniku tych analiz uzyskuje się ponadto informacje o niedoskonałościach systemu (np. niepożądanych współzależnościach pomiędzy jego składowymi), a także o środkach pozwalających poprawić bezpieczeństwo obiektu (np. modyfikacjach o charakterze projektowym lub proceduralnym). Analizy jakościowe są integralną częścią tzw. analiz ryzyka, w których dokonuje się kwantyfikacji opracowanych modeli logicznych w celu określenia wskaźników ilościowych charakteryzujących prawdopodobieństwa określonych sytuacji awaryjnych. W analizach bezpieczeństwa obiektów jądrowych technika drzew błędów jest stosowana w powiązaniu z techniką drzew zdarzeń. W tym przypadku zdarzenia wierzchołkowe odpowiadają zdarzeniom zdefiniowanym w kategoriach niewykonania określonych zadań funkcjonalnych przez poszczególne systemy, których działanie decyduje o przebiegu awarii. Określenie, kiedy zadanie funkcjonalne systemu uważa się za spełnione pomyślnie, oparte jest o ilościowe wymagania precyzujące warunki działania systemu (tzw. kryteria pomyślnego wykonania zadań), często zależne od sytuacji awaryjnej (określonej przez ciąg zdarzeń poprzedzających działanie systemu). W związku z tym dla danego systemu może zajść potrzeba opracowania kilku drzew błędów o zdarzeniach wierzchołkowych odpowiadających różnym sytuacjom awaryjnym (lub jak często przyjęło się określać, drzewa o kilku zdarzeniach wierzchołkowych). Drzewa błędów opracowywane są dla wszystkich systemów pierwszoplanowych i wspierających, istotnych dla przebiegu awarii. Przy analizie poszczególnych sytuacji awaryjnych są one łączone przy użyciu odpowiednich operatorów logicznych w jedno duże drzewo, którego zdarzeniem wierzchołkowym jest wystąpienie określonej sytuacji awaryjnej. Pozostałe systemy (wspierające) są uwzględniane przez dołączenie odpowiednich drzew błędów tych systemów do drzew systemów pierwszoplanowych. Analiza jakościowa i ilościowa takich złożonych drzew błędów jest wykonywana przy użyciu odpowiednich programów komputerowych. Również szereg czynności związanych z przygotowaniem problemu, w tym scalenie poszczególnych drzew systemowych, identyfikacja niezależnych gałęzi, drzew itp., może być zautomatyzowana. Analiza jakościowa polega na znalezieniu podstawowych kombinacji zdarzeń, przy których następuje zdarzenie wierzchołkowe (tzw. zbioru minimalnych przekrojów drzewa). W ramach analiz ilościowych przeprowadza się kwantyfikację zdarzeń, określając kolejno prawdopodobieństwa zdarzeń 6 pierwotnych, poszczególnych przekrojów oraz zdarzenia wierzchołkowego. Bardzo ważnym etapem analiz jest analiza niepewności polegająca na propagacji, poprzez opracowany model logiczny, rozkładów prawdopodobieństw wskaźników charakteryzujących zdarzenia pierwotne. 3. OGÓLNE WYMAGANIA DOTYCZĄCE DRZEW BŁĘDÓW DLA ANALIZ RYZYKA EJ Jak wspomniano wyżej systemowe drzewa błędów są podstawowymi elementami logicznego modelu EJ stosowanego w analizach ryzyka PSA, a czynność konstruowania odpowiednich drzew dla wszystkich systemów istotnych z punktu widzenia bezpieczeństwa, jest bardzo ważnym i odpowiedzialnym etapem analiz. W przypadku dużych i złożonych modeli z jakimi ma się do czynienia przy analizie ciągów awaryjnych EJ, poszczególne części modelu (drzewa błędów dla określonych systemów) są konstruowane niezależnie przez różnych wykonawców, a następnie scalane w odpowiedni sposób dla wykonania analiz określonych sytuacji awaryjnych. Postępowanie takie jest uzasadnione dążeniem do sensownego ograniczenia czasu realizacji zadania przy dość znacznej pracochłonności wykonania modelu PSA. Ma również pewien związek z branżową specyfiką określonych systemów EJ. Opracowywanie systemowych drzew błędów w takim trybie wymaga wielkiej staranności i uwagi od wszystkich uczestników prac, a także właściwych działań koordynacyjnych we wszystkich fazach realizacji modelu. Najbardziej ogólne wymagania jakim powinny odpowiadać poszczególne części modelu, aby zapewnić prawidłowe i sprawne przeprowadzenie analiz PSA, są następujące: • Zarówno drzewa błędów dla poszczególnych systemów jak i drzewa uzyskane ze scalenia kilku drzew systemowych muszą być poprawne pod względem logicznym i formalnym. • Struktura logiczna i sposób przedstawienia drzew błędów powinien być maksymalnie prosty i przejrzysty dla ułatwienia analizy i weryfikacji modelu, a także w dużym stopniu elastyczny z punktu widzenia ewentualnych modyfikacji czy rozszerzania modelu. • Format stosowany przy sporządzaniu dokumentacji drzew błędów powinien być zgodny z użytym modelem komputerowym. Przytoczone wyżej ogólne wymagania mogą być sprecyzowane nieco bardziej szczegółowo. Omówienia wymaga przede wszystkim sprawa logicznej i formalnej poprawności drzew błędów. Należy wymienić tu kilka ważnych kwestii, jak np. identyfikacja i poprawne wprowadzenie do modelu wszystkich zdarzeń zależnych, uniknięcie logicznych pętli w drzewie powstałym ze skojarzenia kilku systemowych drzew błędów, niedopuszczenie do przypadkowego pokrywania się nazw dla kilku różnych zdarzeń, a także zachowania identyczności nazw odnoszących się do tych samych zdarzeń w różnych częściach modelu. Wymagania dotyczące sposobu przedstawienia systemowych drzew błędów dotyczą zarówno zakresu informacji składających się na opis drzew błędów jak i formatu stosowanego przy sporządzaniu odpowiedniej dokumentacji. Odpowiedni zakres i sposób przedstawienia informacji dla poszczególnych drzew systemowych może ułatwić weryfikację i scalanie modelu. Precyzyjny i konsekwentnie stosowany format, na który składają się odpowiednie znaki graficzne oraz system nazewnictwa zdarzeń, a także jednoznaczne zasady podziału 7 drzewa na moduły, ma istotne znaczenie we wszystkich etapach analiz począwszy od identyfikacji błędów logicznych, a skończywszy na rozszerzaniu czy modyfikacjach modelu. Format ten powinien zapewnić odpowiednią przejrzystość i czytelność modelu. Dostosowanie formatu do komputerowej obróbki drzew jest związane z wymaganiami maszyny cyfrowej oraz programu, który ma być użyty dla przeprowadzenia analiz jakościowych i ilościowych. Ograniczenia mogą dotyczyć możliwych typów operatorów logicznych (bramek) oraz liczby znaków stosowanych w nazwach zdarzeń. Szczegółowe informacje dotyczące formatu będą podane w rozdziale 5. 4. PODSTAWOWE POJĘCIA I ELEMENTY METODOLOGICZNE W niniejszym rozdziale podano niektóre podstawowe pojęcia używane w analizie systemów oraz zamieszczono pewne podstawowe wskazania przydatne przy konstruowaniu drzew błędów. Bardziej wyczerpujące informacje z tej dziedziny znaleźć można w pracach monograficznych [1-7], a także wcześniejszych opracowaniach dotyczących metodyki PSA [816]. 4.1. System jako podmiot analizy Określenie systemu stosowane w analizie systemowej ma bardzo szerokie znaczenie i zależy w dużym stopniu od kontekstu prowadzonych analiz. Bardzo ogólna definicja systemu, określa system jako "deterministyczną całość utworzoną przez zbiór współdziałających ze sobą dyskretnych elementów". Ważnym sformułowaniem w powyższej definicji jest deterministyczny charakter systemu implikujący identyfikowalność systemu i jego części składowych oraz fakt współdziałania części składowych systemu w celu wykonania określonych funkcji. W praktycznych analizach pojęcia systemu i jego dyskretnych elementów mają charakter względny i zależą od szczegółowości oraz charakteru prowadzonych analiz. W zależności od potrzeb dyskretne elementy same mogą być rozpatrywane jako systemy. Definicja systemu może zależeć od wyboru zasadniczych aspektów funkcjonowania systemu. Istotne znaczenie może mieć na przykład fakt, czy przedmiotem zainteresowania jest pomyślne wykonanie przez system określonego zadania funkcjonalnego, czy wystąpienie pewnej szczególnej sytuacji awaryjnej. Definicja systemu jest nierozerwalnie związana z przyjęciem zewnętrznych granic systemu zarówno fizycznych jak i czasowych. Granice te określają oddziaływanie systemu na otoczenie i oddziaływanie otoczenia na system. Określenie granic systemu zależy w dużej mierze od aspektów zainteresowania danej analizy, przesądzając równocześnie o tym jak wnikliwa i wyczerpująca jest ta analiza. Ważną kwestią przy definiowaniu systemu jest określenie wewnętrznych granic systemu precyzujących szczegółowość podziału systemu na części składowe oraz zakres powiązań i oddziaływali wewnątrz systemu. Związki funkcjonalne pomiędzy częściami składowymi systemu mogą być bardzo różne, niekiedy bardzo złożone. W pewnych przypadkach są to 8 programy, procedury postępowania czy zasady organizacyjne. Istotny wpływ na sposób określenia wewnętrznych i zewnętrznych granic systemu mogą mieć względy praktyczne związane z ograniczeniem pracochłonności analiz oraz dostępnością danych probabilistycznych dotyczących różnych komponentów systemu. Względy te nierzadko przesądzają o określeniu systemu oraz definicji części składowych systemu. Komponentem systemu przyjęto nazywać niepodzielny zespół połączonych ze sobą części, składających się na identyfikowalne urządzenie, przyrząd lub element wyposażenia o określonym przeznaczeniu funkcjonalnym i definiowalnych charakterystykach. Pożądaną w praktyce cechą komponentu jest możliwość odłączenia, demontażu lub wymiany go w całości, a także przeprowadzenia niezależnej próby komponentu. W praktycznych analizach systemów dla określenia części składowych systemu przyjęto używać pojęcia podsystemu jako zespołu pośredniego w strukturze hierarchicznej pomiędzy systemem i komponentem. Pojęcia system, podsystem i komponent są używane dość elastycznie umożliwiając wprowadzenie pewnej hierarchii i ułatwiający określenie granic systemu. W praktyce podział systemów na podsystemy i komponenty jest w pewnym stopniu uzależniony od dostępnych banków dostarczających dane o profilu niezawodnościowym. Zasady klasyfikacji urządzeń czy elementów wyposażenia zastosowane w takich bankach mogą zadecydować o sposobie podziału systemu w konkretnych analizach. Z takich względów na przykład, definicja pompy może być rozszerzona na cały zespół, obejmujący pompę, silnik napędowy czy nawet układ sterujący. W analizach systemów wygodnie jest wprowadzić podział komponentów na dwa typy: bierne i czynne. Komponenty bierne spełniają w systemie zadania mniej lub bardziej statyczne. Komponenty takie mogą przekazywać energię czy czynnik roboczy z jednego miejsca w drugie (np. kabel elektryczny lub rurociąg parowy) lub przenosić obciążenia (np. konstrukcja wsporcza, naczynie ciśnieniowe). Komponenty czynne pełnią w systemie funkcje dynamiczne zmieniając w określony sposób zachowanie się systemu. Przykładem może być zawór, który przez otwarcie lub zamknięcie zmienia przepływ czynnika w systemie lub wyłącznik działający w podobny sposób w obwodzie elektrycznym. Komponent bierny może być rozpatrywany jako przekaźnik "sygnału", natomiast komponent czynny jako generator lub przetwornik "sygnału". Fizyczne znaczenie użytego tu pojęcia sygnał może być bardzo różne (np. prąd elektryczny lub siła). Definicje przytoczone wyżej dotyczą zwykle głównej funkcji spełnianej przez komponent. W szeregu przypadków czynny komponent może być rozpatrywany jako bierny (np. zamknięty zawór jako jeden z elementów przegrody ciśnieniowej). 4.2. Określenie zdarzeń Zdarzenia występujące w analizie systemowej mogą być zaliczone do trzech zasadniczych grup: • zdarzenia związane z nieprawidłowym funkcjonowaniem komponentów lub systemów, • zdarzenia związane z przeprowadzaniem prac konserwacyjno-remontowych oraz 9 • kontroli systemów i urządzeń, zdarzenia związane z zachowaniem eksploatacyjnego. się obsługi operatorskiej i personelu Zdarzenia pierwszej grupy obejmują całą gamę różnego rodzaju uszkodzeń i nieprawidłowości działania urządzeń wyposażenia. Warto w tym miejscu podkreślić, że w odniesieniu do określonego komponentu wadliwe funkcjonowanie może być spowodowane albo przez uszkodzenie danego komponentu albo przez nieprawidłowość zaistniałą na wyższym poziomie, jak brak sygnału, brak zasilania, niedostateczne chłodzenie itp. Nieprawidłowości te mogą być wywołane przez uszkodzenia innych komponentów (lub systemów), powiązanych funkcjonalnie z danym komponentem lub przez błędy personelu. Pojęcie nieprawidłowości funkcjonowania komponentu jest więc ogólniejsze niż pojęcie uszkodzenia komponentu 1 . W odniesieniu do uszkodzeń rozróżnia się czasem tzw. uszkodzenia pierwotne oraz wtórne, uszkodzenia pierwotne są uszkodzeniami, które nastąpiły w warunkach środowiskowych zgodnych z projektowymi. Są to więc uszkodzenia przypadkowe, spowodowane wadami materiałowymi i wykonawczymi, normalnym zużyciem, korozją itp. Uszkodzenia wtórne są uszkodzeniami, które zostały spowodowane w warunkach środowiskowych nie mieszczących się w granicach projektowych, np. przekroczeniem dopuszczalnych temperatur lub ciśnienia, nadmiernymi obciążeniami mechanicznymi itp. Uszkodzenia komponentu (systemu) są często klasyfikowane z punktu widzenia zadań funkcjonalnych. Klasyfikacja ta ma również związek z podziałem komponentów na czynne i bierne, a także ze stosowanymi modelami uszkodzeń. Wyróżnia się następujące grupy uszkodzeń: • Uszkodzenia polegające na niewypełnieniu zadania funkcjonalnego typu "działania na żądanie". Uszkodzenia te dotyczą komponentów czynnych pełniących w systemie funkcje dynamiczne. Przykładem takiego uszkodzenia może być nie otwarcie się zaworu zdalnie sterowanego na sygnał lub nie uruchomienie silnika napędowego pompy na sygnał itp. W odniesieniu do tych uszkodzeń stosowany jest z reguły dyskretny model uszkodzeń, w którym wystąpienie uszkodzenia jest uzależnione od liczby włączeń lub uruchomień komponentu. • Uszkodzenia w czasie wykonywania zadania funkcjonalnego. Uszkodzenia te dotyczą komponentów wykonujących swe funkcje przez określony okres czasu, zarówno czynnych jak i biernych. Przykładem, takiego uszkodzenia jest przerwanie działania pracującej pompy przed upływem czasu potrzebnego na wykonanie określonego zadania (komponent aktywny) lub rozszczelnienie normalnie zamkniętego zaworu przed upływem czasu potrzebnego przez system na wykonanie określonego zadania (komponent spieniający funkcję bierną). W odniesieniu do tych uszkodzeń stosowany jest z reguły ciągły (czasowy) model uszkodzeń, w którym wystąpienie uszkodzenia jest uzależnione od czasu pracy komponentu w warunkach sprzyjających powstaniu takiego uszkodzenia • Uszkodzenia w czasie oczekiwania na działanie. Do grupy tej zaliczane są uszkodzenia komponentów aktywnych dotyczące ich "działania na żądanie", które nastąpiły w okresie oczekiwania na takie działanie. Uszkodzenia te z reguły pozostają niewykryte do momentu próby uruchomienia lub włączenia komponentu. Przykładem może być uszkodzenie siłownika zaworu, oczekującego w stanie zamkniętym na sygnał otwarcia, 1 termin nieprawidłowe lub wadliwe funkcjonowanie stosowany jest w niniejszej pracy dla określenia zdarzenia polegającego na niewykonaniu przez element (urządzenie, system) określonego zadania funkcjonalnego. W odniesieniu do takiego zdarzenia używany jest często, zadaniem autorów niezbyt zręczny, termin "niezadziałanie". 10 uniemożliwiające wykonanie tego zadania we właściwym momencie. W odniesieniu do tych uszkodzeń stosuje się czasowy (ciągły) model uszkodzeń. Istotne dla właściwego określenia współzależności pomiędzy różnymi zdarzeniami są pojęcia skutków uszkodzenia, sposobu uszkodzenia oraz efektów uszkodzenia. Przy określaniu skutków uszkodzenia przedmiotem zainteresowania jest wpływ określonego uszkodzenia lub nieprawidłowości działania komponentu na system. Pojęcie sposób uszkodzenia precyzuje dokładniej jakie aspekty uszkodzenia są przedmiotem zainteresowania. Natomiast mechanizm uszkodzenia koncentruje się na przyczynach i okolicznościach określonego uszkodzenia. Należy podkreślić, że podobnie jak pojęcia systemu, podsystemu i komponentu również pojęcia skutków, sposobów i mechanizmów uszkodzenia mają charakter relatywny. Określone zdarzenie może stanowić skutek w odniesieniu do komponentu, sposób w odniesieniu do podsystemu i mechanizm w stosunku do systemu. Typowym przykładem jest niezadziałanie zaworu spowodowane uszkodzeniem siłownika zaworu, W odniesieniu do komponentu (siłownika) niezadziałanie zaworu jest skutkiem uszkodzenia. Dla podsystemu (zawór z siłownikiem) niezadziałanie zaworu jest sposobem uszkodzenia. W stosunku do systemu, w skład którego wchodzi zawór, wadliwe funkcjonowanie zaworu stanowi określenie mechanizmu uszkodzenia systemu. Następną ważną grupą zdarzeń odgrywających istotną rolę przy konstruowaniu drzew błędów systemów EJ są zdarzenia związane z przeprowadzeniem czynności konserwacyjnoremontowych oraz kontroli urządzeń czy systemów. W wielu przypadkach czynności te powodują wyłączenie z ruchu jednego z kilku redundancyjnych ciągów technologicznych lub urządzeń. Zdarzenia te mają więc istotny związek z niedyspozycyjnością systemu i możliwością zaistnienia określonego zdarzenia wierzchołkowego, stanowiąc ważny element w strukturze logicznej drzewa. Wymienione wyżej czynności mogą mieć charakter planowany (obsługa okresowa o charakterze prewencyjnym) lub nieplanowany (usuwanie skutków nieprzewidzianych uszkodzeń). Przykładowym określeniem zdarzenia tego typu może być wyłączenie z pracy jednego z trzech redundancyjnych torów kontrolno-pomiarowych dla przeprowadzenia okresowych prób funkcjonalnych i kalibracji aparatury lub wyłączenie z ruchu jednej z trzech redundancyjnych linii systemu awaryjnego chłodzenia rdzenia w związku z usuwaniem skutków nieprzewidzianej awarii pompy. W odniesieniu do zdarzeń tego typu stosuje się zwykle czasowy model zdarzenia, w którym wystąpienie zdarzenia jest uzależnione od częstotliwości przeprowadzania określonych czynności oraz czasu trwania prac. Czynności konserwacyjno-remontowe oraz kontrola urządzeń są zwykle dokonywane równocześnie dla całej linii czy podsystemu, a nie dla pojedynczych komponentów. Pominięcie tego faktu przy ustalaniu logicznej struktury drzewa może wpłynąć na niepotrzebne skomplikowanie i rozbudowanie drzewa. Zdarzenia trzeciej z wymienionych na wstępie grup, związane z zachowaniem się obsługi operatorskiej i personelu eksploatacyjnego, mają bardzo istotne znaczenie w analizach systemów. Wiąże się to ze stosunkowo dużym wkładem ilościowym jaki zwykle wnoszą różnego rodzaju błędy ludzkie w całkowitą niedyspozycyjność systemu. Potencjalne źródła błędów ludzkich istnieją we wszystkich możliwych stanach funkcjonowania systemu począwszy od działań operatorskich związanych z normalną eksploatacją, czynnościach personelu konserwacyjno-remontowego i kontroli eksploatacyjnej, a skończywszy na 11 działaniach operatorskich w sytuacjach awaryjnych. Wpływ błędów popełnianych przez personel ludzki powinien być uwzględniany we wszystkich przypadkach, w których rozwiązania techniczne pozostawiają możliwość nieprawidłowego działania człowieka, zarówno braku określonego działania w sytuacji wymagającej działania, jak i podjęcia nieprawidłowych działań. Przykładami typowych błędów ludzkich jakie uwzględnia się w drzewach zdarzeń mogą być takie zdarzenia jak pozostawienie zaworu w niewłaściwej pozycji po zakończeniu prac konserwacyjnych, niesprawność toru kontrolno-pomiarowego po niewłaściwie przeprowadzonej kalibracji aparatury, itp. Omawiając podstawowe pojęcia związane z definiowaniem zdarzeń, mających stanowić elementy drzewa błędów, należy zwrócić uwagę na tzw. zdarzenia zależne. Wykrycie i poprawne wprowadzenie do modelu wszystkich współzależności pomiędzy zdarzeniami ma wielkie znaczenie z punktu widzenia poprawność i analiz. Jak wiadomo, współzależności te mogą mieć różne podłoże i różny charakter. Pewna część współzależności wynika z powiązań funkcjonalnych komponentów wchodzących w skład systemu z innymi systemami (np. systemami sterowania, zasilania w energię lub w media robocze). Te współzależności powinny być modelowane w sposób jawny przez wprowadzenie do modelu odpowiednich zdarzeń określających wszystkie czynniki wspólne dla kilku systemów lub ich komponentów. W sposób jawny mogą być również modelowane inne współzależności, w których wspólny element związany jest z wpływem czynników zewnętrznych (np. środowiskowych), obsługą eksploatacyjną (np. czynności konserwacyjne charakteryzujące się wspólnym elementem czasowym i ludzkim) czy nawet technologią procesu produkcji (np. błędy materiałowe w całej serii produkcyjnej). Ze względu na brak informacji ilościowych wiele uwarunkowań tego typu modeluje się jednak w sposób przybliżony nie wchodząc szczegółowo we wszystkie źródła i mechanizmy powiązań. Niezależnie od przyjętego modelu opisującego zdarzenia zależne, istotne jest, aby przy konstruowaniu drzew błędów wszystkie możliwe współzależności były wzięte pod uwagę. Prawidłowe wprowadzenie takich współzależności pozwala na uzyskanie rezultatów o praktycznym znaczeniu, nawet jeśli dane probabilistyczne dotyczące współzależności są niewystarczające. Istotne znaczenie mają w takich przypadkach różnego rodzaju analizy czułości i analizy niepewności. 4.3. Elementy logiczne drzewa błędów Jak wspomniano wyżej, drzewo błędów dla systemu jest schematem określającym związki logiczne pomiędzy zdarzeniami dotyczącymi interesujących aspektów zachowania się systemu oraz jego części składowych. Z formalnego matematycznego punktu widzenia drzewo błędów jest niecyklicznym grafem skierowanym, określonym na zbiorze węzłów i zbiorze krawędzi, w którym każda para węzłów może być połączona przez co najwyżej jedną krawędź. W strukturze tej węzły reprezentują zdarzenia, a krawędzie związki logiczne pomiędzy określonymi zdarzeniami. 12 Węzły niemające krawędzi wejściowych noszą nazwę węzłów bazowych podstawowych, a odpowiadające im zdarzenia nazywane będą zdarzeniami elementarnymi, Węzły, które mają jedną lub kilka krawędzi wejściowych noszą nazwę bramek, a odpowiadające im zdarzenia nazywane będą zdarzeniami pośrednimi. Węzły, które nie mają krawędzi wyjściowych nazywane są węzłami wierzchołkowymi, a odpowiadające im zdarzenia - zdarzeniami wierzchołkowymi. Powyższa klasyfikacja zdarzeń jest wyłączenie związana z logiczną strukturą drzewa. Klasyfikacja zdarzeń związana z funkcjonalnymi cechami systemu omawiana w punkcie poprzednim jest w zasadzie niezależna. Bramki logiczne stosowane w drzewach błędów są zróżnicowane w zależności od typu związku logicznego pomiędzy zdarzeniem jakie reprezentuje dana bramka oraz zdarzeniami stanowiącymi wejścia do danej bramki (zdarzeniami niższymi w strukturze drzewa). W praktyce używane są odpowiednie symbole graficzne określające typ bramki. Przy konstruowaniu drzew błędów stosuje się kilka rodzajów bramek logicznych, jednak tylko dwie z nich mają charakter podstawowy, pozostałe są ich odmianami. Bramki te są wiernymi odpowiednikami operatorów logicznych stosowanych w algebrze boolowskiej - bramka "LUB" (odpowiednik operatora "alternatywa") oraz bramka "I" (odpowiednik operatora "koniunkcji"). W przypadku bramki "LUB" zdarzenie określone przez bramkę zachodzi wtedy, gdy ma miejsce jedno lub więcej zdarzeń stanowiących wejścia do bramki. Dla bramki reprezentującej zdarzenie Q z dwoma wejściami A,B bramka "LUB" odpowiada wyrażeniu boolowskiemu Q A B. W przypadku bramki "I" zdarzenie określone przez bramkę zachodzi wtedy, gdy jednocześnie wystąpią wszystkie zdarzenia stanowiące wejścia do bramki. Dla bramki reprezentujące zdarzenie Q z dwoma wejściami A i B bramka "I" odpowiada wyrażeniu boolowskiemu Q A B. Inne rodzaje bramek stosowane w praktycznych zastosowaniach drzew błędów wymienione zostały w dalszej części opracowania. Należy podkreślić, że powiązanie zdarzeń przez bramki logiczne wyraża istnienie określonych relacji przyczynowych pomiędzy zdarzeniami. Powiązania te nie definiują żadnych relacji czasowych, innych niż wynikają z logicznego wymagania, aby określone zdarzenie warunkujące określoną sytuację, nastąpiło wcześniej niż sytuacja ta będzie mogła mieć miejsce. 4.4. Podstawowe zasady konstruowania drzew błędów Jak wspomniano wyżej konstruowanie drzewa błędów dla systemu musi być poprzedzone ustaleniem niezbędnych informacji i starannie przemyślanych założeń wyjściowych, niezbędne jest określenie wszystkich interesujących aspektów funkcjonowania systemu i zdefiniowanie granic zewnętrznych i wewnętrznych systemu, a następnie sprecyzowanie zdarzenia wierzchołkowego (w niektórych przypadkach zdarzeń tych może być kilka). Założenia dotyczące zdarzeń wierzchołkowych powinny być wynikiem wcześniejszych analiz koncentrujących się na określeniu możliwych ciągów awaryjnych. Przy konstruowaniu drzewa błędów stosuje się kilka praktycznych zasad i zaleceń ułatwiających poprawne przeprowadzenie analiz. Podstawową metodą stosowaną przy 13 budowie drzewa jest wieloetapowy, sekwencyjny sposób analizowania związków przyczynowych określany jako zasada bezpośredniej przyczyny. Polega ona na określeniu wszystkich bezpośrednich koniecznych i dostatecznych przyczyn zajścia określonego zdarzenia. Zasada ta jest stosowana systematycznie, najpierw w odniesieniu do zdarzenia wierzchołkowego, a następnie do każdego z ustalonych wcześniej zdarzeń pośrednich. Zasadniczą ideą takiego etapowego prowadzenia analiz jest dążenie co zachowania kompletności zdarzeń. Zawężenie analizy do poszukiwania bezpośrednich przyczyn określonego zdarzenia, rozważanego na danym etapie, bardzo ułatwia osiągnięcie tego celu. Stosowanie tej prostej i naturalnej zasady wymaga, aby każde z analizowanych zdarzeń wierzchołkowych, właściwych dla danego etapu rozważań, było zdefiniowane precyzyjnie w kategoriach nieprawidłowego funkcjonowania systemu lub jego części składowej. Określenie to powinno sformułować o jaką nieprawidłowość działania chodzi i kiedy ona występuje. Przykładem takiego określenia mogą być zdarzenia: "Silnik elektryczny nie został uruchomiony po włączeniu zasilania" lub "normalnie zamknięte styki wyzwalacza nie zostały rozwarte po przerwaniu zasilania cewki niskonapięciowej". Przy dobieraniu odpowiedniego sformułowania nadrzędną zasadą powinno być jasne i wyczerpujące określenie zdarzenia, a nie dążenie do zwięzłości opisu przez zmniejszenie zakresu niezbędnych informacji. Następną praktyczną zasadą ułatwiającą stosowanie reguły bezpośredniej przyczyny jest rozpatrywanie przyczyn nieprawidłowego funkcjonowania, analizowanego w danym etapie, w kategoriach przyczyn związanych z uszkodzeniem określonego komponentu lub przyczyn zewnętrznych w stosunku do tego komponentu (systemowych). Takie rozumowanie pozwala na wyodrębnienie dwóch zasadniczych gałęzi drzewa. Pierwsza związana z uszkodzeniami danego komponentu, może być zakończona bramką "LUB" z pewną liczbą zdarzeń wejściowych typu podstawowego, które określają różne rodzaje uszkodzeń komponentu. Druga, analizująca przyczyny zewnętrzne mające charakter nieprawidłowości "sygnału" (zasilania, sygnałów sterujących, dopływu medium roboczego itp.), może być kontynuowana w opisany wyżej sposób. Jeżeli propagacja określonego ciągu zdarzeń prowadzących do nieprawidłowego działania systemu może być przerwana przez niespodziewane i mało prawdopodobne uszkodzenie któregoś z komponentów, to zakłada się z reguły, że takie uszkodzenie nie występuje. Pozwala to wyeliminować mało znaczące ciągi zdarzeń już na etapie konstruowania drzewa. Przykładem takiej sytuacji może być analiza systemu zabezpieczeń reaktora związana z niewykonaniem funkcji zabezpieczających, W analizie takiej należy pominąć wszystkie uszkodzenia komponentów systemu, których skutkiem jest wygenerowanie sygnału zrzutu podzespołów regulacyjnych, np. przez uszkodzenie styków w module logicznym powodujące powstanie sygnału wyzwalającego, niezależnie od sygnału przesyłanego przez tor kontrolnopomiarowy. Dwa dalsze zalecenia o charakterze porządkowym mają na celu zmniejszenie możliwości popełnienia błędów logicznych przez niewłaściwy opis zdarzeń przeanalizowanych we wcześniejszych etapach analizy drzewa. Pierwszym z nich jest zasada kompletnego określenia wszystkich zdarzeń stanowiących wejścia do określonej bramki przed rozpoczęciem dalszej analizy któregoś z tych zdarzeń. Drugie z zaleceń dotyczy opisu zdarzeń pośrednich. Zaleca się, aby wszystkie bramki miały właściwie opisane odpowiadające im zdarzenia zdefiniowane w kategoriach nieprawidłowości funkcjonowania. Bezpośrednie łączenie bramek może prowadzić do niewłaściwego zrozumienia logiki drzewa i omyłek przy prowadzeniu dalszej analizy. 14 Podane wyżej zasady i zalecenia mają charakter ogólny i stosują się do bardzo szerokiej klasy systemów. Pewne wskazania metodyczne wynikać mogą z określonych cech analizowanych systemów. Uwagi dotyczące konstruowania drzew błędów dla potrzeb PSA, wynikające ze specyficznych cech systemów EJ, znaleźć można w dalszej części opracowania. 5. ZALECENIA DOTYCZĄCE FORMATU DRZEW BŁĘDÓW 5.1. Graficzna reprezentacja drzew błędów Graficzna reprezentacja stanowi pierwotną i najczęściej stosowaną formę przedstawienia drzewa błędów. Podstawowe zasady przyjęte w literaturze zagranicznej i krajowej przy graficznym zapisie drzewa nie zawsze są jednolite. Różnice dotyczą zarówno stosowanych symboli i sposobu oznaczeń, jak również niektórych zasad o charakterze porządkowym. I tak na przykład, symbole bramek stosowane w literaturze niemieckiej różnią się od symboli stosowanych w krajach anglosaskich, w organizacjach, podległych Kanadyjskiej Komisji Energii Atomowej (AECB) zalecana była pozioma orientacja drzewa [11-12], itp. Zasady dotyczące graficznego przedstawienia drzew błędów przedstawione w niniejszym opracowaniu są kwintesencją zasad stosowanych już w praktyce przez firmy energetyczne i organizacje naukowe wykonujące analizy PSA. W dużej mierze zasady te opierają się o bogatą praktykę stosowaną w Stanach Zjednoczonych, która w dziedzinie energetyki jądrowej została zapoczątkowana przez znane opracowanie "Reactor Risk Study" [13]. Przyjęte zasady i konwencje zostały zaadaptowane i są stonowane aktualnie w wielu innych krajach. Pewne elementy formatu zaczerpnięte zostały ponadto z innych opracowań, miedzy innymi z zaleceń Kanadyjskiej Komisji Energii Atomowej [12]. 5.1.1. Symbole graficzne Symbole graficzne stosowane przy opracowywaniu drzew błędów składają się z kilku elementów, pokazanych w sposób ogólny na rys. 1. Rys. 1. Sposób opisu zdarzeń w drzewach uszkodzeń. 15 a - określenie zdarzenia zawierające definicję słowną oraz nazwo kodową, b - odpowiedni symbol graficzny określający typ zdarzenia pośredniego (bramki) lub elementarnego, c - linie określające wejścia do bramki (gdy symbol określający typ zdarzenia jest bramką), d - symbol przeniesienia stosowany wtedy ,gdy określone zdarzenie występuje powtórnie w innym miejscu drzewa. Prostokąt oznaczony na rysunku literą "a" zawiera opis zdarzenia. Symbol ten stosowany jest zawsze niezależnie od typu zdarzenia. Opis zdarzenia składa się zwykle z definicji słownej oraz nazwy kodowej. Sposób tworzenia nazw kodowych opisany został w pkt. 5.1.2. W pewnych przypadkach kodowa nazwa zdarzenia może być umieszczana poza obrysem prostokąta. Bezpośrednio pod tym symbolem należy umieścić symbol graficzny oznaczony na rysunku literą "b", określająca typ zdarzenia. Symbol ten powinien, być zgodny z zestawieniem symboli podanym w tabeli 1. Jeżeli opisywane zdarzenie jest zdarzeniem pośrednim symbol "b" jest symbolem bramki logicznej z zaznaczonymi wejściami (c) połączonymi z prostokątami (a) zawierającymi opis odpowiednich zdarzeń na niższym poziomie drzewa. Zalecane typy bramek logicznych i ich symbole podane zostały w tabeli 1. W niektórych przypadkach zdarzenie pośrednie może być oznaczone symbolem przeniesienia umieszczonym analogicznie do symbolu bramki (pozycja b). Symbol ten określany jako symbol "przeniesienia do" jest używany ze względów praktycznych dla uzyskania zwartej struktury drzewa. Jednym z ważnych zastosowań jest przypadek, gdy określone zdarzenie pośrednie występuje w drzewie kilkakrotnie. W takim przypadku cześć drzewa określająca to zdarzenie powinna występować tylko w jednym miejscu drzewa. W miejscu tym należy umieścić przy prostokącie zawierającym opis zdarzenia (a) symbol "przeniesienia z" (oznaczony na rys. 1 literą "d"), a w pozostałych miejscach symbole "przeniesienia do" (umieszczone na pozycji b). Symbole przeniesienia mogą być również używane do podziału dużych drzew na kilka mniejszych części. Jest to zalecane ze względów czysto praktycznych związanych z ograniczonym formatem stron, dążeniem do zachowania odpowiedniej przejrzystości itp. W przypadku, gdy opisywane zdarzenie jest zdarzeniem elementarnym stosuje się symbole określające precyzyjniej charakter zdarzenia. Podstawowym typem zdarzenia elementarnego jest tzw. zdarzenie pierwotne mające charakter uszkodzenia lub nieprawidłowości i które przy założonej szczegółowości analiz nie musi być dalej rozwijane. Zdarzenia te mają dwie charakterystyczne cechy mogą być zdefiniowane w inny sposób niż przez drzewo błędów oraz nie są uzależnione od innych zdarzeń lub uwarunkowań, które wpływają równocześnie na inne zdarzenia występujące w drzewie. Ze względów praktycznych wyróżnia się także zdarzenia, które nie są dalej rozwijane, albo ze względu na małe znaczenie tego zdarzenia albo brak dostatecznych informacji, a także zdarzenia, które mogłyby być dalej rozwijane lub są rozwinięte gdzie indziej, ale w danym drzewie są traktowane jako zdarzenia elementarne. Stosowane jest również pojecie zdarzenia zewnętrznego odnoszącego się do zdarzeń, które zwykle, w normalnych warunkach, zachodzi. Odpowiednie symbole stosowane dla oznaczenia tych zdarzeń podane zostały w tabeli 1. Praktyczne zasady użycia odpowiednich symboli 16 graficznych zilustrowane zostały na rys.2. Rys.2. Przykładowy wybrany fragment drzewa błędów dla systemu awaryjnego chłodzenia rdzenia. 5.1.2. Kodowe nazwy zdarzeń Jak wspomniano w pkt. 5.1.1 kodowa nazwa zdarzenia stanowi jeden z elementów opisu zdarzenia. Przy wyborze tych nazw stosowane są odpowiednie systemy kodowania, które umożliwiają przekazanie szeregu istotnych informacji dotyczących opisywanego zdarzenia. Stosowanie właściwego systemu kodowania ułatwia prawidłowe opracowanie systemowych drzew zdarzeń, ich scalenie i weryfikację, oraz obróbkę komputerową, ma również istotny wpływ na przejrzystość i czytelność rezultatów analiz. System nazewnictwa zdarzeń powinien zapewnić jednoznaczną identyfikację każdego ze zdarzeń przy zachowaniu możliwie małej liczby znaków składających się na nazwę kodową. Ograniczenie długości nazwy jest związane z naturalnym dążeniem do zapewnienia jak największej czytelności zakodowanych informacji, kiedyś również wynikało z wymagań programów komputerowych stosowanych do obróbki drzew. Podobnie jak w znanych opracowaniach dotyczących PSA dla elektrowni jądrowych proponowana kodowa nazwa zdarzenia obejmuje dwie grupy informacji - określenie właściwego urządzenia lub elementu (komponentu), którego zdarzenie dotyczy oraz określenie charakteru zdarzenia (niesprawności lub błędu). Nazwa kodowa zawiera cztery człony identyfikacyjne, z których trzy pierwsze służą do jednoznacznego określenia komponentu. Proponowany format kodowej nazwy zdarzenia jest następujący: 17 Identyfikator systemu (2 znaki); Szczegółowy identyfikator komponentu (5 znaków); Identyfikator typu komponentu (2 znaki); Określenie charakteru zdarzenia (1 znak). Identyfikator systemu jest podstawową informacją pozwalająca przyporządkować określone zdarzenie do odpowiedniego drzewa błędów. Na ogół oznaczenie kodowe składa się z dwóch znaków literowych utworzonych z początkowych liter nazwy systemu. Ze względu na odmienny podział logiczny elektrowni na układy, utrzymanie całkowitej zgodności nie jest możliwe. Niezbędne było wprowadzenie szeregu nowych symboli dla oznaczenia systemów, które zawierały kilka układów technologicznych wyodrębnionych w dokumentacji projektowej. Starano się jednak zachować w oznaczeniach systemów pewne wspólne elementy ułatwiające właściwe skojarzenia przedmiotowe. Proponowane oznaczenia systemów przedstawione zostały w tabeli 2. Przedstawione zestawienie ogranicza się co systemów istotnych dla przebiegu awarii, ustalonych na podstawie wstępnych analiz jakościowych EJ. W miarę postępu prac może zajść potrzeba uzupełnienia powyższej listy systemów i odpowiadających im oznaczeń. Identyfikator komponentu łącznie z identyfikatorem systemu powinien jednoznacznie określić urządzenie lub element, którego dotyczy opisywane zdarzenie. W opracowaniach PSA za granicą, człon identyfikacyjny komponentu jest z reguły zbieżny z oznaczeniami stosowanymi na rysunkach i segmentach projektowych. Proponuje się więc, aby człon identyfikujący komponent składał się z 5 znaków zawierających 2-cyfrowy numer ciągu lub linii, symbol literowy okreś1ający typ komponentu oraz 2-cyfrowy numer porządkowy. Na przykład dla zaworu oznaczonego 1TQ22S01 człon identyfikujący komponent ma postać 22S01. W przypadkach, gdy odrzucenie symboli literowych oznaczających system może wprowadzić niejednoznaczność, symbol literowy określający typ komponentu powinien być zastąpiony przez znaczącą literę występującą w symbolu systemu. Na przykład dla komponentów występujących w drzewie błędów systemu przekazywania i przetwarzania energii o symbolu kodowym RS i oznaczonych w dokumentacji projektowej symbolami 1RA10S02 i 1RC10S022, proponuje się użyć jako człony identyfikujące komponent symbole 10A02 i 10C02. W odniesieniu do niektórych rozbudowanych i złożonych systemów (np. systemy elektryczne lub systemy sterowania) powyższy sposób ustalania członu identyfikującego komponent może być nieprzydatny lub niewystarczający dla jednoznacznego określenia komponentu, zwłaszcza przy analizach o znacznym stopniu szczegółowości. W tym przypadku dopuszcza się stosowanie dla określonego systemu odmiennych zasad kodowania, a ich ustalenie pozostawia się specjaliście opracowującym drzewa błędów tego systemu. W odniesieniu do systemów elektrycznych i systemów sterowania dopuszcza się zwiększenie długości identyfikatora komponentu do 6-ciu znaków przez zredukowanie identyfikatora systemu do jednego znaku E lub C. Identyfikator typu komponentu zawiera informacje o typie lub klasie urządzenia (elementu), spełniając równocześnie istotną rolę z punktu widzenia jednoznacznego określenia komponentu. Człon ten składa się na ogół z dwóch znaków alfanumerycznych. W opracowaniach dotyczących PSA symbol ten jest utworzony z początkowych liter w słownym określeniu typu 2 Przytoczony przykład jest przykładem abstrakcyjnym ilustrującym teoretyczne możliwości powstania niejednoznaczności symboli. 18 urządzenia (np. Control Rods-CR, Check Valves - CV, Piping - PI itp.). Ten sposób oznaczeń pozostawia znaczną przypadkowość i dowolność w doborze symboli, uniemożliwia wprowadzenie systematycznych elementów klasyfikacyjnych ograniczając szczegółowość podziału i z tych względów nie wydaje się godny naśladowania. Proponowany system oznaczeń rozróżnia podzespoły i urządzenia oraz elementy urządzeń. Utrzymany został podział wyposażenia na 6 grup wymienionych w tabeli 3, z których każda ma przyporządkowaną pierwszą literę oznaczenia. Kody oznaczeń dotyczących drugiej litery w poszczególnych typach urządzeń i podzespołów podane zostały w tabelach 4 - 8. Oznaczenia dotyczące elementów urządzeń są złożone również z dwóch liter, z których pierwsza określa jedną z trzech grup elementów, a druga precyzuje typ elementu. Ostatni człon w kodowej nazwie zdarzenia określający charakter zdarzenia zawiera jedynie zgrubne informacje, które mają ułatwić przegląd rezultatów analizy jakościowej drzew błędów na poziomie komponentów. Bardziej szczegółowe informacje są podawane niezależnie przy opisie drzew błędów i w zestawieniach zdarzeń elementarnych stanowiących część dokumentacji drzew (patrz rozdz. 6). Zestawienie odpowiednich oznaczeń kodowych podane zostało w tabeli 12. Przyjęte oznaczenia są zgodne z oznaczeniami stosowanymi w analizach PSA dla elektrowni Oconee. Przedstawiony sposób ustalania kodowych nazw zdarzeń powinien być stosowany do wszystkich zdarzeń, które mogą pojawić się w zbiorze minimalnych przekrojów drzewa (zdarzeń elementarnych). W odniesieniu do zdarzeń pośrednich (bramek) należy stosować uproszczony sposób opisu zdarzeń, w którym nazwa kodowa składa się z identyfikatora systemu oraz numeru porządkowego zdarzenia ustalonego przez specjalistę opracowującego drzewo błędów dla tego systemu. Przy odpowiednim symbolu przeniesienia, jeśli taki jest stosowany, należy umieszczać identyfikator utworzony z identyfikatora odpowiedniej bramki poprzedzonego literą T oznaczająca przeniesienie. W odniesieniu do zdarzeń pośrednich (bramek oraz zdarzeń oznaczonych symbolem przeniesienia) kodowa nazwa zdarzenia może być umieszczana poza obrysem prostokąta zawierającego opis zdarzenia. W tych przypadkach zaleca się, aby odpowiedni identyfikator umieszczony był po prawej stronie symbolu bramki lub symbolu przeniesienia. Zwiększa to przejrzystość zapisu, a także pozwala na zmniejszenie wymiarów prostokąta zawierającego często kilkuwyrazowy opis zdarzenia. Na rys. 2 przedstawiono fragment drzewa błędów dla systemu awaryjnego chłodzenia rdzenia wysokiego ciśnienia. Przykład ten ilustruje przedstawione wyżej zasady tworzenia nazw kodowych oraz zalecenia dotyczące formatu drzew błędów. 5.2. Wykorzystanie wspomagania komputerowego w analizie drzew błędów Pakiety programów komputerowych są istotnym narzędziem wspomagającym analizy niezawodności systemów, z wykorzystaniem drzew błędów (uszkodzeń). Najczęściej dąży się do tego aby pakiet taki umożliwiał: Tworzenie nowych drzew błędów; Edycję drzew istniejących; Korzystanie z wewnętrznej bazy danych niezawodnościowych; Tworzenie własnych baz danych parametrów niezawodnościowych; 19 Analizę jakościową drzew błędów - generowanie zbiorów minimalnych przekrojów drzewa (nieredukowalnego zbioru iloczynów zdarzeń elementarnych, z których każdy prowadzi do zdarzenia szczytowego analizowanego drzewa); Analizę ilościową drzew błędów, opartą na wygenerowanym zbiorze minimalnych przekrojów drzewa; Analizę stopnia wpływu zdarzeń elementarnych na prawdopodobieństwo zajścia zdarzenia wierzchołkowego analizowanego drzewa; Wyznaczanie metodą Monte Carlo rozkładu prawdopodobieństwa zajścia zdarzenia wierzchołkowego na podstawie funkcji rozkładu prawdopodobieństwa zdarzeń elementarnych; Analizy jakościowe i ilościowe drzew zdarzeń wyznaczających ciągi awaryjne, opisane przez kombinacje zdarzeń szczytowych dla różnych systemów lub kluczowych działań operatora obsługującego instalację. W dalszej części opracowania opisano najczęściej używane programy do analiz FTA. Tabela 1. Zestawienie zalecanych symboli graficznych. Symbole bramek logicznych Bramka „I” - Zdarzenie na wyjściu bramki zachodzi tylko wtedy, gdy wszystkie zdarzenia stanowiące wejścia do bramki zachodzą jednocześnie Bramka „LUB” - Zdarzenie na wyjściu bramki zachodzi, jeżeli zachodzi jedno lub więcej zdarzeń stanowiących wejścia do bramki Bramka „WYŁĄCZNE LUB” - Zdarzenie wyjściowe zachodzi tylko w sytuacji, gdy zachodzi dokładnie jedno ze zdarzeń stanowiących wejścia do bramki Bramka „I Z PRIORYTETEM” - Zdarzenie wyjściowe zachodzi tylko w sytuacji, gdy wszystkie zdarzenia wyjściowe do bramki zachodzą w odpowiedniej kolejności /kolejność ta jest podana z prawej strony bramki jako tzw. zdarzenie warunkujące/ - Zdarzenie wyjściowe zachodzi w sytuacji określonej przez funkcję logiczną podaną przez użytkownika / z prawej strony bramki/ Bramka „SPECJALNA” 20 Bramka „NIE” -Zdarzenie wyjściowe jest zaprzeczeniem zdarzenia wejściowego Bramka „ZAKAZ” - Zdarzenie wyjściowe zachodzi w wyniku pojedynczego zdarzenia wejściowego i spełnienia dodatkowego warunku /podanego z prawej strony jako tzw. zdarzenie warunkujące/ 21 Symbole zdarzeń elementarnych Zdarzenie Pierwotne - Zdarzenie nie wymagające dalszego rozwijania Zdarzenie Nierozwinięte - Zdarzenie, które nie jest dalej rozwijane ze względu na małe znaczenie tego zdarzenia lub brak dostatecznych informacji - Zdarzenie, które mogłoby być dalej rozwijane lub jest rozwinięte gdzie indziej, ale jest traktowane jako zdarzenie elementarne - Zdarzenie, które zwykle w normalnych warunkach zachodzi Zdarzenie Rozwinięte Zdarzenie zewnętrzne Symbole przeniesienia „przeniesienie z” - symbol przeniesienia umieszczany przy opisie zdarzenia, które występuje w drzewie kilkakrotnie, a jest rozwinięte tylko w jednym miejscu drzewa „przeniesienia do” - Symbol przeniesienia umieszczany przy zdarzeniu, dla wskazania miejsca, w którym należy dołączyć fragment drzewa, oznaczony odpowiednim symbolem „przeniesienie z” 22 Tabela 2. Kody oznaczeń literowych dla systemów istotnych dla przebiegu awarii. Oznaczenie AZ TI TJ TH Nazwa systemu Systemy pierwszoplanowe: System wyłączania awaryjnego reaktora Bierny system awaryjnego chłodzenia rdzenia (BUACR) Czynny wysokociśnieniowy system awaryjnego chłodzenia rdzenia (CWUACR) Czynny niskociśnieniowy system awaryjnego chłodzenia rdzenia (CNUACR) TQ RS RX YP System awaryjnego zraszania pomieszczeń szczelnych i lokalizacji awarii System przekazywania i przetwarzania energii Awaryjny system wody zasilającej System zaworów upustowych stabilizatora EB EQ ED EK CZ CX CA VF TA TP TF TL Systemy wspierające: System zasilania elektrycznego od sieci zewnętrznej System dieslowskich układów niezawodnego zasilania (poziom 6 i 0.4 kV) System zasilania elektrycznego prądu stałego 220V System bezprzerwowego zasilania prądem przemiennym 220 V System sterowania działaniami zabezpieczającymi System sterowania awaryjnym systemem wody zasilającej Zintegrowany system sterowania bloku System wody ruchowej odpowiedzialnej System sprężonego powietrza wysokiego ciśnienia System azotu wysokiego ciśnienia System chłodzenia pośredniego urządzeń System chłodzenia recyrkulacyjnego pomieszczeń UACR 23 Tabela 3. Oznaczenia kodowe dla określania typu urządzeń lub elementu – znaczenie pierwszej litery identyfikatora. Litera A B C D E G X,T,V,S Z Y,Q,U Rodzaj układów, urządzeń lub elementów Agregaty cieplno-mechaniczne, obejmują układy lub urządzenia wyposażone w napęd (wraz z napędem) Aparaty cieplno-mechaniczne, obejmują układy lub urządzenia nieposiadające napędu Układy pomiarowe Układy automatycznej regulacji Układy przetwarzania wartości wielkości mierzonych Urządzenia elektryczne Cieplno-mechaniczne elementy urządzeń i układów Nieelektyczne elementy automatyki Elektryczne elementy urządzeń i układów. 24 Tabela 4. Oznaczenia kodowe dla agregatów cieplno-mechanicznych. Oznaczenie AA AB AC AE AF AG AH AM AN AP AR AS AT AU AV AX AZ 3 Grupa urządzeń Zawieradła Wrota, bramy, śluzy, przepusty Wymienniki ciepła łącznie z napędami Suwnice, dźwignice, żurawie, wywrotnice Przenośniki poziome i pionowe Agregaty prądotwórcze diesla, wodne, gazowe Agregaty grzewcze lub chłodnicze Mieszanki do cieczy i ciał sypkich Wentylatory, dmuchawy, sprężarki Pompy Urządzenia przeładunku paliwa jądrowego3 Urządzenia nastawcze, siłowniki Agregaty sedymentacyjne i filtrujące łącznie z napędami Układy napędowe podzespołów regulacyjnych, reaktora 7 Agregatory dopalające Agregaty dc przeprowadzania prób Agregaty specjalne i inne Oznaczenia uzupełniające w stosunku do systemu SOWEL 25 Tabela 5. Oznaczenia kodowe dla aparatów cieplno-mechanicznych. Oznaczenie BA BB BC BD BE BG BH BJ BM BP BQ BR BS BT BU BV BY BW 4 Grupa urządzeń Zasobniki UACR4 Zbiorniki, zasobniki Wymienniki ciepła (podgrzewacze, chłodnice) Rozprężacze Odwadniacze, syfony Powierzchnie ogrzewalne Urządzenia grzewcze i chłodzące (nie napędzane) Osuszacze powietrza i gazu6 Urządzenie do obróbki chemicznej, demineralizatory Strumienice Zawieszenia i podparcia (zblokowane zestawy) Rurociągi, kanały, kolektory (zblokowane zestawy) Tłumiki akustyczne Filtry i rozdzielacze Izolacja Urządzenia dopalające, palniki (nie napędzane) Rekombinatory6 Wytwornice pary6 Oznaczenia uzupełniające w stosunku do systemu SOWEL 26 Tabela 6. Oznaczenia kodowe dla urządzeń elektrycznych. Oznaczenie GA GB BC GD GE GG GH GJ GL GM GN GP GQ GR GS GT GU GV GW GX GY Grupa urządzeń Rozdzielnice pomocnicze prądu przemiennego ogólnych potrzeb własnych Rozdzielnice pomocnicze prądu przemiennego potrzeb własnych blokowych Rozdzielnice pomocnicze prądu stałego ogólnych potrzeb własnych Rozdzielnice potrzeb własnych blokowych Rozdzielnice niezawodnego prądu przemiennego Zestawy przyłączowe, pośredniczące Mosty i ciągi szynowe Przepusty szynowe Przepusty kablowe Mufy i głowice kablowe Rozdzielnice pomocnicze oświetlenia specjalnego Rozdzielnice pomocnicze oświetlenia podstawowego Siłowe złącza wtykowe Urządzenia wytwórcze prądu stałego, baterie akumulatorów Urządzenia łączeniowe i sterownicze (nie związane z realizowaną technologią) Urządzenia transformujące Urządzenia prostownicze Urządzenia przekształtnikowe Zestawy zabezpieczeń prądowych Urządzenia nastawcze Urządzenia łączności 27 Tabela 7. Oznaczenia kodowe dla układów automatycznej regulacji. Oznaczenie DA DB DC DD DE DF DG DI DJ DK DL DM DN DP DQ DR DS DT DU DV DW DZ Wielkość kontrolowana przez układ Skład produktu Płomień Przewodność (cieplna, elektryczna i inne) Gęstość, ciężar właściwy Napięcie elektryczne, siła elektromotoryczna Natężenie przepływu Wymiar przedmiotu Natężenie prądu elektrycznego Moc Czas, program Poziom Wilgotność Praca (energia), ruch Ciśnienie Ilość produktu lub zdarzeń w czasie Radioaktywność Prędkość, częstotliwość Temperatura Wielkość jako funkcja wielu zmiennych Lepkość Siła, ciężar Droga, przesunięcie, położenie 28 Tabela 8. Oznaczenie kodowe dla kompleksowych układów przetwarzania wartości wielkości mierzonych. Oznaczenie EP ES EU EZ Przeznaczenie układu Komputer procesu technologicznego Funkcje związane ze sterowaniem Zintegrowane przetwarzanie wartości wielkości mierzonych wspólne-dla wielu różnych systemów automatyki Zabezpieczenia i blokady 29 Tabela 9. Oznaczenia kodowe dla cieplno-mechanicznych elementów układów i urządzeń. Oznaczenie XB XC XD XE XF XG XJ XK XL XM XN XP XQ XR XS XT XU XW XX XY XZ SM SE SP SU VV VM VE VP VZ VN VR TK TP TW TG TX Grupa lub typ elementów Elementy zbiorników, zasobników Wymienniki ciepła jako elementy urządzeń Ograniczniki strumienia, dysze, krzyży, zwężki itp. Elementy urządzeń dźwigowych Elementy przenośników Silniki z wyjątkiem elektrycznych oraz turbin Elementy kruszarek, młynów Elementy pras, urządzeń pakietujących Przekładnie, sprzęgła Mieszalniki Wentylatory, dmuchawy Pompy Zawieszenia, podparcia Elementy rurociągów i kanałów Siłowniki nieelektryczne Filtry, rozdzielacze Podzespoły regulacyjne reaktora Elementy wytwornic pary Elementy urządzeń do przeprowadzania prób Hamulce Elementy urządzeń specjalnych Mechanizm napędowy zaworu z silnikiem elektrycznym Mechanizm napędowy zaworu typu elektromagnetycznego Mechanizm napędowy zaworu typu pneumatycznego Mechanizm napędowy podzespołu regulacyjnego reaktora Zawór ręczny Zawór z napędem silnikiem elektrycznym Zawór elektromagnetyczny Zawór pneumatyczny Zawór zwrotny Zawór nadmiarowy, bezpieczeństwa Zawór redukcyjny Turbina parowa kondensacyjna Turbina parowa przeciwprężna Turbina wodna Turbina gazowa Turbina innego typu 30 Tabela 10. Oznaczenia kodowe dla elektrycznych elementów układów i urządzeń. Oznaczenie YA YB YC YD YE YF YG QG UG YH YK YL YM YN YP YQ YR Grupa lub rodzaj elementów Zespoły sterowniczo-sygnalizacyjne pomiarowe, automatyki łączeniowej zabezpieczającej, wzmacniacze, itp. Przetworniki i nadajniki pomiarowe analogowe i cyfrowe (sygnał wejściowy nieelektryczny - sygnał wyjściowy elektryczny lub odwrotnie) Kondensatory Elementy binarne, opóźniające i pamięciowe Grzejniki elektryczne, elementy różne Elementy zabezpieczające (odgromniki, bezpieczniki, wyzwalacze, wyłączniki) Elementy generujące (prądnice, przetwornice i wzmacniacze maszynowe) Akumulator Prostownik, zasilacz, oscylator Elementy sygnalizacyjne Przekaźniki, styczniki Cewki, dławiki Silniki elektryczne Regulatory i elementy operacyjne Przyrządy pomiarowe Łączniki w obwodach głównych (wyłączniki, rozłączniki, odłączniki itp.) Rezystory YS Przyrządy sterownicze, wybieraki (sterowniki, przyciski, przełączniki, nastawniki, łączniki instalacyjne) YT Transformatory YU Przetworniki sygnałów elektrycznych, modulatory, elementy transmisyjne Lampy elektronowe, elementy półprzewodnikowe Kanały transmisyjne, falowody, anteny Łączniki wtykowe, zaciski Elektrycznie zasilane lub sterowane elementy mechaniczne, pneumatyczne, hydrauliczne Elementy końcowe, przekształtniki hybrydowe, filtry, korektory, ograniczniki YV YW YX YY YZ 31 Tabela 11. Oznaczenia kodowe dla nieelektrycznych elementów automatyki. Oznaczenie ZA ZB ZH ZM ZN ZP ZR ZS ZT ZU ZX Grupa lub rodzaj elementów Armatura urządzeń automatyki Nadajniki lub przetworniki pomiarowe (analogowe i cyfrowe o nieelektrycznych sygnałach wejścia i wyjścia) Wskaźniki i sygnalizatory stanu Przyłącza manometryczne Regulatory, elementy operacyjne, logiczne, wzmacniacze Przyrządy pomiarowe, analogowe Rurki sygnałowe (impulsowe) Naczynia pomocnicze urządzeń automatyki Przyłącza termometryczne Przetworniki sygnałów (analogowe i cyfrowe o nieelektrycznych sygnałach wejścia i wyjścia) Złącza kanałów przesyłowych 32 Tabela 12. Oznacza kodowe używane do określenia charakteru zdarzenia 5. Oznaczenie H M S C O T R X N F Charakter zdarzenia Błędy związane z działalnością personelu6 Niedyspozycyjność spowodowana wykonywaniem prac konserwacyjno-obsługowych Niesprawność polegająca na nieudanej próbie uruchomienia lub włączenia urządzeń (należy stosować do wszystkich urządzeń, które oczekują w rezerwie i są uruchamiane na sygnał jak np. pompy, wentylatory itp., niesprawności zaworów zalicza się do innych kategorii zdarzeń) Nieudana próba zamknięcia (złączenia) urządzenia na sygnał Nieudana próba otwarcia (rozłączenia) urządzenia na sygnał Nieprawidłowe działanie polegające na zmianie właściwego położenia elementu lub niepożądanym, samoistnym działaniu urządzenia. Nieprawidłowość funkcjonalna polegająca na zatrzymaniu się (przerwie w funkcjonowaniu) pracującego urządzenia-stosuje się zwykle do urządzeń, w których stan pracy ma charakter czasowy np. pracująca pompa, silnik, prądnica itp.) Zwarcie elektryczne Przerwa w obwodzie lub brak sygnału wyjściowego (nie tylko elektrycznego) Niewykonanie określonego zadania funkcjonalnego. Kategoria ta zawiera wszystkie niesprawności, których nie daje się zaliczyć do żadnej z ww. kategorii. 6. PRAKTYCZNE WSKAZANIA DOTYCZĄCE ANALIZY SYSTEMÓW EJ W niniejszym rozdziale omówione zostały niektóre specyficzne cechy systemów z jakimi ma się do czynienia przy analizie bezpieczeństwa EJ. Podano również pewne praktyczne zalecenia ułatwiające opracowanie odpowiednich modeli tych systemów oraz ich analizę. . 6.1. Modelowanie systemów EJ 6.1.1. Podstawowe typy systemów Spośród systemów odgrywających istotną rolę przy analizie bezpieczeństwa EJ liczną grupę stanowią systemy cieplno-przepływowe. Z funkcjonalnego punktu widzenia są to przeważnie 5 Przytoczona lista zdarzeń nie wyczerpuje wszystkich sytuacji, które mogą wystąpić w analizach systemów. Bardziej precyzyjny opis zdarzenia powinien być podany w drzewie zdarzeń oraz w zestawieniach zdarzeń pierwotnych. 6 Błędy związane z działalnością personelu powinny dominować w zestawieniu z innymi cechami zdarzenia. Jeśli nie udało się uruchomić pompy na skutek błędu obsługi, zdarzenie powinno być oznaczone symbolem H, a nie S. 33 różnego rodzaju systemy chłodzenia i wentylacji. Wspólnym elementem tych systemów jest przesyłanie czynnika roboczego o określonych parametrach i z określoną intensywnością zgodnie z wymaganiami procesu technologicznego. Integralną cechą tych systemów jest rozbudowana sieć rurociągów lub kanałów przepływowych z odpowiednią armaturą oraz urządzeniami przetłaczającymi czynnik (pompy, wentylatory, sprężarki), zbiornikami lub zasobnikami, wymiennikami ciepła itp. Znaczna część komponentów wchodzących w skład takich systemów jest zdalnie sterowana, albo bezpośrednio sygnałami z systemu sterowania, czy systemu zabezpieczeń albo za pośrednictwem odpowiednich układów sterujących. Specyficzną cechą tych systemów są liczne powiązania z innymi systemami, przede wszystkim z systemami zasilania elektrycznego oraz systemami sterowania i zabezpieczeń. Istotne znaczenie mogą mieć również powiązania z innymi systemami cieplno-przepływowymi spełniającymi pomocnicze funkcje (np. wentylacja pomieszczeń, dodatkowe chłodzenie komponentów itp.). Systemy elektryczne obejmują szeroką grupę systemów, które dostarczają energię elektryczną do sieci elektroenergetycznej oraz do innych systemów i urządzeń EJ. Dla potrzeb związanych z analizami sytuacji awaryjnych istotne znaczenie mają systemy zasilania potrzeb własnych w warunkach awaryjnych. Pierwotnymi źródłami energii są w tych systemach: sieć zewnętrzna, zespoły prądotwórcze diesla oraz baterie akumulatorów. Specyficzną cechą systemów zasilania jest modułowość oraz hierarchiczna struktura. Modułowość systemu zasilania elektrycznego polega na wyodrębnieniu szeregu podsystemów oddzielonych od siebie elektrycznie i fizycznie. Jednym z kryteriów podziału jest rodzaj odbiorów i wymagania dotyczące pewności zasilania. Dalszy podział na podsystemy wynika z wymagań związanych z rezerwowaniem. Z reguły wyróżnia się trzy grupy odbiorów (urządzeń zasilanych energią elektryczną), z których dwie pierwsze obejmują odbiory istotne dla bezpiecznego: wyłączenia reaktora w warunkach awaryjnych lub niezbędne dla zredukowania skutków awarii, a trzecie odbiory używane w czasie normalnej pracy bloku. W systemie niezawodnego zasilania obejmującego odbiory pierwszej i drugiej grupy wyodrębnia się szereg ciągów niezależnych pod względem fizycznym i elektrycznym. Stanowią one źródła energii dla wszystkich redundancyjnych komponentów lub systemów istotnych dla bezpieczeństwa obiektu. Hierarchiczna struktura systemu zasilania elektrycznego EJ jest związana z istnieniem szeregu szyn zbiorczych na różnych poziomach napięcia. W strukturze tej szyny, zbiorcze niższego poziomu napięcia są połączone z szyną zbiorczą poziomu bezpośrednio wyższego. Przykład typowej struktury hierarchicznej jednego z ciągów systemu niezawodnego zasilania EJ pokazano na rys. 3. 34 Rys. 3. Przykładowy fragment systemu elektrycznego ilustrujący hierarchiczną. strukturę systemu. Hierarchiczna struktura systemu ma istotny wpływ na sposób konstruowania drzew błędów. Dzięki takiej strukturze część drzewa określająca utratę napięcia na określonej szynie zbiorczej jest wspólna dla kilku szyn bezpośrednio z nią związanych, co ma korzystny wpływ na rozmiary modelu. Systemy sterowania i automatyki stanowią znaczącą i bardzo ważną część wyposażenia EJ. Zadaniem tych systemów jest utrzymanie parametrów pracy EJ w bezpiecznych i ekonomicznych zakresach. Pod względem funkcjonalnym w systemach tych wyróżnia się dwie zasadnicze grupy - systemy sterowania oraz zabezpieczeń. Funkcje sterujące obejmują całą gamę zadań funkcjonalnych związanych ze sterowaniem poszczególnych mechanizmów, urządzeń czy układów w normalnych warunkach pracy bloku. Systemy realizujące funkcje zabezpieczające (nazywane systemami sterowania działaniami zabezpieczającymi) zapewniają automatyczne podjęcie określonych działań zabezpieczających w sytuacjach awaryjnych zagrażających bezpieczeństwu EJ. Sytuacje takie określone przez zdefiniowanie granicznych wartości odpowiednich parametrów technologicznych. W rozwiązaniach EJ systemy sterowania i systemy zabezpieczeń są z reguły podzielone pod względem funkcjonalnym i fizycznym. 35 Układy sterujące mechanizmami lub urządzeniami realizują sygnał włączenia lub uruchomienia określonego komponentu. Współpracują one zwykle z pojedynczym komponentem, w odróżnieniu od systemów sterowania i systemów zabezpieczeń, które mogą generować sygnał wejściowy dla kilku układów sterujących. Uszkodzenie układu sterującego może spowodować niemożność zamierzonej zmiany stanu operacyjnego komponentu lub niezamierzoną zmianę tego stanu. Komponenty mogą być sprzężone bezpośrednio z układem sterującym (niektóre rozłączniki, zawory elektromagnetyczne i inne) lub za pośrednictwem odpowiedniego łącznika umieszczonego w układzie zasilania (pompy, wentylatory, zawory napędzane silnikiem elektrycznym). Powiązania pomiędzy sterowanym komponentem oraz układem sterującym, systemem sterowania i zabezpieczeń oraz systemami wspierającymi, które powinny być uwzględnione przy budowie drzew błędów pokazano na rys. 4. Rys.4. Powiązania pomiędzy sterowanym urządzeniem, układem sterującym, systemem sterowania i zabezpieczeń, systemami wspierającymi oraz personelem eksploatacyjnym. 6.1.2. Zasady dekompozycji systemu Pierwszą i bardzo ważną czynnością przy konstruowaniu drzew błędów jest opracowanie uproszczonego schematu i jego podział na segmenty. Uproszczenia schematu polegają na eliminacji pewnych części systemu, które nie mają istotnego wpływu na zachowanie się systemu. W przypadku systemów przepływowych może być stosowana zgrubna reguła, określająca jako mało istotne dla zachowania się systemu, rurociągi stanowiące odgałęzienia głównego przewodu rurowego, których średnica jest mniejsza niż 1/3 średnicy głównej nitki. Podobnie segmenty rurowe zawierające zawory z napędem ręcznym, które są normalnie zamknięte, a których otwarcie może mieć korzystny wpływ na skuteczność działania systemu, na ogół mogą być pominięte. Otwarcie takiego 36 zaworu przez operatora nie jest brane pod uwagę, jeżeli nie jest to wyraźnie ujęte w odpowiednich procedurach awaryjnych. W przypadku systemów elektrycznych lub systemów sterowania i zabezpieczeń mogą być pominięte niektóre części obwodów, które odgrywają jedynie pomocniczą rolę w wykonaniu zasadniczych funkcji systemu, jak np. obwody sygnalizacji, obwody rejestracji komputerowej, niektóre blokady czy wyposażenie zabezpieczające. Po wykonaniu wszystkich możliwych uproszczeń system dzieli się na segmenty przez zaznaczenie węzłów we wszystkich miejscach, w których następuje połączenie dwóch lub większej liczby przewodów (rurowych czy elektrycznych). Każda z części systemu zawarta pomiędzy określonymi w ten sposób węzłami tworzy segment. W przypadku systemów przepływowych segment taki składa się z pojedynczej nitki rurociągu zawierającej z reguły odpowiednią armaturę odcinającą czy regulacyjną, urządzenia przetłaczające, powierzchnie wymiany ciepła itp. W systemach elektrycznych i systemach sterowania segment składa się z pojedynczej linii kablowej oraz odpowiedniego wyposażenia elektrycznego jak łączniki, cewki przekaźników; uzwojenia maszyn elektrycznych, transformatorów itp. W odniesieniu do układów sterowania segment nazywany jest również ścieżką sygnałową. Stosowane jest również pojęcie sieci elektrycznej stanowiącej szeregowo równoległą kombinację kilku ścieżek sygnałowych. Wprowadzenie segmentacji ułatwia systematyczną analizę możliwych uszkodzeń systemu. Analiza ta polega na znalezieniu wszystkich logicznych kombinacji uszkodzeń dla każdego z segmentów (ścieżek sygnałowych), określonych części systemu (sieci) i wreszcie całego systemu. 6.1.3. Szczegółowość modelu Szczegółowość modelu logicznego jest bardzo ważnym czynnikiem wpływającym z jednej strony na pracochłonność analiz, a z drugiej strony na jakość uzyskanych rezultatów. Istotną sprawą, która może skłaniać do zwiększenia szczegółowości modelu jest uwzględnienie różnego rodzaju powiązań międzysystemowych. W dużej mierze istniejące współzależności wynikają z powiązań określonego systemu z systemami zasilania oraz systemami sterowania i zabezpieczeń. Ze względu na wspomniane wyżej powiązania szczegółowość modelu powinna być co najmniej taka, aby wszystkie czynniki wspólne dla kilku systemów mogły być wyrażone w sposób jawny przez wyprowadzenie odpowiednich identycznie sformułowanych i nazwanych zdarzeń użytych w poszczególnych drzewach uszkodzeń. Drugim ważnym czynnikiem mającym wpływ na szczegółowość modelu jest szczegółowość danych probabilistycznych dotyczących komponentów analizowanego systemu. Szczegółowość tych danych może być różna. Zależy ona w dużej mierze od typu systemu. W odniesieniu do większości systemów przepływowych, a także do systemów zasilania elektrycznego szczegółowość modelu stosowana w praktyce PSA jest konsystencja z istniejącymi danymi niezawodnościowymi uzyskiwanymi z historii eksploatacyjnej elektrowni jądrowych. Przy modelowaniu uwzględnia się więc poszczególne komponenty wchodzące w skład systemu na poziomie agregatów (np. pompy z napędem, zawieradła elektryczne, uradzenia łączeniowe, transformujące itp.), a niekiedy nawet elementów. W odniesieniu do niektórych systemów, stosowane jest inne podejście. I tak np. przy analizach 37 systemu przekazywania i przetwarzania energii można wykorzystać stosunkowo bogate dane statystyczne o dużym stopniu agregacji, modelując niedyspozycyjność całego systemu, lub dużych jego części, wywołaną przez przyczyny niezależne, jako zdarzenia elementarne. Przy takim podejściu należy jedynie rozbudować tą część modelu, która wiąże się z uszkodzeniami systemu wywołanymi przez zdarzenia zależne wynikające z powiązań międzysystemowych. W odniesieniu do systemów sterowania i zabezpieczeń często stosowanym poziomem szczegółowości modelu jest poziom wynikający z logicznego schematu funkcjonalnego. Ten poziom szczegółowości nie wymaga analizowania logiki obwodów na poziomie elementów półprzewodnikowych czy pojedynczych przekaźników. Jest jednak wystarczający, aby właściwie wprowadzić do modelu wszystkie zależności związane z zasilaniem w energię, chłodzeniem w warunkach awaryjnych, działaniem personelu itp. 6.1.4. Niektóre założenia modelowe Szereg założeń przyjmowanych w analizach PSA ma charakter ogólny i odnosi się do różnych systemów EJ. Pęknięcia rurociągów nie są z reguły uwzględniane w drzewach błędów. Zdarzenia te są na ogół pomijane w zestawieniu z innymi uszkodzeniami. Wyjątkiem są pęknięcia stanowiące wspólną przyczynę uszkodzeń kilku elementów. Uszkodzenia zaworów zwrotnych polegające na odwrotnym przepływie czynnika są z reguły pomijane. Zablokowanie przewodów przepływowych jest z reguły pomijane w stosunku do innych uszkodzeń. W niektórych uzasadnionych przypadkach (np. wysoka koncentracja kwasu borowego) zjawiska takie mogą być modelowane bezpośrednio w diagramie. Pasywne uszkodzenie zaworów (odłączenie grzybka zaworu od wrzeciona) są z reguły pomijane. Wyjątkiem mogą być sytuacje w których uszkodzenie takie ogranicza stopień redundacyjności w systemie lub sytuacje długotrwałej pracy bez możliwości detekcji uszkodzenia. W analizach rozróżnia się z reguły dwa stany komponentów - stan. uszkodzenia oraz stan prawidłowego funkcjonowania. Kombinacja częściowych uszkodzeń, które mogą prowadzić do prawidłowego zachowania się systemu nie jest uwzględniana. Zakłada się, że rozwiązania projektowe systemów/komponentów są prawidłowe. Przy modelowaniu czynności obsługowo-konserwacyjnych, przeglądów, prób itp., które wiążą się z odstawianiem urządzeń z ruchu zakłada się, że rażące naruszenie ograniczeń ruchowych czy innych przepisów ujętych w procedurach eksploatacyjnych jest pomijalne, ze względu na małe prawdopodobieństwo tego zdarzenia. 6.1.5. Identyfikacja istotnych zdarzeń Wybór odpowiednich zdarzeń i komponentów, które należy uwzględnić w modelu zależy od typu modelowanego zdarzenia wierzchołkowego. 38 Jeżeli modeluje się utratę drożności określonego segmentu w systemie przepływowym, należy uwzględnić wszystkie uszkodzenia komponentów znajdujących się w rozpatrywanym segmencie powodujące zablokowanie przepływu. W tym przypadku należy zastosować bramkę logiczną "LUB". Podobnie postępuje się modelując przerwanie ścieżki sygnałowej w systemie sterowania. W tym przypadku uwzględnia się wszystkie uszkodzenia komponentów powodujących przerwanie obwodu, kojarząc je przy użyciu bramki logicznej "LUB". Utrata szczelności określonego segmentu rurowego następuje w przypadku równoczesnej zmiany pozycji wszystkich zaworów normalnie zamkniętych. W tym przypadku nałoży zastosować bramkę logiczną "I". Podobnie postępuje się modelując zamknięcie ścieżki sygnałowej w układach sterowania. Należy uwzględnić równoczesne uszkodzenia wszystkich elementów znajdujących się w tej ścieżce w pozycji zamykającej obwód, stosując bramkę "I". Przy modelowaniu zdarzenia polegającego na zamknięciu obwodu zwykle nie uwzględnia się w modelu takich komponentów, jak przewody, cewki, uzwojenia maszyn elektrycznych. Uwzględnienie tych zdarzeń w takim przypadku jest niewłaściwe, gdyż niepotrzebnie komplikuje model, a ponadto wprowadza niekoherentność drzewa7. Analiza tych drzew jest utrudniona. Dlatego zaleca się zachowanie koherentności drzew. Przy modelowaniu systemów sterowania działaniami zabezpieczającymi należy starannie przeanalizować uszkodzenia źródeł zasilania elektrycznego. W przypadku tych systemów każdy z redundancyjnych torów kontrolno-pomiarowych zasilany jest z odrębnego i niezależnego źródła zasilania. Nieuwzględnienie tego faktu może doprowadzić do istotnych błędów. Jedną z przyczyn uszkodzeń wyposażenia może być podwyższona temperatura w pomieszczeniach, w których jest ono zlokalizowane. Dotyczy to w szczególności maszyn elektrycznych oraz aparatury elektronicznej. Pierwotną przyczyną takiego uszkodzenia jest często awaria systemu wentylacyjnego. Dla rozstrzygnięcia czy tego typu zdarzenie powinno być uwzględnione w modelu należy ustalić dopuszczalny czas pracy wyposażenia w warunkach podwyższonej temperatury. Jeżeli czas ten jest znacznie dłuższy w porównaniu z wymaganym czasem działania wyposażenia, uszkodzenie te nie muszą być brane pod uwagę. Z reguły zdarzeniami o istotnym znaczeniu są błędy ludzkie. Błędy te mogą być dominującym elementem przy ocenie niegotowości systemu. Szczególne znaczenie mają dwa typy błędów ludzkich - błędy popełnione przez personel eksploatacyjny przy wykonywaniu czynności obsługowych i prób wyposażenia oraz błędy personelu operatorskiego w sytuacjach nienormalnych. Niegotowość komponentów w związku z obsługą i próbami okresowymi analizowana jest w oparciu o odpowiednie procedury eksploatacyjne. W wyniku tych analiz identyfikuje się konfigurację systemu właściwą dla przeprowadzenia obsługi lub próby i ustala, które z komponentów mogą być pozostawione przez personel w pozycjach naruszających bezpieczeństwo systemu. W odniesieniu do każdego z takich komponentów modeluje się niegotowość związaną z przeprowadzaniem czynności obsługowych oraz potencjalne błędy polegające na pozostawieniu komponentów w niewłaściwej pozycji (stanie). Błędy personelu operatorskiego modeluje się z reguły jako zdarzenia pierwotne na poziomie 7 Drzewami niekoherentynymi nazywane są drzewa zawierające równocześnie zdarzenia proste i dopełniające do tych zdarzeń. 39 komponentu. W odniesieniu do każdego z komponentów, który sterowany jest przez operatora, wprowadza się do modelu zdarzenie pierwotne modelujące nieprawidłowe funkcjonowanie komponentu spowodowane przez błąd operatora. 6.1.6. Identyfikacja i usuwanie pętli logicznych Wzajemne powiązania systemów mogą spowodować pojawienie się logicznych, pętli w modelu powstałych przez skojarzenie kilku systemowych drzew błędów przy analizie określonego ciągu zdarzeń awaryjnych. Takie pętle mogą mieć miejsce w przypadku niewłaściwego uwzględnienia czasowego elementu powiązań. Zasadniczy problem powstaje, gdy system A wymaga działania systemu B przy rozruchu i w początkowym okresie pracy, a system B wymaga działania systemu A w dłuższej perspektywie czasowej. Ten typ zależności można zilustrować na przykładzie systemów niezawodnego zasilania elektrycznego prądu, przemiennego oraz prądu stałego. Zasilanie prądem stałym jest istotne między innymi dla działania układów sterujących agregatów prądotwórczych diesla. W dłuższej perspektywie czasowej, określonej przez pojemność akumulatorów, baterie akumulatorowe muszą być ładowane przez odpowiednie prostowniki zasilane przez zespoły prądotwórcze diesla. Tak więc w drzewie błędów zespołów prądotwórczych pojawi się system zasilania prądu stałego jako system wspierający i na odwrót. Model każdego z systemów wydaje się poprawny, jednak po skojarzeniu ich pojawia się pętla logiczna. Innym przykładem pętli logicznej jest system chłodzenia agregatów diesla. Logiczna sprzeczność w tym przypadku polega na tym, że system ten wymaga zasilania elektrycznego prądem wytwarzanym przez agregat diesla, a agregat diesla wymaga odpowiedniego chłodzenia. Niektóre pętle logiczne, pojawiające się najczęściej w modelu EJ pokazano schematycznie na rys. 5 40 Rys.5. Ilustracja możliwych pętli logicznych w wielosystemowych drzewach uszkodzeń elektrowni jądrowej. Wspomniane wyżej pętle są trudne do zidentyfikowania w drzewie wykonanym dla pojedynczego systemu. Dla uniknięcia, takich nielogiczności niezbędna jest ścisła współpraca pomiędzy zespołami opracowującymi drzewa systemowe, a także odpowiednie działania koordynacyjne. Pozwala to wyeliminować takie nielogiczności na etapie opracowywania drzew. Dla uniknięcia pętli logicznych dokonuje się pewnych założeń polegających na pominięciu niektórych sprzężeń. Z reguły budowane są dwa poddrzewa - jedno dla krótkiego okresu pracy systemu, a drugie dla dłuższej perspektywy czasowej. W opisanym wyżej przypadku buduje się drzewo modelujące pracę systemu w okresie w jakim agregaty diesla mogą pracować bez 41 chłodzenia zewnętrznego oraz drzewo modelujące pracę długotrwałą. W pierwszym modelu pomija się w ogóle powiązanie z systemem chłodzenia. W drugim modelu uwzględnia się system chłodzenia, jednak drzewo modelujące zasilanie elektryczne jest rozwijane tylko do pewnego poziomu (np. najbliższej szyny zbiorczej). W ten sposób eliminuje się pętlę logiczną, nie rezygnując z uwzględnienia istotnych powiązań systemu chłodzenia z systemem zasilania elektrycznego. Podobnie postępuje się w przypadku innych możliwych pętli logicznych. 6.2. Zdarzenia wierzchołkowe dla systemów EJ Zdarzenia wierzchołkowe dla systemów EJ są podstawowymi informacjami wyjściowym dla opracowania systemowych drzew błędów. Jak wspomniano w rozdz. 2 zdarzenia wierzchołkowe dla systemów pierwszoplanowych wynikają logicznie z drzew zdarzeń stanowiących graficzną formę przedstawienia różnych sytuacji awaryjnych. Zdarzenia te są logicznym zaprzeczeniem pomyślnego wykonania zadań funkcjonalnych występujących w nagłówku drzewa zdarzeń. Wymagania funkcjonalne dla systemów pierwszoplanowych mogą być różne w zależności od rodzaju i przebiegu sytuacji awaryjnej. Różnice te wiążą się ze zdarzeniem początkującym awarię oraz ciągiem zdarzeń poprzedzających działanie systemu. W zależności od typu zdarzeń początkujących np. z reaktorami PWR wyróżnia się sytuacje awaryjne w EJ spowodowane przez rozszczelnienia obiegu pierwotnego oraz przez stany przejściowe wymagające wyłączenia reaktora. W pierwszej grupie awarii rozpatruje się zwykle 4-6 zakresów różniących się rozmiarami nieszczelności. Z reguły, rodzaj i kolejność ingerujących systemów oraz kryteria wykonania zadań funkcjonalnych są dla tych kategorii różne. W drugiej grupie stanów awaryjnych wyróżnia się zwykle stany przejściowe wywołane przyczynami nie naruszającymi zdolności systemów odprowadzania ciepła powyłączeniowego oraz stany przejściowe wywołane zanikiem zasilania zewnętrznego. 6.3. Dokumentacja modelu Rezultaty analiz systemów powinny być odpowiednio przedstawione i opisane. Opis ten powinien zawierać wszystkie niezbędne informacje umożliwiające zrozumienie przeprowadzonych analiz, a także w oparciu o przedstawiony model, ewentualne odtworzenie uzyskanych rezultatów. Bardzo istotną sprawą związaną z przedstawieniem modelu jest możliwe maksymalne ułatwienie dalszych prac nad budową i analizą modelu całej elektrowni. Mowa tu o procesie scalenia drzew błędów opracowanych dla poszczególnych systemów i analizy poszczególnych sytuacji awaryjnych. Dokumentacja modelu systemu powinna zawierać: • opis systemu, • wymagania modelowe wynikające z drzew zdarzeń, • opis modelu logicznego systemu. Wymagania modelowe wynikające z drzew zdarzeń powinny zawierać informacje dotyczące zdarzeń wierzchołkowych. Zdarzenia te powinny być przedstawione w kategoriach ilościowych zgodnych z kryteriami pomyślnego wykonania zadań funkcjonalnych 42 wynikających z drzew zdarzeń. Ponadto, należy przestawić wszystkie uwarunkowania (warunki brzegowe) wynikające z kontekstu drzew zdarzeń, które uwzględnia się przy analizie systemu. Właściwy opis modeli powinien zabierać podstawowe założenia modelowe, graficzne przedstawienie drzew błędów i słowny opis drzew błędów oraz tabelaryczne zestawienia informacji udokładniających charakterystyki zdarzeń występujących w modelu. Niektóre najczęściej spotykane założenia stosowane w niezawodnościowych analizach systemów EJ podane zostały w p. 6.1.4. W zależności od systemu i charakteru analizy mogą być przyjmowane inne założenia specyficzne dla danego systemu. Graficzne przedstawienie drzewa błędów jest zasadniczą częścią opisu modelu. Informacje dotyczące formatu drzew błędów przedstawione zostały w rozdz. 5. Słowny opis drzew błędów jest elementem uzupełniającym. Powinien on zawierać informacje wyjaśniające i uzasadniające przyjęte rozwiązania modelowe. W opisie należy możliwie często odwoływać się do opisów systemu stosując kodowe nazwy komponentów używane na schematach technologicznych, oraz kodowe nazwy zdarzeń używane przy graficznej reprezentacji drzew. Tabelaryczne zestawienie informacji dotyczących zdarzeń stanowiących elementy modelu ma charakter uzupełniający. Zawierają one dodatkowe, bardziej szczegółowe informacje charakteryzujące zdarzenia występujące w modelu. Zaleca się wykonanie odrębnych zestawień obejmujących zdarzenia pierwotne dotyczące wyposażenia EJ, błędy personelu oraz zdarzenia związane z obsługą urządzeń. Zestawienia te powinny zawierać nazwę kodową, słowny opis i typ zdarzenia oraz podstawowe dane liczbowe o charakterze probabilistycznym (prawdopodobieństwa lub intensywności uszkodzeń). W przypadku zdarzeń scharakteryzowanych przez intensywności uszkodzeń podać należy informacje dotyczące parametrów czasowych związanych z podanym wskaźnikiem. W pewnych przypadkach parametr czasowy może oznaczać czas wykonania określonego zadania odpowiedni dla danego zdarzenia wierzchołkowego. W innych przypadkach może to być czas związany z wykryciem określonego uszkodzenia. W odniesieniu do zdarzeń określonych przez intensywności uszkodzeń „na żądanie” podaje się średni czas pomiędzy kolejnymi żądaniami. Podaje się również średnią wartość prawdopodobieństwa danego zdarzenia uzyskany przez skojarzenie intensywności uszkodzeń z odpowiednim parametrem czasowym. Oprócz wspomnianych wyżej zestawień dotyczących zdarzeń pierwotnych zaleca się wykonanie zestawienia zdarzeń pośrednich, które są rozwinięte w innych systemach (oznaczenie symbolami przeniesienia). Zestawienie to jest bardzo istotne dla prawidłowego scalenia drzew błędów. Ułatwia to wykrycie i skorygowanie niekonsystencji lub błędów związanych z nazwami zdarzeń (różne nazwy dla tego samego zdarzenia). W zestawieniu tym podaje się głównie informacje dotyczące powiązań z innymi systemami jak systemy sterowania i zabezpieczeń, systemy zasilania elektrycznego, systemy zasilania w media robocze itp. Informacje zamieszczone w zestawieniu powinny zawierać słowne określenie zdarzenia, nazwę systemu, podsystemu, ciągu lub szyny zbiorczej określającą miejsce i sposób powiązania oraz kodową nazwę bramki. 43 7. TECHNIKI UZUPEŁNIAJĄCE STOSOWANE W OSZACOWANIACH ZDARZEŃ AWARYJNYCH Podstawy metod ocen błędów ludzkich w aspekcie bezpieczeństwa systemów technicznych 7.1. 7.1.1. Analiza niezawodności człowieka Analiza niezawodności człowieka (Human Reliability Analysis - HRA) jest metodą oszacowania niezawodności człowieka. Podczas przeprowadzania HRA niezbędne jest zidentyfikowanie tych działań człowieka, które mogą wpływać na niezawodność lub dyspozycyjność systemu. Najczęstszym zastosowaniem HRA jest ocena działań człowieka w aspekcie funkcjonowania systemu. Człowiek, rozpatrywany jako element systemu, może nie tylko zawieść w ten sposób, że nie wykona przewidzianych zadań lub że wykona je nieprawidłowo, ale również może wykonać czynności prowadzące do degradacji zdolności systemu do spełnienia swoich funkcji. To ostatnie nie jest zwykle przedmiotem HRA. Czynniki wpływające na działanie człowieka W modelowaniu działania człowieka na potrzeby zintegrowanych ocen ryzyka systemu niezbędne jest uwzględnienie tych czynników, które najbardziej wpływają na zachowanie się człowieka. Określane są one mianem czynników wpływających na działanie człowieka (Performance Shaping Factor - PSF). PSF dzielą się na zewnętrzne i wewnętrzne. Czynniki zewnętrzne obejmują całość środowiska pracy, szczególnie zaś konstrukcję urządzeń i maszyn, instrukcje pisemne i ustne. Natomiast wewnętrzne PSF wiążą się z indywidualnymi cechami osób, ich umiejętnościami, motywacją i oczekiwaniami. Stresy psychologiczne i fizjologiczne są czynnikiem środowiska pracy, w którym wymagania nałożone na człowieka przez system nie są współmierne z jego zdolnościami i ograniczeniami. W modelowaniu zachowania się człowieka wyróżnia się często cztery poziomy czynników stresujących: bardzo niski (niewystarczający, aby zachować odpowiedni poziom czujności przy wykonywaniu zadań); optymalny (ułatwiający wykonywanie zadań); umiarkowanie wysoki (w umiarkowany sposób przeszkadza w optymalnym wykonaniu zadań); bardzo wysoki. Trzy pierwsze poziomy utożsamia się ze stresem zadaniowym, związanym z niskim, optymalnym lub dużym obciążeniem zadaniami. Najwyższy poziom reprezentuje stres zagrożenia i jest powodowany emocjonalnymi reakcjami związanymi z sytuacją w jakiej zadanie jest wykonywane Zależność i sprzężenie Zależność jest jeszcze innym ważnym czynnikiem PSF. Zależność pomiędzy dwoma zadaniami odnosi się do sytuacji, gdy na prawdopodobieństwo niepowodzenia wykonania jednego zadania wpływa sukces lub niepowodzenie wykonania innego zadania. Taka zależność 44 może występować pomiędzy zadaniami tej samej osoby lub dwóch innych osób wykonujących dwa różne zadania. Dla celów praktycznych zastosowanie HRA kontinuum możliwych stopni zależności pomiędzy zadaniami zastępuje się przez pewne grupy tych zależności, np. zerowa zależność (ZD), niska zależność (LD), umiarkowana zależność (MD), wysoka zależność (HD) i całkowita zależność CD). Skutki błędów ludzkich i czynnik odnowy Świadomość skutków błędu może spełniać funkcję PSF. Ta świadomość może obniżać lub zwiększać prawdopodobieństwo popełnienia błędu. Na przykład operator obawiając się nagany lub obciążenia poniesionymi stratami ekonomicznymi może powstrzymywać się przed wyłączeniem złożonego urządzenia lub instalacji, chociaż znamiona powstałej sytuacji awaryjnej będą wskazywały na konieczność zrobienia tego. Często skutki błędów człowieka mogą być kompensowane przez inne elementy systemu lub inne działania człowieka. Decyduje o tym tzw. czynnik odnowy (Recovery Factor - RF) przewidziany w systemie. Typowym przykładem czynnika odnowy jest rezerwowanie ludzkie. 7.1.2. Podstawowe elementy analiz niezawodności człowieka Typy stanów eksploatacyjnych systemu rozpatrywane w HRA: Dla celów HRA wygodnie jest podzielić stany eksploatacyjne systemu na dwie zasadnicze grupy: normalne stany eksploatacyjne; stany awaryjne. Normalne stany eksploatacyjne obejmują rozruch, wyłączenie oraz eksploatację w granicach założonych przez projekt. Stany awaryjne są skutkiem zdarzeń, które przerywają warunki normalnej eksploatacji systemu. Wyróżnia się przy tym zdarzenia wewnętrzne wywodzące się z uszkodzeń elementów technicznych systemu lub błędów ludzi, stanowiących zarówno elementy tego systemu, jak i zdarzenia zewnętrzne różnego pochodzenia, których zajście jest niezależne od samego systemu, ale wpływa na jego funkcjonowanie. W wypadku instalacji przemysłowych zdarzeniami zewnętrznymi mogą być wszystkie zdarzenia wpływające na funkcjonowanie instalacji w związku z jej lokalizacją (bliskość szlaków komunikacyjnych, rzek, akwenów wodnych, innych zakładów, warunków geologicznych, itp.) oraz ekstremalnymi warunkami pogodowymi (silny wiatr, niska lub wysoka temperatura, itp.). Zadania i zachowanie zadaniowe w HRA Klasyfikacja zadań ludzkich pomaga w: selekcji zadań, rozbiciu na bardziej elementarne podzadania i kroki, doborze odpowiedniej, oprócz modelu, oceny ilościowej błędów, prowadzeniu ocen ilościowych. 45 W zależności od potrzeb można stosować bardziej uproszczone klasyfikacje oparte na mniejszej liczbie parametrów. Takim zbiorem parametrów może być: typ działania - operacje w stanie normalnej eksploatacji, - operacje w stanie awaryjnym, typ zadania - wymagający diagnozowania sytuacji, wyboru alternatywnych rozwiązań, podejmowania decyzji, - realizacja zgodnie z ustalonymi instrukcjami i przyswojonymi wcześniej zadaniami postępowania, typ interfejsu - formalne instrukcje i materiały pisane, - urządzenia monitorujące, - regulatory, zawory, przyciski, itp. (dostępne w miejscu sterowania lub lokalnie). Następujące grupy zadań wykonywane w warunkach normalnej eksploatacji mają istotne znaczenie dla jego bezpieczeństwa: 1. rutynowe działania kontrolne, np. przegląd informacji dostarczanych przez monitory o wartościach parametrów wyznaczających obszar bezpiecznej eksploatacji systemu; 2. zadania prewencyjno-konserwatorskie, np. wymiana uszkodzonego elementu systemu zwłaszcza urządzeń ważnych dla bezpieczeństwa; 3. kalibracje urządzeń ważnych dla bezpieczeństwa systemu; 4. testy po dokonaniu konserwacji i kalibracji urządzeń ważnych dla bezpieczeństwa; 5. przywrócenie stanu wszystkich urządzeń do właściwego reżimu pracy, po testach i konserwacjach - zwykle zmienia się konfigurację systemu dla umożliwienia przeprowadzenia takich testów i konserwacji; 6. zadania związane z odnową - te związane z wykluczeniem odstępstw, np. sprawdzenie wykonanej przez kogoś pracy (rezerwowanie ludzkie), odnotowanie alarmów o niebezpiecznych tendencjach o wartościach parametrów opisujących zakres/ograniczenia pracy systemu, aktywne inspekcje, w których wyznaczona osoba dokonuje inspekcji określonych urządzeń, zwykle kierując się przy tym pisaną instrukcją, i pasywne inspekcje, w których wyszukiwanie odstępstw ma charakter przypadkowy. Zadania związane z kalibracją i przywróceniem stanu operacyjnego urządzeń są szczególnie ważne w analizach HRA, ze względu na to, że błędy w wykonaniu tych czynności mogą spowodować jednoczesną niedyspozycyjność wielu urządzeń, w szczególności zmniejszyć poziom rezerwowania urządzeń ważnych dla bezpieczeństwa. Takie błędy ludzkie stają się tym samym błędami o wspólnej przyczynie (common cause failure, common mode failure - CCF), ponieważ pojedynczy błąd (ludzki) uszkadza więcej niż jeden element/urządzenia systemu. Zadania wykonywane w warunkach normalnej eksploatacji systemu mało wiążą się, jeżeli w ogóle się wiążą, z diagnozowaniem i podejmowaniem decyzji. Zwykle czynności wykonywane w tej sytuacji wynikają z ustalonych strategii eksploatacji systemu, a w szczególności z pisanych instrukcji i harmonogramów wykonywania rutynowych zadań. Sposób wykonywania zadań dzieli się zwykle na: wyuczone odruchy - mniej lub bardziej podświadome działania wynikające z zapamiętanych wzorców zachowania, np. użycie ręcznych narzędzi przez człowieka doświadczonego w ich stosowaniu; 46 wyuczone zasady - wymaga to więcej wysiłku umysłowego w śledzeniu zapamiętanych lub napisanych instrukcji; oparte na wiedzy - jest to ważne w sytuacjach nierutynowych i nie w pełni znanych, gdzie procesy związane z poznawaniem i podejmowaniem decyzji odgrywają istotną rolę. Sytuacje podatne na błędy i wypadki Dokonując oceny zadań dla zidentyfikowania możliwości wystąpienia błędów ludzkich analizujący zwykle poszukuje warunków pracy, które z ergonomicznego punktu widzenia są złe i sprzyjają popełnieniu błędów (Error Likely Situations - ELS). ELS nakładają na człowieka wymagania, które nie są zgodne z jego możliwościami i ograniczeniami. Na przykład każde rozwiązanie konstrukcyjne, które narusza stereotypy, powinno być zaliczone do ELS. Rozwiązanie, które zmusza operatora do zapamiętania wskazań kilku urządzeń monitorujących, żeby na ich podstawie mógł ocenić aktualną sytuację, jest bardziej podatne na błędy, niż wtedy gdy jeden monitor dostarcza informacji, których operator potrzebuje. Sytuacje podatne na wypadki (Accident Prone Situations - APS) są specjalnym przypadkiem ELS, gdzie błędy ludzkie z dużym prawdopodobieństwem mogą powodować obrażenia ludzi, ofiary śmiertelne, zniszczenie sprzętu czy też całego obiektu technicznego. Można zdefiniować również cechy ludzkie szczególnie sprzyjające popełnianiu błędów lub powodowanie wypadków. Badania jednak wskazują, że bardziej opłacalne jest koncentrowanie się w analizach bezpieczeństwa systemów na identyfikowaniu APS i ELS niż na poszukiwaniu takich cech ludzkich. Kategorie błędów ludzkich w HRA W HRA jesteśmy zainteresowani przede wszystkim tymi rodzajami błędów ludzkich, które oddziałują na system. Człowiek może popełnić błąd, jeżeli wykona zadanie niepoprawnie, nie wykona zadania lub nie zdąży wykonać zadania we właściwym czasie. To jest podstawą najczęściej stosowanej w HRA następującej klasyfikacji błędów ludzkich. Błędy pominięcia: pominięcie całego zadania, pominięcie kroku zadania, Błędy wykonania: błędy wykonania: - wybór urządzenia sterującego, - przestawienie urządzenia sterującego do niewłaściwej pozycji, - wydanie niewłaściwego polecenia lub przekazanie niewłaściwej informacji, błędy kolejności: błędy czasu wykonania zadania, - zbyt wcześnie, - zbyt późno, błędy jakościowe: - zbyt mało, - zbyt dużo. 47 7.1.3. Rola czynników kształtujących działanie człowieka Czynniki PSF w dużym stopniu określają, czy działanie człowieka jest wysoko niezawodne, wysoko zawodne lub mieści się pomiędzy tymi dwoma skrajnymi poziomami. PSF dzieli się na trzy kategorie: (1) PSF zewnętrzne w stosunku do człowieka, (2) wewnętrzne PSF - związane z cechami osobniczymi, (3) czynniki stresujące. Zewnętrzne PSF obejmują następujące grupy czynników oddziaływania na człowieka: cechy sytuacyjne dotyczą zwykle więcej niż jednego wykonywanego zadania i odnoszą się do: - rozwiązania architektonicznego miejsca pracy (np. sterowni) i innych obszarów wykonywania pracy oraz połączeń komunikacyjnych między nimi, - jakości środowiska pracy: temperatura, wilgotność, oświetlenie, jakość powietrza, hałas i wibracje, poziom ogólnej czystości, konieczność noszenia ubrań ochronnych, - godzin pracy i przerw w pracy, - zmianowości, - dostępności odpowiedniego sprzętu, narzędzi i materiałów, - obsady (liczba i rodzaj personelu wykonującego pracę), dostosowania/przygotowana do wykonywania zadań na stanowiskach, - struktury organizacyjnej (struktura zarządzania, zakresy odpowiedzialności, kanały komunikacji), zasad polityki w zakresie bezpieczeństwa, kontroli administracyjnej tej polityki, - systemów wynagradzania, nagród, motywacji, zainteresowania dobrą pracą, charakterystyki zadań i sprzętu: - wymagania percepcyjne, - wymagania motoryczne (szybkość, siła, precyzja), - zgodność informacji dostarczanych przez monitory z wymaganiami co do operowania sterownikami, - wymagania co do antycypacji sygnałów/alarmów przy znacznym obciążeniu innymi zadaniami wymagającymi uwagi, - wymagania w zakresie interpolacji informacji i diagnozowania, - podejmowanie decyzji, - złożoność (obciążenia informacyjne), - częstość i powtarzalność zadania, - krytyczność zadania (zwykle wykonujący poświęca szczególnie dużo uwagi takim zadaniom), - wymagania odnoszące się do pamiętania długoczasowego (wyuczone zasady, strategie i ich stosowanie) i chwilowego zapamiętywania informacji (np. ustne polecenia, wskazania instrumentów, monitorów itp.), - wymagania dokonywania przeliczeń arytmetycznych w trakcie wykonywania zadania, - sprzężenie - system dostarcza informacji o skutkach działań podjętych przez człowieka, - zadanie dynamiczne lub wykonywane kolejno zgodnie z instrukcją, - skład zespołu wykonującego zadanie z punktu widzenia podziału zadań i możliwości skorygowania popełnionych błędów (odnowy). Ważnym elementem interfejsu COT są regulatory i urządzenia obsługiwane ręcznie lokalnie w miejscu zamontowania. Większość regulatorów obsługiwanych ręcznie to sterowniki 48 elektryczne różnego typu umiejscowione bądź to w centralnym miejscu (np. w sterowni), bądź lokalnie w bezpośrednim zasięgu urządzeń, których pracą sterują. Innym elementem interfejsu są instrukcje ustne i pisane. Najczęściej spotykane niedostatki instrukcji pisanych, to: poważne braki w treści i formacie, mała zbieżność pomiędzy nazewnictwem stosowanym w instrukcji a elementami paneli, brak jasnego wskazania, w wypadku instrukcji do działań kontrolnych, co jest prawidłową a co nieprawidłową odpowiedzią systemu, schematy i wykazy nie są skorelowane z tematem, nie ma jasności, którą procedurę zastosować w danej sytuacji, utrudnienie operatorowi diagnozowania sytuacji. Czynniki stresujące i stres mogą mieć charakter psychologiczny, fizyczny lub być kombinacją obydwu. Generalnie czynnik stresujący określa się jako zewnętrzną lub wewnętrzną siłę powodującą napięcie umysłowe lub fizyczne. Psychologiczne czynniki stresujące to: nagłość sytuacji, czas trwania, szybkość wykonania zadania, obciążenie zadaniami, wykonanie zadania wiąże się z dużym ryzykiem, zagrożenie, praca monotonna, degradująca lub „bezsensowna”, długie okresy monotonnego czuwania (bez zajścia zdarzeń), konflikt motywacji w odniesieniu do wykonywanej pracy, upośledzenie sensoryczne, rozproszenie koncentracji (hałas, oślepiające światło, ruch, kolory, migotanie), niespójność sygnałów/bodźców. Istnieje związek pomiędzy jakością wykonywania zadania a poziomem stresu psychologicznego. Pokazuje on, że zarówno zbyt wysoki jak również zbyt niski poziom czynników stresujących niekorzystnie wpływa na wykonanie zadania. Obszar niskiego poziomu czynników stresujących jest szczególnie ważny dla zadań monitorowania stanu systemu. Wiąże się to z efektem czuwania w wypadku zadań pasywnych o niskim poziomie sygnałów. Czynniki fizjologiczne obejmują: czas trwania stresu; zmęczenie; ból lub odczuwanie dyskomfortu; głód lub pragnienie; ekstremalne temperatury i poziom wilgotności; ekstremalne wartości ciśnienia atmosferycznego; wysokie przeciążenie; brak tlenu; wibracje; ograniczona reakcja; brak ćwiczeń fizycznych; 49 zaburzenia rytmu pracy serca. Wewnętrzne PSF Pewne wewnętrzne PSF są poza możliwościami minimalizacji ich negatywnego oddziaływania przez wdrożenie odpowiednich zasad kontroli lub zarządzania, jednak większość z nich może podlegać takim wpływom. Podstawowe czynniki wewnętrzne kształtujące umiejętność wykonywania zadania: - dotychczasowe szkolenia i umiejętności; aktualny stan umiejętności; osobowość i parametry inteligencji; motywacja i skłonności; wiedza o wymaganych standardach wykonywania zadania; różnice płci; stan fizyczny; skłonności w wyniku wpływu rodziny, innych osób lub agencji; identyfikowanie się lub przynależność do różnych grup. Najważniejsze kategorie PSF wpływające na bezpieczeństwo systemu Doświadczenie wskazuje, że większość wymienionych wyżej PSF, ważnych dla bezpieczeństwa różni się w zależności od tego, czy dotyczy błędów popełnionych w normalnych warunkach eksploatacji systemu, czy też w jego stanach awaryjnych. Najważniejsze klasy PSF należące do obydwu grup to: I. Normalne warunki eksploatacji 1. Typ operacji potrzebny do przywrócenia właściwego stanu funkcjonalnego po przeprowadzeniu testów, kalibracji i remontów, w wyniku których elementy ważne dla bezpieczeństwa są czasowo odłączone/niedyspozycyjne - ciąg czynności - pisane instrukcje - listy kontrolne - zawieszenie etykiet lub inne formy oznaczania elementów na okres prowadzonych prac konserwacyjnych 2. Czynniki odnowy ważne dla p.1 - rezerwowanie ludzkie - specjalne monitory w sterowni 3. Kontrola administracyjna w odniesieniu do punktów 1 i 2 obejmująca zagadnienia: - jak dobrze zadania są wykonane z punktów 1 i 2 - zależności pomiędzy osobami wykonującymi zadania z punktów 1 i 2 4. Sposób oznaczania stanu dyspozycyjności elementów ważnych dla bezpieczeństwa, lokalnie, poza sterownią II. Po zajściu zdarzenia początkującego stan awaryjny 1. Zakres w jakim potrzebne informacje są bezpośrednio udostępniane personelowi na monitorach sterowni i w materiałach pisanych, aby zredukować konieczność przetwarzania, interpretacji i podejmowania decyzji. 2. Rodzaj i częstość szkolenia personelu w zakresie praktycznej znajomości przebiegu procesów awaryjnych, reakcji systemu i koniecznych działań operatorskich. 3. Zależność pomiędzy personelem sterowni w stanie awaryjnym systemu - skoordynowanie działań zespołu. 4. Poziom stresu psychologicznego wywołanego stanem awaryjnym: - złe wdrożenie wymienionych wyżej trzech PSF 50 - niepewność co do metody zdarzenia (niewystarczające lub sprzeczne informacje) - niezdecydowanie w aspekcie, co czynić (niewystarczające lub sprzeczne instrukcje) - stopień, w jakim urządzenia bezpieczeństwa systemu działają zgodnie z wymaganiami 7.1.4. Ogólne zasady analizy działań człowieka w aspekcie niezawodności i bezpieczeństwa systemu Metody identyfikacji źródeł zagrożenia wynikające z działalności człowieka jako elementu systemu antropotechnicznego oraz analizy błędów ludzkich w aspekcie niezawodności i bezpieczeństwa takich systemów sprowadzają się do realizacji następujących kroków: 1. Opisać cele i funkcje systemu; 2. Opisać charakterystyki sytuacyjne związane z zadaniami wykonywanymi przez człowieka; 3. Opisać cechy wymagane od ludzi/personelu jako elementów systemu; 4. Opisać stanowiska i zadania; 5. Dokonać analizy stanowisk i zadań z punktu widzenia podatności na błędy (ELS); 6. Ocenić prawdopodobieństwo potencjalnych błędów; 7. Ocenić prawdopodobieństwo, że błędy nie będą wykryte lub skorygowane; 8. Ocenić skutki każdego niewykrytego lub nieskorygowanego błędu. Analiza stanowisk i zadań personelu Analiza zadań jest procesem określenia specyficznych zachowań wymaganych od ludzi jako elementów systemu antropotechnicznego. Zadanie jest elementem opisującym realizację jednej z wielu funkcji określonego stanowiska. Analiza zadania powinna być stosowana do każdego rodzaju zadania zarówno do złożonych zadań dynamicznych, związanych z interpretacją i podejmowaniem decyzji (wymagających kognitywnego zachowania się), jak również do zadań wykonywanych krok po kroku zgodnie z instrukcją. Opis zadania poza klasyfikacją typu powinien zawierać powiązania z innymi zadaniami i PSF odnoszącymi się do: (1) cech zadania i sprzętu oraz (2) instrukcji zadaniowych i stanowiskowych. Przyjęty format opisu zadania powinien umożliwiać łatwą identyfikację źródeł błędów potencjalnych. Analiza zadania jest w istocie identyfikacją ELS. Czynniki wyznaczające takie sytuacje można pogrupować zgrubnie w następujący sposób: 1. wymagania w zakresie skaningu urządzenia monitorującego, percepcji ważnych informacji i antycypowaniu sygnałów/zdarzeń, 2. wymagania odnoszące się do pamiętania informacji oraz istnienia sygnałów dla inicjacji działań, 3. złożoność manipulacyjna czynności. Analiza zadań wymaga zatem identyfikacji podstawowych PSF związanych z grupami działań B, C i D przedstawionymi na rys. 6. A B Elementy funkcjonalne człowieka Wewnętrzna pętla sprzężenia C D 51 E Wejście zewnętrzne poprzez sygnały, znaki, uwarunkowania. Urządzenia monitorujęce: Optyczne Akustyczne Inne Komunikowanie się: Ustne Pisemne Warunki środowiska pracy Wejście wewnętrzne poprzez rozróżnianie, zauważanie, uświadamianie Filtrowanie, organizowanie, rozpoznawanie informacji poprzez: Receptory i w pewnym stopniu elementy działania lub procesy poznawcze Procesy i działania poznawcze Reakcja człowieka Przetwarzanie zarejestrowanych informacji włączając w to efekty pamięci, celów, intencji, osobowości (skłonności, motywacje, emocje itd.) interpretacja i podejmowanie decyzji Kontrola pewnych funkcji systemu lub wydanie ustnych / pisemnych poleceń lub przekazanie informacji Skutki dla systemu antropotechnicz nego Właściwe lub niewłaściwe oddziaływanie na system poprzez: Brak działania Przełączniki Zawory Klawiaturę komputera Dźwigi Narzędzia Instrukcje Zewnętrzna pętla sprzężenia Rys. 6. Uproszczony model funkcjonalny człowieka jako elementu systemu COT. Zdarzenia awaryjne, model zachowania się człowieka w aspekcie ocen niezawodności i bezpieczeństwa systemu Dla celów HRA rozróżnia się następujące etapy wymagające ocen zachowania się człowieka/grupy ludzi (operatora systemu): 1. Początek stanu awaryjnego, zajście zdarzenia początkującego taki stan. 2. Percepcja warunków awaryjnych, alarmy, sygnały, wskazania urządzeń monitorujących. 3. Rozróżnianie wskaźników/sygnałów stanu awaryjnego. 4. Interpretacja wyróżnionych sygnałów. 5. Diagnoza wyróżnionych sygnałów. 6. Wybór pomiędzy alternatywnymi diagnozami. 7. Decyzja o podjęciu akcji. 8. Przeprowadzenie akcji. Przedstawione wyżej etapy są projekcją modelu kognitywnego zachowania się człowieka, właściwego dla procesów diagnozy sytuacji i podejmowania decyzji. Prawdopodobieństwo prawidłowej diagnozy zależy od wielu czynników osobowych i wiedzy operatora, uwarunkowań zewnętrznych wynikających z zaistniałej sytuacji, ale także od czasu, jakim dysponuje operator. Metoda dekompozycyjna THERP THERP (Technique for Human Error Rate Prediction) jest metodą służącą do oceny niezawodności człowieka, która została zaproponowana przez Swain'a i Guttmann'a. Została ona opublikowana w 1983 roku i jest obecnie szeroko stosowana w praktyce inżynierskich ocen niezawodności tzw. czynnika ludzkiego. W technice tej zawarto ciekawe podejście, które: pozwala na modelowanie niezawodności człowieka z pomocniczym konstruowaniem drzew zdarzeń (podobnie jak w inżynieryjnych ocenach ryzyka), na podstawie których 52 wyznacza się prawdopodobieństwa sukcesu lub niepowodzenia wykonania określonego zadania przez człowieka lub grupę ludzi, umożliwia uwzględnienie tzw. czynników formujących działanie: PSF, które potencjalnie wpływają na jakość działania operatorów (człowieka lub grupy ludzi realizujących określone zadanie na konkretnym obiekcie). Analiza niezawodności człowieka za pomocą techniki THERP przebiega w czterech podstawowych fazach: (1) Rozpoznanie problemu - Przebywanie na obiekcie (dane topologiczne i funkcjonalne obiektu) - Przegląd informacji od analityków systemowych (2) Ocena jakościowa - Wizyty i rozmowy na miejscu - Analiza zadań - Budowa drzew zdarzeń analizy niezawodności człowieka: (DRZEWA HRA) (3) Ocena ilościowa - Wyznaczenie nominalnych prawdopodobieństw błędów człowieka (BHEP) - Ocena względnego wpływu czynników formujących działanie (PSF) - Ocena zależności działań - Wyznaczenie prawdopodobieństw sukcesu i niepowodzenia - Określenie potencjalnych czynników naprawczych (4) Badanie i wykorzystanie wyników - Przeprowadzenie analizy wrażliwości; - Przekazanie informacji analitykom systemowym. W technice THERP stosuje się do reprezentacji graficznej działań operatora i możliwych błędów drzewa zdarzeń analizy niezawodności człowieka (drzewa HRA): Są one kompatybilne z drzewami zdarzeń stosowanymi w systemowej analizie ryzyka. Drzewa te umożliwiają dekomponowanie zadania na elementarne kroki zadania, dla których są znane dane niezawodności człowieka. Zastosowane podejście dekompozycyjne jest podobne do sposobu analizy niezawodności systemów technicznych. Po zdefiniowaniu poszczególnych zdarzeń, uwzględnionych w drzewach HRA, możliwe jest wyznaczenie wskaźników probabilistycznych sukcesu i niepowodzenia analizowanego zadania. Oszacowanie prawdopodobieństw błędów człowieka metodą THERP Prawdopodobieństwa sukcesu lub niepowodzenia konkretnego zadania wyznacza się na podstawie uprzednio skonstruowanego drzewa HRA, z przypisaniem kolejnym gałęziom tego drzewa odpowiednich prawdopodobieństw błędów człowieka: HEP. W metodzie THERP wartości HEP kolejnych gałęzi drzewa HRA mogą pochodzić z następujących źródeł: bazy danych opisanej w rozdziale 20 poradnika THERP, zbioru danych wyznaczonych na podstawie własnych danych o wypadkach i awariach, zbioru danych uzyskanych na podstawie badań na symulatorach, danych wynikających z subiektywnej oceny. Głównym źródłem danych jest jednak rozdział 20 podręcznika THERP, który zawiera: tabele danych z prawdopodobieństwami i współczynnikami błędu-niepewności, zasady wyjaśniające, jak modyfikować dane ujęte w tabelach dla uwzględnienia czynników formujących działanie (PSF), 53 reguły uwzględnienia zależności pomiędzy zdarzeniami błędów człowieka, co wyraża się poprzez odpowiednią zmianę wartości prawdopodobieństw ciągu zdarzeń niezależnych na prawdopodobieństwa zdarzeń zależnych. Korzystanie z bazy danych metody THERP przebiega następująco: Zdefiniowanie błędu, którego prawdopodobieństwo ma być ocenione. Dla zdefiniowanego błędu poszukuje się w rozdziale 20 poradnika THERP odpowiedniej tabeli, która zawiera bazowe prawdopodobieństwa popełnienia błędu ludzkiego (BHEP). W tabelach tych ujęto np. błędy odpowiedzi (niewłaściwych reakcji) na sygnały alarmowe i szereg innych niepoprawnych działań operatora. Zidentyfikowanie współczynników formujących działanie PSF związanych z rozważanym błędem. powinny być uwzględnione w zależności od warunków analizowanej sytuacji. Modyfikowanie wartości BHEP, wynikającej z reguł podanych przez Swain'a & Guttmann'a, w celu uwzględnienia PSF. Sprowadza się to do mnożenia lub dzielenia nominalnego BHEP przez współczynnik, przez wybrany PSF, np. 3 lub 10, zgodne z zasadami podanymi w poradniku. W konkretnym wypadku, kiedy analityk wyczuwa, że jakieś PSF są szczególnie niekorzystne i ich wpływ wykracza poza granice sugerowane w poradniku, analityk może odwołać się do innej metody szacowania HEP, np. przy pomocy metody APJ (wymagany udział kilku ekspertów). Modyfikowanie HEP, zgodnie z zasadami podanymi przez Swain’a i Guttmann’a, wartości prawdopodobieństwa, dla uwzględnienia tego, że sukces czy niepowodzenie jakiegoś kroku (działania) są zależne od sukcesu czy niepowodzenia poprzednich kroków (działań). Dlatego w metodzie wyróżniono pięć poziomów zależności: od zera (brak zależności) do 5 (zupełna zależność). Po przyjęciu przez analityka odpowiedniego poziomu zależności, HEP wyznaczone zgodnie z punktem są odpowiednio modyfikowane. Wyznaczenie globalnych HEP dla całego zadania na podstawie prawdopodobieństw błędów człowieka oszacowanych dla poszczególnych kroków i po uwzględnieniu czynników naprawy wymaga oceny probabilistycznej drzewa HRA przy zastosowaniu klasycznych zasad obliczania prawdopodobieństw, przez odpowiednie kombinowanie prawdopodobieństw błędów człowieka, uzyskanych dla poszczególnych kroków zadania. Takie globalne HEP dla całego zadania jest następnie przypisane zdarzeniu, polegającemu na popełnieniu błędu przez człowieka, uwzględnionemu w strukturze logicznej modelowania niezawodności układu (systemu). 54 Rys. 7. Prawdopodobieństwo niepowodzenia przeprowadzenia właściwej diagnozy stanu awaryjnego w funkcji czasu diagnozy [w minutach]. Metoda konserwatywnych ocen HRA Analizy powypadkowe. W tym wypadku zanim operator podejmie jakąkolwiek akcję naprawczą musi najpierw dokonać diagnozy awarii. Czas potrzebny do przeprowadzenia diagnozy oblicza się z równania: Td =Tn-Ta gdzie: Td - maksymalny czas dostępny do przeprowadzenia diagnozy; Tm..- maksymalny czas potrzebny do przeprowadzenia diagnozy i wykonania wszystkich działań naprawczych mających na celu zahamowanie rozwoju sytuacji awaryjnej; Ta - czas potrzebny do przeprowadzenia wszystkich działań naprawczych. Maksymalny czas potrzebny do przeprowadzenia diagnozy i działań naprawczych musi być określony na podstawie szczegółowych analiz każdego ciągu awaryjnego. Musi się przy tym brać pod uwagę oszacowania opóźnień rozwoju sytuacji awaryjnej w wyniku takich czynników jak prędkość generowania ciepła, kinetyka reakcji chemicznej a także przepływy substratów lub czynników chłodzących. Takie analizy w ogólności wymagają wsparcia inżynieryjnego. Czas wymagany do przeprowadzenia działań naprawczych Ta zależy od ilości i rodzaju zadań jakie te działania obejmują. Czasy wymagane dla wykonania reprezentatywnych zadań przez operatora, włączając w to czas dojścia, są podane w tabeli poniżej. 55 Tabela 13. Czasy wymagane dla przeprowadzenia zadań reprezentatywnych. Opis działania Wybrać i zainicjować procedurę postępowania, jeżeli nie jest dobrze pamiętana Czas dojścia plus czas manipulacji na głównym panelu sterowni Czas dojścia plus czas manipulacji na drugoplanowym panelu sterowni Czas dojścia plus czas manipulacji urządzeń poza sterownią Stabilizacja procesu a. b. c. Wymagany czas (min.) 5a 1 2 b c Procedurę można uznać za w pełni zapamiętaną przez operatora jeżeli jest wystarczająco często testowana, np. można uznać, że procedury awaryjnego wyłączania instalacji symulowane raz na kwartał będą dobrze zapamiętane. Odpowiednie czasy mogą być oszacowane przez przeprowadzenie odpowiednich pomiarów czasu dojścia. Oszacowanie operatora należy pomnożyć przez 2, jeżeli nie ma innych informacji na ten temat. Można przyjąć 5 min. dla sytuacji jakichkolwiek oszacowań. Po przeprowadzeniu działań naprawczych potrzeba jeszcze odpowiedniego czasu do uzyskania stabilizacji sytuacji. Czas ten należy określić poprzez konsultację z inżynierami procesowymi. Jeżeli nie ma jakichkolwiek dostępnych informacji można optymistycznie przyjąć, że system wraca do stanu poprzedniego natychmiast. Przy tym to założenie należy później sprawdzić. Czas Ta jest sumą wszystkich czasów potrzebnych do wykonania zadań cząstkowych. Został oszacowany zgodnie z powyższą tabelą. Z chwilą wyznaczenia czasów Tm. i Ta możemy określić również maksymalny czas do przeprowadzenia diagnozy. Na podstawie tego oszacowania możemy określić prawdopodobieństwo niepowodzenia przeprowadzenia właściwej diagnozy stanu awaryjnego. Metoda HEART Technika HEART (Human Error Assessment and Reduction Technique) została opracowana przez Wiliams'a w 1985 roku, a następnie zmodyfikowana w 1988 roku. W technice tej uwzględnia się zadania człowieka oraz czynniki ergonomiczne i środowiskowe, które wpływają negatywnie na wykonywanie tych zadań. Każdy czynnik, który potencjalnie wpływa na działanie, jest określany ilościowo, a następnie oblicza się prawdopodobieństwo błędu człowieka, które zależy od iloczynu współczynników związanych z tymi czynnikami. Wyróżnione zadania i nominalne wartości zawodności człowieka ujęto w tabeli 13. Twórcy metody HEART opracowali również tabele, zawierającą zestawienie 38 warunków wpływających niekorzystnie na działanie człowieka wraz z współczynnikami (większymi od 1), które powinno się uwzględnić do modyfikowania wartości prawdopodobieństw nominalnych (wskaźnika zawodności człowieka) dla konkretnego analizowanego przypadku. Przykładowe warunki wraz z wartościami współczynników korekcyjnych podano poniżej: brak czasu dostępnego na wykrycie błędu i jego korekcję (×11), niezgodność modelu rzeczywistości operatora z modelem wyobrażanym przez projektanta (× 8), dwuznaczność w wymaganych sposobach działania (× 5), niedoświadczenie operatora (× 3), konflikt pomiędzy celami bieżącymi a długoterminowymi (× 2.5), warunki do wybrania niewłaściwej procedury (× 2), wysoki poziom emocjonalnego stresu (× 1.3), 56 brak zgodności pomiędzy faktycznym stanem wskaźników a procedurami (× 1.2), wiek personelu wykonującego zadania percepcyjne (× 1.02). Tabela 13. Ogólne zadania i wartości nominalne zawodności człowieka. Ogólne zadania (A) Zupełnie nieznane, wykonywane pośpiesznie bez świadomości możliwych skutków (B) Przywrócenie lub spowodowanie nowego stanu systemu bez nadzoru lub procedur (C) Złożone zadanie wymagające wysokiego poziomu rozumowania i zręczności (D) Prostsze zadania wykonywane szybko lub z niewystarczającą uwagą (E) Rutynowe, dobrze wypraktykowane, szybkie zadania wymagające stosunkowo niskiego poziomu zręczności (F) Przywrócenie lub spowodowanie nowego stanu systemu według procedur (G) Rutynowe, dobrze wypraktykowane, zadania przez dobrze wyszkoloną osobę (H) Odpowiedź na sygnał w sytuacji nadzorującego zautomatyzowanego systemu podającego dokładną interpretację stanu systemu (M) Różne zadania bez znajomości ich opisu Proponowane nominalne wartości zawodności człowieka 0.55 0.26 0.16 0.09 0.02 0.003 0.0004 0.00002 0.03 Wartości kwantyli 5%-95% 0.35-097 0.140.42 0.120.28 0.060.13 0.0070.045 0.00080.007 0.000080.009 0.000006 0.0009 0.0080.11 Przykład: Inżynier niezawodności chce oszacować prawdopodobieństwo niepowodzenia w odizolowaniu obejścia instalacji, co ma być wykonane zgodnie z procedurą, ale niedoświadczony operator stosuje niewłaściwą procedurę, przez co nieświadomie naraża obiekt na duże ryzyko. Stosując uproszczone podejście HEART, wybiera się najpierw z tabeli 13 typ zadania, któremu odpowiada określona wartość zawodności. W rozważanym przypadku jest to typ zadania (F) i nominalna zawodność człowieka (0.003). Uwzględnia się następnie warunki sprzyjające popełnieniu błędu ze współczynnikami korekcyjnymi (zob. skrócone zestawienie powyżej), określa się względną ważność kolejnych warunków (poprzez przyjęcie wartości od 0 do 1) i ocenia wartości współczynników korygujących zawodność nominalną człowieka. Odpowiednie wartości zestawiono w tabeli 14. Tabela 14. Przykładowe czynniki i wartości współczynników korygujących zawodność nominalną człowieka. Czynnik Współczynnik Względna korekcyjny ważność Brak doświadczenia 3 0.4 Niewłaściwa technika 6 1.0 Zła percepcja ryzyka 4 0.8 Konflikt celów 2.5 0.8 Niskie morale 1.2 0.6 Wartość współczynników wypływu (3-1)x0,4+1=1,8 (6-1)x1+1=6,0 (4-1)x0,8+1=3,4 (2,5-1)x0,8+1=2,2 (1,2-1)x0,6+1=1,1 Uwzględniając wartość zawodności nominalnej (0.003 dla typu zadania F) oraz wartości współczynników wpływu z tabeli 14, uzyskuje się wartość zawodności człowieka: 57 q 0.003 1.8 6.0 3.4 2.2 1.1 0.27 Podobne obliczenia można przeprowadzić w razie potrzeby dla oceny wartości granicznych, określonych kwantylami 5% i 95%, przyjmując dla zadania typu F wartości odpowiednio 0.0008 i 0.007 zamiast 0.003 w równaniu podanym powyżej. Uzyska się wówczas wartości odpowiednio 0.072 i 0.63. Jest oczywiste, że wartość zawodności nie może przekroczyć wartości 1 (prawdopodobieństwo) i w razie uzyskania z równania wartości powyżej 1.00, przyjmuje się wartość równą 1. Metoda HEART umożliwia również łatwe określenie względnego wpływu poszczególnych czynników na wartość zawodności. Uwzględniając w rozważanym przykładzie wartości z ostatniej kolumny tabeli 14 uzyska się względny wpływ poszczególnych czynników: Czynnik Brak doświadczenia Niewłaściwa technika Zła percepcja ryzyka Konflikt celów Niskie morale Względny wpływ w % 12 42 23 15 8 Na podstawie podobnych wartości procentowych można wysnuć oczywiste wnioski co do przeciwdziałań mających na celu zredukowanie zawodności człowieka w konkretnym analizowanym przypadku. Wady metody HEART: aktualna wersja metody HEART traktuje zadania w izolacji; nie istnieje model uwzględnienia zależności pomiędzy kolejnymi zadaniami; może powodować to problemy w ocenie błędów człowieka, umieszczonych np. w drzewie zdarzeń; niewyjaśniona jest dostatecznie do tej pory kwestia dotycząca źródeł proponowanych w metodzie HEART liczb (nominalne prawdopodobieństwa błędów i współczynniki korygujące); nie są one właściwie udokumentowane, a ponieważ metoda wyłoniła się z badań ergonomicznych, powinna być zweryfikowana, łącznie z opublikowanymi danymi, przez odpowiedni weryfikujący zespół ergonomistów; inną kwestią jest przyjęcie niezależności czynników; w metodzie HEART przyjmuje się, że czynniki to można traktować jako niezależne; jest to dużą wadą metody i powinno być poddane odpowiednim badaniom. Zalety metody HEART: metoda daje analitykowi możliwość powiązania ważniejszych czynników ergonomicznych związanych z projektowanym system z probabilistycznymi oszacowaniami błędów człowieka; możliwość analizowania systemu z uwzględnieniem aspektów ergonomicznych jest dużą zaletą metody; wskazuje to jednak na ograniczenia w praktycznej przydatności metody, której stosowanie powinno być ograniczone raczej tylko do oceny wariantowych rozwiązań w czasie projektowania systemu; analiza tą metodą jest stosunkowo prosta w porównaniu z innymi metodami. Metoda HCR 58 Metoda HCR (Human Cognitive Reliability) została opracowana przez Hannaman'a i in. (1985). W metodzie tej określa się wartość prawdopodobieństwa popełnienia błędu (rozumianego jako niewykonanego prawidłowo działania skutkującego brakiem odpowiedzi na sytuację) w funkcji deficytu czasu, jaki występuje na wykonanie zadania i typu czynności, z wzoru: t C a ,i t 0,5 P(t ) exp C g ,i Bi gdzie: t - czas dostępny na wykonanie zadania, - czas średni zwykle wystarczający na wykonanie zadania, t0,5 Cei, Cgi, Bi - współczynniki zależne od typu czynności (odruchy. reguły, wiedza), uzyskane z kalibracji modelu na symulatorze treningowym. Uwzględnia się wpływ trzech czynników formujących działanie/niezawodność: - doświadczenie operatora - poziom stresu - jakość ergonomiczna sterowni. Wpływ tych czynników jest uwzględniany w wartości czasu t0,5 w konkretnych warunkach, wg wzoru: t 0,5 t o ,5 nom 1 K11 K 21 K 3 gdzie współczynniki K1, K2 i K3 pochodzą z tabeli 15. Tabela 15. Współczynniki korekcyjne do modelu HCR. Doświadczenie operatora : ekspert, wysokie umiejętności przeciętna wiedza i wyszkolenie nowicjusz, minimalne umiejętności Poziom stresu: sytuacja skrajnego zagrożenia sytuacja potencjalnego zagrożenia sytuacja normalna, brak zagrożenia niska czujność, monotonia Jakość ergonomiczna sterowni: doskonała dobra dostateczna słaba niezwykle zła Współczynnik K1 -0.22 0.00 0.44 K2 0.44 0.28 0.00 0.28 K3 - 0.22 0.00 0.44 0.78 0.92 Dla uproszczenia obliczeń funkcji opisanej wzorem dla czynności typu wyuczonych odruchów (skill), reguły (rule) i wiedza (knowledge) jest często wykorzystywana w formie graficznej, co przedstawia rys. 8. Na osi odciętych oznaczona jest zmienna czasowa. Na osi rzędnych odczytuje się prawdopodobieństwo braku odpowiedzi na sytuację ze strony operatora. 59 Przykład: Należy obliczyć prawdopodobieństwo braku prawidłowej reakcji operatora w sterowni elektrowni gdy: czynności są wykonywane na poziomie odruchów, czas dopuszczalny na wykonanie zadania wynosi 79s, czas średni wykonani zadania wynosi 25s, w tym 10 s na detekcję/diagnozę sytuacji a 15s na sterowanie, operator: dobrze wyszkolony, poziom stresu: potencjalne zagrożenie, jakość ergonomiczna: dobra. Rys. 8. Funkcja niezawodności człowieka wg modelu HCR. (Hannaman i in. 1985) Iloczyn (1+K1)(1+K2)(1+K3) wynosi 1,28 (K1=0, K2=0.28, K3=0). Dla 10 s i 15s czasy skorygowane t0,5 wynoszą więc odpowiednio: 12.8s i 19.2s. Ponieważ czynniki formujące są identyczne w obu zadaniach, łączny czas można przyjąć jako 32s. Ponieważ stosunek czasu dopuszczalnego do średniego wynosi 79/32=2.47, dla tej wartości można odczytać z wykresu wartość prawdopodobieństwa braku reakcji równą 2.9x103. Zbliżoną wartość można oczywiście obliczyć z podanego na początku wzoru. Wady metody HCR: ograniczony zakres zastosowania uwzględniony tylko jeden rodzaj błędu (brak poprawnej reakcji) reguły podziału czynności na odruchy, reguły i wiedzę niezbyt klarowne pomijalny wpływ innych czynników formujących poza czasem konieczny dostęp do symulatora, aby zweryfikować wyniki brak zaleceń korekcyjnych co do niezawodności człowieka w danej sytuacji nie uwzględniona zależność zdarzeń. Zalety metody HCR: prosta i efektywna; uwzględnia również czynności typu reguły i wiedza. 60 Procedura SHARP Procedura nazwana SHARP (Systematic Human Action Reliability Procedure), Hannaman & Spurgin 1984, dotyczy uwzględniania zdarzeń związanych z błędami człowieka w strukturze modelu logicznego systemu. Zgodnie z nią odpowiedzialność za prawidłowe uwzględnienie oddziaływań i błędów człowieka w strukturze modelu logicznego PA.B (głównie drzewa zdarzeń i drzewa błędów) podzielona jest pomiędzy analityka systemu i analityka niezawodności człowieka. Celem SHARP jest dopomożenie tym analitykom w określeniu najważniejszych oddziaływań i błędów, istotnych z punktu widzenia bezpieczeństwa obiektu. Procedura SHARP zawiera 7 kroków. Dla każdego kroku określono cele, informację "wejściową" i "wyjściową" oraz reguły postępowania. Zasadnicze cele poszczególnych kroków są następujące: 1. Definiowanie (Definition) - upewnienie się, czy wszystkie ważne rodzaje oddziaływań człowieka są odpowiednio uwzględnione w analizie. 2. Przesiewanie (Screening) - zidentyfikowanie oddziaływań i błędów, mających istotny wpływ na pracę i bezpieczeństwo obiektu. 3. Rozbicie (Breakdown) - bardziej precyzyjny opts ważniejszych oddziaływań w celu określenia kluczowych czynników ważnych w modelowaniu. 4. Reprezentacja (Representation) - selekcja i zastosowanie techniki modelowania dla istotnych oddziaływań. 5. Ocena wpływu (Impact assessment) - badanie wpływu ważniejszych oddziaływań i błędów człowieka, mających na celu umiejscowienie zdarzenia w strukturze modelu logicznego systemu. 6. Ocena ilościowa (Quantification) - skorzystanie z odpowiednich danych lub metod modelowania w celu określenia prawdopodobieństw błędów; analiza wrażliwości i określenie przedziałów niepewności. 7. Dokumentowanie (Documentation) - zawarcie wszystkich istotnych informacji związanych z oceną niezawodności człowieka w taki sposób, aby było możliwe w przyszłości odtworzenie i zrozumienie analizy. Metoda TESEO Metoda TESEO (wł. Tecnica Empirica Stima Errori Operatori) zaproponowali Bello i Colombari w 1980 roku. Jest to metoda w pewnym sensie empiryczna. Model probabilistyczny został przyjęty głównie na podstawie studiów literaturowych. Model ten przeznaczony jest w zasadzie do szacowania prawdopodobieństw błędów operatora, który został przywołany do wykonania określonego zadania w sterowni obiektu przemysłowego. W modelu techniki TESEO przyjęto, że prawdopodobieństwo błędu operatora zależy od pięciu czynników określanych ilościowo na podstawie zawartości odpowiedniej tabeli: Typu podjętego działania (K1); Czasu dostępnego na przeprowadzenie tego działania; czynnik ten nazwano tymczasowym czynnikiem stresu (K2); Charakterystyki (przygotowania) człowieka -operatora (K3); Stanu emocjonalnego operatora, nazwanego czynnikiem obawy w działaniu (K4); Charakterystyki ergonomicznej środowiska, nazwanej czynnikiem ergonomicznym działania (K5). Prawdopodobieństwo błędu człowieka (PBC) wyznacza się na podstawie wzoru: 61 PBC Q K 1 K 2 K 3 K 4 K 5 Przykład: Operator musi dokonać wyboru linii przesyłu półproduktu sypkiego pomiędzy dwoma zbiornikami i zdalnie otworzyć odpowiednie zawory. W sterowni nie ma wskazań aktualnej pozycji tych zaworów. Sterownia nie jest odizolowana akustycznie, a oświetlenie jest niewłaściwe. Czas dostępny na wykonanie operacji wynosi 3 minuty. Doświadczenie operatora jest przeciętne. Z tabeli metody TESEO przyjmuje się kolejno wartości współczynników, a dla uwarunkowań działania człowieka, zgodnie z niniejszym przykładem, są one: działanie jest rutynowe, wymaga jednak uwagi: K1 =0,01, czas dostępny przekracza 20 sekund: K2 =0,5, doświadczenie i wiedza operatora są przeciętne: K3 = 1, sytuacja jest normalna: K4 =1, czynniki ergonomiczne są bardzo niekorzystne: K =10 s. Dlatego prawdopodobieństwo błędu człowieka będzie wynosiło: PBC Q K 1 K 2 K 3 K 4 K 5 0,01 0,5 1 1 10 0,05 Zalety metody TESEO: technika jest prosta w stosowaniu i umożliwia szybkie przeprowadzenie analizy, zapewnia prostą analizę wrażliwości, to jest badanie wpływu zmian czynników na prawdopodobieństwo błędu człowieka, oceny porównawcze oszacowań PBC za pomocą tej techniki wskazują na dość dobrą zgodność z wynikami uzyskanymi za pomocą innych metod. Wady metody TESEO: brak jest opublikowanych podstaw teoretycznych metody i danych uwzględnionych podczas opracowania modelu, przyjęto, że w każdym przypadku analizy wystarczy uwzględnić pięć czynników, co jest dyskusyjne (nie podano uzasadnienia dla takiego modelu), można kwestionować przyjęte założenie o mnożeniu współczynników określających czynniki wpływające na prawdopodobieństwo błędu człowieka (założenie liniowości modelu). Mimo tych wad technika TESEO dzięki swej prostocie była stosowana w licznych analizach ryzyka obiektów przemysłowych, w tym obiektów chemicznych w USA. Metoda SLIM Metodę SLIM (Success Likelihood Index Method) analizy niezawodności człowieka opracował Embrey ze współpracownikami w roku 1984 ( Brookhaven National Laboratory) w ramach projektu finansowanego przez NRC (Nuclear Regulatory Commission), USA. Opracowano następnie również inne moduły wspomagające przeprowadzanie analiz na bazie metody SLIM: MAUD (Multi-Attributive Utility Decomposition) - London School of Economics oraz SARAH (Systematic Approach to the Reliability Assessment o f Humans) - Humon Reliability Associates. Moduł MAUD jest stosowany do analizy zestawu kilku zadań i oszacowania wskaźników SLI (Success Likelihood Index), na podstawie których wyznacza się prawdopodobieństwa błędów człowieka (PBC). Natomiast moduł SARAH służy do kalibrowania względnych wskaźników sukcesu w celu wyznaczenia kolejnych wartości PBC dla analizowanych zadań. Procedura SLIM obejmuje następujące kroki: 62 1. 2. 3. 4. 5. 6. 7. 8. Zdefiniowanie sytuacji i analiza zadań wykonywanych przez człowieka, Określenie ważniejszych czynników wpływu CW, Ocena i szeregowanie zadań względem wyróżnionych CW, Wyznaczanie współczynników wagowych dla kolejnych CW, Określenie punktów odniesienia i skalowanie kolejnych CW, Obliczenia wskaźników SLI, Konwersja wskaźników SLI na prawdopodobieństwa, Ocena granic niepewności. Normalizowany współczynnik SLI przyjmuje wartości z przedziału [0-1]. 7.1.5. Zasady selekcji metod i technik analizy niezawodności człowieka Istota metodyki proponowanej w niniejszej sekcji sprowadza się do ułatwienia wyboru najodpowiedniejszej techniki analizy niezawodności człowieka wg ustalonych kryteriów, odzwierciedlających preferencje oceniającego oraz zasoby, którymi dysponuje. Przyjmuje się następujące kryteria wyboru metody (Park 1987, Humphreys 1988): 1. dokładność i powtarzalność wyniku, 2. wierność modelowania, 3. użyteczność (uniwersalność, analiza wrażliwości), 4. wykorzystanie zasobów, 5. akceptowalność metody, 6. dojrzałość metody, a ponadto: 7. umiejętności oceniającego, 8. pracochłonność metody, 9. dostęp do danych nominalnych HEP lub możliwość ich zebrania. Definicje i objaśnienia kryteriów: Dokładność i powtarzalność wyniku dokładność przewidywania końcowej wartości HEP (zgodność z wartościami empirycznymi), powtarzalność wyniku przy kolejnych analizach tej samej sytuacji przez różne osoby. Wierność modelowania - wierność odzwierciedlenia sytuacji (zadania) i czynników wpływających na niezawodność człowieka, - zgodność z wiedzą teoretyczną na temat zachowań człowieka w sterowaniu systemami technicznymi, - stopień w jakim metoda wydaje się przekonywująca dla potencjalnego użytkownika, zgodność wyników z uzyskanymi za pomocą innych metod. Użyteczność - możliwość formułowania zaleceń co do środków poprawy niezawodności człowieka w analizowanej sytuacji, - możliwość przeprowadzenia analizy wrażliwości wyniku na zmiany danych wejściowych, - zakres stosowalności metody w różnych gałęziach przemysłu, - zakres stosowalności metody w różnych typach zadań, zachowań i czynności umysłowych operatora. Wykorzystanie zasobów - wymagania co do liczby osób potrzebnych do analizy, ich dostępności, czasu i obsługi 63 potrzebnych do ukończenia analizy, - wymagania co do ilości i formy danych wejściowych (jakościowych i ilościowych), - zdolność metody do dostarczenia wiarygodnych wyników mimo niekompletnych danych - stopień dekompozycji zadania do wykonania potrzebny do przeprowadzenia analizy, - wymagania co do kwalifikacji, wyszkolenia i umiejętności osób biorących udział w analizie. Akceptowalność metody - zaakceptowanie metody przez organizacje nadzorujące bezpieczeństwo, - zaakceptowanie metody przez środowiska naukowe, - zaakceptowanie metody przez ekspertów dokonujących oceny, - możliwość przeprowadzenia audytu i kontroli poprawności przeprowadzonych analiz, - możliwość nadzoru prowadzonych analiz przez ekspertów z zewnątrz. Dojrzałość metody - aktualna dojrzałość techniczna metody, - sprawdzona w praktycznym jej stosowaniu, - zdolność metody do dalszego rozwoju w aspekcie spełnienia w wyższym stopniu jednego lub więcej omawianych kryteriów. Prostota metody / Niezbędne umiejętności oceniającego - jego przygotowanie zawodowe, rodzaj i poziom wykształcenia, - praktyka zawodowa w dziedzinie, z której pochodzi analizowany problem, - doświadczenie w posługiwaniu się technikami analizy niezawodności człowieka, - umiejętność obsługi komputera i oprogramowania do obliczeń. Pracochłonność metody - ilość danych, które trzeba przygotować do wykonania analizy, - stopień skomplikowania prac potrzebnych do wykonania analiz, - stosunek nakładu pracy do uzyskanych efektów, - ilość pracy „ręcznej" wymaganej do analizy. Dostęp do danych nominalnych HEP lub możliwość ich zebrania - dostępność danych wejściowych (wartości bazowe HEP) dla rozważanych typów zadań, - możliwość uzyskania tych danych z ocen, ekspertów lub odległych źródeł (literatura, komputerowe bazy danych), - możliwość pomiarów eksperymentalnych w warunkach zbliżonych do rzeczywistych. Tabela 16. Zestawienie zalet i wad wybranych metod. Metoda Zalety THERP metoda szeroko akceptowana, dobra dokładność, szczegółowość analizy zależna od wykonawcy. SLIM dobre podstawy teoretyczne, metoda szybka, przejrzysta i kontrolowana, szczegółowość analizy zależna od wykonawcy, możliwość analizy czynnikowej. HEART metoda prosta, szybka i łatwa, nadaje się zwłaszcza do oceny projektów, wymagane małe zasoby. Wady duże wymagania co do zasobów, ograniczenie do czynności operatorskich niskiego poziomu, metoda nie daje zaleceń korekcyjnych. subiektywizm ocen konieczna baza danych i komputer, utrudniona eksperymentalna weryfikacja wyników. niezależność czynników formujących niezawodność człowieka, utrudniona eksperymentalna weryfikacja wyników. 64 HCR metoda prosta, szybka i łatwa, jako jedna z niewielu obejmuje również zadania wysokiego poziomu (wiedza), wykorzystuje dane z symulatora. TESEO metoda prosta, szybka i łatwa, możliwa analiza czynnikowa. uwzględnia tylko zależności czasowe i typ zadania, nie obejmuje większości błędów kognitywnych, zbyt uproszczona kategoryzacja zadań. brak zweryfikowanych podstaw teoretycznych, niska dokładność modelowania. Każda z omawianych w niniejszej pracy metod spełnia powyższe kryteria w różnym stopniu, jak również posiada zarówno wady jak i zalety (tabela powyżej). Ponadto każde z kryteriów ma różną wagę dla różnych użytkowników. Dlatego powyższa lista kryteriów może być w pewnych wypadkach niewystarczająca. Przedstawiony poniżej przewodnik do wyboru najodpowiedniejszej metody analizy winien być oceniany z takim zastrzeżeniem. Nie zostały w nim uwzględnione wszystkie znane w literaturze przedmiotu metody, a jedynie te najbardziej popularne. Tabela 17 podaje stopień spełnienia podanych wyżej kryteriów przez wybrane metody, podany w skali od 1 do 5 (1 - ocena najniższa, 5 - ocena najwyższa). Zestawienie to pozwala również na porównanie różnych metod i określenie ich profilu w aspekcie preferencji użytkownika co do konkretnego typu zastosowania. Udział poszczególnych kryteriów w preferencjach potencjalnego użytkownika może być różny. Z tego powodu można zastosować metodę kryteriów ważonych, gdzie wagi kryteriów określają udział każdego kryterium w całości oceny. Tabela 18 pokazuje przykład zastosowania metody kryteriów ważonych dla jednej z metod (podanej w tabeli jako „metoda X"). Tabela 17. Ocena wybranych metod względem kryteriów. Metoda THERP SLIM HEART HCR TESEO Dokładność Wierność Użyteczność Wykorzystanie Akceptowalność Dojrzałość Prostota Pracochłonność Dostępność i powtarzalność modelowania zasobów danych 3 3 3 1 1 3 3 3 1 1 3 5 5 2 4 2 2 5 2 1 5 4 3 2 1 5 4 2 1 1 2 2 5 2 1 5 2 3 1 1 5 2 2 4 5 Tabela 18. Przykład metody kryteriów ważonych. Kryterium Dokładność i powtarzalność Wierność modelowania Użyteczność Wykorzystanie zasobów Akceptowalność Dojrzałość Prostota Pracochłonność Dostępność danych Ocena kryterium 3 Waga 4 4 3 3 5 3 2 1 0.15 0.10 0.05 0.10 0.05 0.15 0.10 0.10 0.20 Ocena łączna 0.60 0.60 0.40 0.15 0.30 0.25 0.45 0.20 0.10 3,05 W powyższym przykładzie wskaźnik preferencji wynosi 3.05. Aby ocenić, jak dalece metoda 65 X może być preferowana w wyborze, należy porównać wynik przy tym samym zestawie wag: z innymi metodami, z maksymalną liczbą punktów możliwą do uzyskania, gdyby wszystkie kryteria uzyskały ocenę 5. Rys. 9 pokazuje przykład mapy preferencji z uwagi na dwa wybrane kryteria: szczegółowość i trudność użycia metody (odwrotność prostoty). Tego typu oceny cząstkowe w praktyce są często wystarczające, gdyż na ogół 2-3 kryteria główne przesądzają o wyborze metody. Rys. 9. Porównanie wybranych metod analizy niezawodności człowieka. 7.2. Błędy o wspólnej przyczynie (CCF) Redundancja i różnorodność rozwiązań mają na celu podniesienie niezawodności i /lub bezpieczeństwa w wielu instalacjach. Trend do stosowania redundancji i różnorodności rozwiązań obserwuje się szczególnie w systemach kontroli i sterowania. Bardzo wysoka niezawodność, osiągana teoretycznie przez redundancję, musi być konfrontowana z pojedynczymi zdarzeniami, które mogą spowodować uszkodzenie zwielokrotnionych komponentów (np. uszkodzenie funkcjonalne wszystkich czujników temperatury w systemie ochronnym może być spowodowane błędną procedurą kalibracji podczas przeglądu). Tego typu zdarzenia zależne, które nie wiążą się bezpośrednio z uszkadzanym elementem, a ocenione są jako bardzo istotne dla działania systemu, nazywa się błędami o wspólnej przyczynie. Źródła błędów o wspólnej przyczynie tkwią w: - błędnych konstrukcjach inżynierskich; - środowisku zewnętrznym; - nie sprawdzonych procedurach operacyjnych. 7.2.1. Rodzaje CCF Istnieje szereg możliwych źródeł zależności pomiędzy elementami zwielokrotnionymi i wynikających z nich rodzajów CCF. W tabeli 19 przedstawiono pełny schemat kategorii przyczyn uszkodzeń zależnych, z uwzględnieniem zdarzeń zewnętrznych (pożar, powódź, silny wiatr, wypadek lotniczy) i wewnętrznych (pożary). 66 Tabela 19. System klasyfikacji uszkodzeń zależnych. Przypadki uszkodzeń zależnych w systemach z redundacją Inżynieria Projekt Konstrukcja NIEDOSTAT NIEDOSTATKI PRODUK INSTALACJA KI FUNKCJONAL CJA I ODBIÓR FUNKCJONA NE LNE Działanie Procedury PRZEGLĄ DY I TESTY DZIAŁANIE Niezidentyfiko wane ryzyko Współzależność kanałów Niefachowa naprawa Błędy operatora Niewystarczaj ące oprzyrządowa nie Wspólne komponenty operacyjne i bezpieczeństwa Niedostatki operacyjne Niewystarczaj ąca kontrola Niewłaściwe składniki Niewłaściwa kontrola jakości Niewłaściwa kontrola jakości Niewłaściwe standardy Niewłaściwe standardy Niewłaściwa inspekcja Niewłaściwa inspekcja Niewłaściwe testy Niewłaściwe testy i odbiory Błędy projektowe Niewłaściw e testowanie Niewłaściw a kalibracja Niewłaściw e procedury Niewłaściw y nadzór Ograniczenia projektowe Środowisko PRZEKROCZE NIA ZDARZENIA Temperatura Pożar Ciśnienie Powódź Wilgotność Pogoda Drgania Trzęsienie ziemi Niewłaściwe procedury Niewłaściwy nadzór Błędy w komunikacji (porozumiewa niu) Przyśpieszenia Wybuchy Naprężenia Pociski Korozja Współpraca Zasilanie elektryczne Promieniowani e Promieniowanie Chemikalia Kontaminacja Obciążenia statyczne Niektóre z wymienionych zdarzeń można rozwijać w analizach zagrożeń poprzez budowanie dla nich modeli logicznych drzew zdarzeń i drzew błędów. Inne rodzaje zależności obejmujące uszkodzenia wspólnych systemów zasilania i funkcjonalne wygodnie jest potraktować jako zdarzenia elementarne w drzewach zdarzeń i uszkodzeń, a następnie dokonać oszacowania prawdopodobieństwa zdarzenia CCF. Jedną z metod szacowania prawdopodobieństwa wystąpienia błędu o wspólnej przyczynie jest Model Współczynnika Beta, najpowszechniej używany model parametryczny. W modelu tym zakłada się, że uszkodzenie każdego komponentu systemu można przedstawić jako sumę składnika niezależnego i składnika o wspólnej przyczynie. i c gdzie: - prawdopodobieństwo uszkodzenia komponentu, - prawdopodobieństwo uszkodzenia komponentu z przyczyn niezależnych, i - prawdopodobieństwo uszkodzenia komponentu z przyczyn zależnych. c Współczynnik beta wynosi: c c i 67 Jeżeli system jest skonstruowany z identycznych elementów redundancyjnych, to błąd CCF dla systemu wynosi . Jako estymatora powszechnie używa się wielkości: nc ni nc gdzie: nc - całkowita liczba uszkodzeń komponentów wywołanych wspólną przyczyną, ni - całkowita liczba uszkodzeń komponentów wywołanych z przyczyn niezależnych. Podstawowe założenie Modelu Współczynnika Beta, że błąd o wspólnej przyczynie spowoduje uszkodzenie wszystkich komponentów redundancyjnych, prowadzi do oszacowań konserwatywnych. Może się zdarzyć, że błąd CCF wywoła uszkodzenie np. dwóch spośród trzech komponentów i system jako całość zachowuje swoją funkcję. Istnieją modele eliminujące to konserwatywne założenie, ale istnieje zbyt mało dostępnych danych pozwalających na ich zastosowanie. 7.2.2. Proste metody uwzględniania CCF w modelach drzew błędów Dla modelowania błędów o wspólnej przyczynie wygodnie jest zdefiniować błąd CCF jako jawne zdarzenie elementarne w modelu logicznym (np. w drzewie błędów). Błąd o wspólnej przyczynie jest tym, który reprezentuje wielokrotne uszkodzenia elementów, biorące początek we wspólnej okoliczności pierwotnej. Na rys. 10 przedstawiono prosty model logiczny systemu o redundancji podwójnej z uwzględnieniem CCF. W sposób jawny, błędy o wspólnej przyczynie uwzględnia się w większości probabilistycznych analiz zagrożeń i bezpieczeństwa. Wchodzą one, jako komponenty analiz drzew błędów, do wynikowych sekwencji awaryjnych lub rozwiązań mówiących o niezawodności systemu. Rys. 10. Modele drzew błędów: bez uwzględnienia CCF i z uwzględnieniem CCF. 68 8. PORÓWNANIE OPROGRAMOWANIA DO ANALIZ DRZEW BŁĘDÓW/ZDARZEŃ DLA ENERGETYKI JĄDROWEJ 8.1. Krótka charakterystyka analizowanych programów Wśród programów objętych niniejszą analizą porównawczą znalazło się w sumie 7 różnych aplikacji i pakietów oprogramowania: RiskSpectrum PSAP RW Edition (v 2.00.00) SAPHIRE (v 7.0) RELEX 2009 (update: 04/2010) ITEM Toolkit (v 7.08.7.3) ITEM QRAS (v 2.2.0) FaultTree+ (v 11.2.3) OpenFTA (v 1.0) Poziom ich zaawansowania, możliwości zastosowania w praktyce, zwłaszcza z punktu widzenia wykorzystania w energetyce jądrowej, a także takie czynniki jak koszt zakupu i obsługi czy warunki szkolenia, są w ich przypadku diametralnie różne, a co za tym idzie, wymagają usystematyzowanego, szczegółowego opisu. Metodologia przyjęta w poniższym opracowaniu, opiera się w głównej mierze na zestawieniu kluczowych, z punktu widzenia potrzeb Państwowej Agencji Atomistyki, parametrów i funkcjonalności. Na tej bazie dopiero dokonana została próba wyciągnięcia rzetelnych wniosków i ocena przydatności, a opierając się dodatkowo na stosunku jakości do ceny, wyprowadzona została rekomendacja konkretnego produktu. Wypada jednak zacząć od wprowadzenia, aby przybliżyć w skrócie każdy program z osobna przez pryzmat historii jego rozwoju oraz środowiska, a więc podłoża, przygotowania eksperckiego na jakim bazuje. W rozdziale tym znajdą się zatem takie informacje, jak: producent i jego doświadczenie, ewentualne referencje i związki z energetyką jądrową; historia rozwoju produktu i zgrubny opis zakresu jego możliwości, a także niekiedy i ciekawostki, wyróżniające go w zestawieniu. 8.1.1. RiskSpectrum PSA Professional RiskSpectrum PSA jest jednym z pięciu wysoce wyspecjalizowanych programów wchodzących w skład całego pakietu noszącego nazwę RiskSpectrum Software Suite. RiskSpectrum PSA to przede wszystkim zawansowane narzędzie do projektowania drzew błędów i zdarzeń, wykorzystywane oficjalnie w blisko połowie elektrowni jądrowych na całym świecie! Oprogramowanie to oferuje bardzo bogaty, a przy tym dość intuicyjny w obsłudze interfejs użytkownika (GUI), pozwalając zamodelować niemalże wszystko począwszy od bardzo prostych drzew błędów z wykorzystaniem podstawowych bramek logicznych typu AND czy 69 OR aż do zaawansowanych struktur łączonych w drzewa zdarzeń, wykorzystując przy tym warunki brzegowe czy tzw. zdarzenia o wspólnej przyczynie (CCF). RS PSA jako zintegrowane narzędzie analiz (RSAT) zostało zaprojektowane z myślą o rozwiązywaniu dużych modeli PSA. Oferuje zatem możliwość obliczenia MCS (Minimal Cut Set), BDD (Binary Decision Diagram), wrażliwości wyników, poziomu istotności zdarzeń elementarnych w badanym systemie, a także analiz parametrów zależnych od czasu. RiskSpectrum PSA zawiera także edytor MCS oraz zaawansowane funkcje do tzw. postprocesingowej obróbki wyników. Najnowsza wersja RiskSpectrum PSA nosi numer 1.1.3 i została wydana w czerwcu 2010 roku. Producentem tego oprogramowania jest firma Scandpower. Scandpower jako firma swój początek datuje na lato 1971 roku, kiedy to pod naciskiem ówczesnego Norweskiego Ministra Przemysłu – Finna Lieda - swoje siły połączyły cztery największe wówczas norweskie spółki: Norsk Hydro, Elkem, Hafslund oraz Årdal & Sundal Verk. Celem tego działania było utworzenie skonsolidowanej firmy konsultacyjno-inżynieryjnej na potrzeby najszybciej rozwijających się wówczas gałęzi przemysłu, a więc przemysłu jądrowego i naftowego. Obecnie Scandpower stara się uchodzić za lidera rynku usług w zakresie oceny bezpieczeństwa oraz wśród dostawców wyspecjalizowanego oprogramowania na potrzeby wymienionych wcześniej gałęzi przemysłu, a także sektora transportu. Scandpower od początków swojego istnienia był zaangażowany w działalność na rzecz przemysłu jądrowego w Norwegii. Kiedy jednak program atomowy zawieszono firma skupiła się na potrzebach gwałtownie rozwijającego się sektora paliwowego. Niemniej jednak nie pozwoliła zapomnieć o sobie na międzynarodowym rynku atomowym, dbając jednocześnie o zachowanie najważniejszych obowiązujących w nim zasad, tj. bezpieczeństwo, wysoka jakość, poważne podejście do zagadnień ochrony środowiska, rozwój wiedzy z zakresu zarządzania ryzykiem. Wzrost zapotrzebowania na tego typu usługi, spowodował dalszy dynamiczny rozwój firmy, która swoje filie otwierała kolejno w Uppsali (Szwecja 1988), Bergen (Norwegia 2000), Stavanger (Norwegia 2001), Houston (USA 2002), Pekinie (Chiny 2002), a ostatnio także w Trondheim (Norwegia) i Goteborgu (Szwecja 2006). Od stycznia 2007 roku Scandpower połączyła swoje siły ze szwedzkim RELCON AB, krajowym liderem rynku w dziedzinie bezpieczeństwa jądrowego i dotychczasowym deweloperem oprogramowania RiskSpectrum. Rezultatem połączenia obu firm było powstanie nowej marki na szwedzkim rynku Relcon Scandpower AB, z biurami w Sztokholmie, Goteborgu, Malmö i Uppsali. Od końca 2009 Scandpower jest również częścią Lloyd’s Register Group, wspólnie tworząc niezależną wiodącą światową organizację zarządzania ryzykiem. Na dzień dzisiejszy Scandpower to 7500 pracowników, z tego 250 wysoko wykwalifikowanych specjalistów pracujących na co dzień w 280 biurach na świecie. 8.1.2. SAPHIRE SAPHIRE to oprogramowanie przeznaczone do realizacji badań w dziedzinie PSA na zwykłych komputerach personalnych. SAPHIRE to skrót od Systems Analysis Programs for Hands-on Integrated Reliability Evaluations, czyli programów do analiz systemów dla 70 zintegrowanych obliczeń niezawodnościowych stworzonych i przekształconych w jedno narzędzie przez U.S. Nuclear Regulatory Commission, a zatem podobnie jak w przypadku RiskSpectrum od początku z myślą o zastosowaniach w analizach bezpieczeństwa przemyśle jądrowym. Program umożliwia operowanie na drzewach błędów i zdarzeń na podstawie danych dotyczących zdarzeniach elementarnych. Pozwala również przeprowadzać analizę niepewności i generować raporty końcowe, przy pomocy których analitycy są w stanie tworzyć opisy nawet najbardziej skomplikowanych instalacji, systemów czy procesów technologicznych – taka jest rekomendacja US NRC. SAPHIRE może być użyty przede wszystkim do: modelowania odpowiedzi elektrowni (czy też konkretnego jej podsystemu) na w2ystąpiemie zdarzenia inicjującego, obliczania częstotliwości uszkodzenia rdzenia reaktora (Core Damage Frequencies CDF), identyfikowania kluczowych elementów wpływających na zniszczenie rdzenia (PSA poziom 1). Program ten można również wykorzystać do oceny awaryjności obudowy bezpieczeństwa poprzez konstruowanie modeli do wyznaczania scenariuszy zdarzeń prowadzących do uwolnień (tzw. fenomenologicznych drzew zdarzeń) w wyniku poważnej awarii reaktora z uszkodzeniem rdzenia (PSA poziom 2). SAPHIRE pozwala wreszcie na realizację analiz zarówno dla zdarzeń wewnętrznych jak i zewnętrznych. W ograniczonym stopniu może być także przydatny w kwantyfikowaniu częstotliwości skutków uwolnienia substancji aktywnych do środowiska (PSA poziom 3). Wszystkie te funkcje sprawiają, że SAPHIRE jest bardzo użytecznym narzędziem technicznym, wymagającym jednak od użytkownika dobrej znajomości idei PSA oraz metod wykorzystywanych do realizacji takich analiz. SAPHIRE jest oprogramowaniem, które ewoluowało wraz z postępem technologii komputerowych. Pierwszą wersję kodu US NRC opracowało już w 1987 roku pod nazwą IRRAS, wprowadzając jednocześnie innowacyjną wtedy metodę rysowania, edycji i graficznej analizy drzew błędów. W kolejnej wersji (1989) pojawiły się moduły do obsługi drzew zdarzeń. Kolejnym przełomem był rok 1990, kiedy to wraz z udostępnieniem do publicznego użytku czwartej wersji wokół oprogramowania utworzono grupę roboczą użytkowników zwaną IRRAS Users Group. Rok1992 przyniósł za sobą kolejne nowości, w tym m.in. możliwość tworzenia powiązań (linkowania) między drzewami błędów i drzew zdarzeń. Pięć lat później SAPHIRE zyskał nowy wygląd adekwatny do interfejsu Win95 oraz możliwość instalacji tzw. wtyczek (plug-in) rozszerzających funkcjonalność programu. Wersja siódma, która podlegała niniejszemu badaniu, została udostępniona w roku 1999. Należy podkreślić, iż badanie to w przeciwieństwie do innych produktów oparte zostało na dokumentacji produktu, gdyż nie było możliwości zainstalowania oprogramowania, nawet w wersji demonstracyjnej. Dostępna obecnie wersja ósma, zawiera szereg ulepszeń, zwłaszcza jeśli chodzi o interfejs graficzny, jednak z braku dostępu doń tylko bardzo nieliczne z jej elementów mogły zostać uwzględnione w niniejszym opracowaniu. Od wersji 6-tej IRRAS jest już oficjalnie nazywany jako SAPHIRE, zmiana nazwy miała podkreślić nie tylko zmianę wyglądu poprzez wprowadzenie przyjaznego dla użytkownika GUI zwanego tu Graphical Evaluation Module (GEM), ale przede wszystkim zintegrowanie wszystkich dotychczasowych funkcji w postaci jednej aplikacji. SAPHIRE sukcesywnie 71 zwiększa swoje zdolności obliczeniowe. Przykładem może być tu informacja, że wersja 7-ma jest w stanie liczyć nawet do 2 mln sekwencji. Ponadto zawiera usprawniony algorytm dzielenia drzew na gałęzie, linkowania (łączenia) drzew oraz raportowania. Jak wspomniano, najmniej informacji jest na temat najnowszej wersji SAPHIRE 8 (2004), która odznacza się całkowicie przebudowanym interfejsem. Z uwagi właśnie na niewystarczający opis, a także na brak dostępu do instalacyjnej wersji programu SAPHIRE 8 został właściwie pominięty w tym porównaniu. Wiadomo jedynie, że posiada on wszystkie funkcjonalności swoich poprzedników oraz ulepszone GUI. 8.1.3. RELEX 2009 RELEX - skrót od Reliability Excellence jak twierdzi producent firma PTC, jest potężnym narzędziem do zarządzania jakością, niezawodnością i ryzykiem. Bogaty, przyjazny i jednocześnie najbardziej ergonomiczny interfejs użytkownika w całym niniejszym zestawieniu, modułowość oraz mnogość opcji to niewątpliwie jego główne zalety. I choć powstał on głównie z myślą o zarządzaniu cyklem życia seryjnych produktów, a nie takich unikalnych obiektów jakimi są przeważnie instalacje (czy też całe elektrownie) jądrowe, to i tu - okazuje się – radzi sobie równie dobrze. PTC ma doświadczenie w współpracy z szeroko rozumianym przemyłem energetycznym, jak również i z samym sektorem jądrowym. Swoje rozwiązania dostarcza do kluczowych klientów w całej Europie. Przez ostatnie ponad 2,5 roku PTC świadczyło swoje usługi i służyło wiedzą ekspercką z zakresu FRACAS (Failure Reporting And Corrective ActionS – raportowanie awarii i działania korygujące) zarówno skandynawskiemu jak i niemieckiemu przemysłowi jądrowemu. Jak zapewnia PTC, ich partnerzy mają pozytywne doświadczenia w implementacji RELEXa jako narzędzia do tworzenia procedur działań korygujących (naprawczych i prewencyjnych) zgodnych ze wskazaniami i standardami opisanymi w takich dokumentach jak IAEA Tecdoc 1580, Tecdoc 1581, Tecdoc 1477, INSAG 23 etc. Dzięki wykorzystaniu RELEX FRACAS ich skandynawscy klienci tj. Vattenfall (EJ Forsmark) oraz E.On (EJ Oskarshamn) przeszli z pozytywnym wynikiem przegląd ekspertów misji OSART (IAEA Operational Safety Assessment Review Team). Co więcej, Vattenfall Europe Nuclear Energy, w swoich dwóch reaktorach jądrowych Brünsbüttel i Krümmel wykorzystuje Relex FRACAS w swojej bieżącej pracy, a ostatnio nawet przy jego pomocy przeszli pozytywnie WANO Peer Review. Dzięki narzędziom FMEA, RELEX umożliwia także korzystanie z metodologii i opisu HAZOPS (Hazard & Operability Studies). Z powodzeniem też udała się implementacja modułu RELEX Fault Tree w zakładach przemysłu jądrowego w Chris Brookes-Mann oraz VT Group Services w Wielkiej Brytanii. PTC (Parametric Technology Corporation) zostało założone w 1985 roku, a obecnie zatrudnia w sumie ok. 5000 pracowników. Jako jedna z największych światowych i najszybciej rozwijających się firm programistycznych, a przynajmniej za taką uważa się samo PTC, dostarcza kompletne rozwiązania z zakresu Zarządzania Cyklem Życia Produktu do ponad 50 tys. klientów przemysłowych, w tym m.in. do takich sektorów gospodarki jak high-tech, lotnictwo i bezpieczeństwo militarne, motoryzacja czy wreszcie przemysł instrumentów medycznych. 72 8.1.4. ITEM QRAS oraz ITEM Toolkit QRAS i Toolkit to dwa niezależne produkty z oferty firmy ITEM Software, działającej na rynku od 1984 roku. Podobnie jak w przypadku pozostałych firm, ITEM Software uważa siebie za uznawanego na całym świecie lidera wśród dostawców inżynierskiego oprogramowania do obliczeń niezawodnościowych. Ich rozwiązania skupiają się głównie na ewaluacji typu RAMS czyli Reliability, Availability, Maintainability and Safety evaluation, czyli obliczeń z zakresu niezawodności, dostępności, utrzymania i bezpieczeństwa. Zgodnie z informacją na oficjalnej witrynie internetowej wiadomo, że na chwilę obecną ITEM Software może się poszczycić wydaniem ponad 7500 licencji na swoje oprogramowanie klientom z 37 krajów świata, w tym istotnych partnerów (nie wymienionych nigdzie z nazwy) z sektora obrony, telekomunikacji, lotnictwa, energetyki atomowej, naftowej, medycznej, elektronicznej, ubezpieczeniowej etc. ITEM QRAS lub też iQRAS - Quantitative Risk Assessment System albo, tłumacząc wprost na polski, system ilościowej oceny ryzyka, swoje zastosowanie znalazł głównie (ale nie tylko) w lotnictwie, sektorze obronnym, opiece zdrowotnej. Jako jego największą zaletę producent podkreśla, że ich opatentowane rozwiązania umożliwiają analitykowi przeprowadzanie w sposób prosty i szybki badań na skomplikowanych schematach, wykorzystujących złożone zależności czasowe w całych sekwencjach zdarzeń. Ilościowa ocena ryzyka, w tym programie, podobnie jak i w większości pozostałych omawianych tutaj programów, jest realizowana przy użyciu graficznego diagramu ciągu zdarzeń (Event Sequence Diagrams) oraz technik analizy drzew błędów (Fault Tree Analysis). Same scenariusze są modelowane przy wykorzystaniu zależności czasowych oraz zależności wynikających z logiki elementów w schemacie. A wynik takiej analizy umożliwia przede wszystkim rozpoznanie wartości ryzyka, przekraczających dopuszczalne normy. ITEM ToolKit jest krokiem naprzód w porównaniu do iQRAS, jest bowiem całym pakietem komplementarnych modułów do analiz typu RAMS choć w głównej mierze z przeznaczeniem dla urządzeń czy instalacji elektrycznych i mechanicznych. W skrócie jest to zintegrowana platforma, oferująca skalowalne procesy, która pozwala jednocześnie zaoszczędzić czas i zasoby. Nie bez przyczyny podkreśla się tu modułowość Toolkit-a. Trzeba bowiem pamiętać, że powstał on na bazie niezależnie rozwijanych do tej pory aplikacji. Zadaniem projektantów Toolkit-a było ich zintegrowanie i zapewnienie pełnej konwersji danych uzyskanych za pomocą jednego modułu do drugiego. I trzeba przyznać, że wyszło im to na tyle dobrze, że pierwsze uruchomienie daje użytkownikowi poczucie pracy w jednej a nie kilku aplikacjach naraz. Modułowość ma dodatkową zaletę z punktu widzenia klienta, można by rzec przewagę, nad opisywaną tu konkurencją. Otóż ITEM Toolkit można zakupić zarówno w postaci całego pakietu, jak również i poszczególnych modułów, w dowolnej konfiguracji! 73 8.1.5. FaultTree+ Oprogramowanie FaultTree+, jest kolejnym przykładem potężnego zintegrowanego narzędzia do przeprowadzania pełnych analiz niezawodnościowych, w tym równoczesnego tworzenia i obliczeń drzew błędów i zdarzeń, a także modeli Markowa. Oczywiście w razie potrzeby każda z tych analiz może być realizowana niezależnie. FaultTree+ jest w stanie bardzo wydajnie przeliczać drzewa składające się nawet z 20 000 bramek i 20 000 zdarzeń elementarnych, choć nie oznacza to wcale, że nie poradzi sobie i z większymi schematami. Program został napisany z myślą o użytkownikach firmy Microsoft, stąd też jego pełna kompatybilność z MS Windows oraz pakietem MS Office. Jak już wspomniano FaultTree+ jest w stanie wykonywać obliczenia na dużych i skomplikowanych drzewach, dzięki czemu bez problemu uzyskuje się wyniki w postaci najbardziej prawdopodobnej ścieżki propagacji awarii (full minimal cut representation) prowadzącej do zdarzenia szczytowego. FaultTree+ dostarcza też narzędzia do analizy skutków zdarzeń o wspólnej przyczynie (CCF), oceny istotności zdarzeń elementarnych w układzie (importance), niepewności i wrażliwości działania instalacji. FaultTree+ składa się w sumie z trzech modułów: Fault Tree Analysis Event Tree Analysis Markov Analysis – który pozwala ponadto badać dyskretne stany systemu, a także możliwe przejścia między nimi. Producentem tego oprogramowania jest firma Isograph założona w 1986 roku. Przez ponad dwie dekady swoją reputację budowała na wydajności, dokładności, stabilności i odporności swoich produktów. Tym sposobem Isograph stał się jednym ze światowych liderów oprogramowania typu RAMS, a jego produkty są w użyciu w ponad 7000 zakładów na całym świecie, często w bardzo zaawansowanych projektach. Isograph ma swoje biura w okolicach Manchester-u (Wielka Brytania) oraz w Irvine (USA, Kalifornia), a rzesza ekspertów z dziedziny niezawodności, inżynierów, matematyków, pracujących tam na co dzień wciąż nieprzerwanie dba o ciągły rozwój swoich aplikacji. Produkty marki Isograph są w szerokim użyciu w przemyśle kolejowym, motoryzacyjnym atomowym, czy wreszcie obronnym oraz lotniczym. Ich zastosowanie, jak twierdzi Isograph, pozwala podnieść poziom bezpieczeństwa i niezawodności. Służą one też do optymalizacji procedur utrzymania obiektów oraz do podnoszenia osiągów dostępnych aktywów w sektorze usług, w przemyśle petrochemicznym, a także górniczym. Znajdują też zastosowanie w środowiskach akademickich kształcących przyszłych inżynierów niezawodności. 8.1.6. OpenFTA Ostatnim, aczkolwiek wcale nie mniej ciekawym, choć na pewno bardziej ograniczonym w swoich możliwościach w porównaniu do konkurencji w całym tym zestawieniu jest OpenFTA. OpenFTA to produkt, a w zasadzie projekt „open-source”, stanowiący podstawę technologiczną dla komercyjnego odpowiednika o nazwie Formal-FTA tego samego producenta, czyli firmy Auvation. Należy tu zaznaczyć, że program ten jest darmowy, dostępny na stronie producenta na zasadzie GNU General Public Licence). 74 Autorzy OpenFTA twierdzą, że ich produkt jest zaawansowanym narzędziem do budowania drzew błędów. Faktycznie OpenFTA służy do tworzenia (aż i tylko) drzew błędów. Pozwala tworzyć drzewa za pomocą bardzo przejrzystego GUI, pozwala także obliczać ścieżki propagacji awarii i testować dane metodą symulacji Monte Carlo. Nie ma też ograniczeń natury ilościowej w kontekście wielkości drzewa, ale na tym praktycznie jego możliwości się kończą. Dlaczego został zatem umieszczony w zestawieniu? Otóż przyczyny są co najmniej trzy. Po pierwsze sama idea otwartego oprogramowania jest tu dość ciekawa i warta wspomnienia. Po drugie OpenFTA służy tu jako punkt odniesienia do wszelakich porównań z pozostałym analizowanym oprogramowaniem, zwłaszcza w kontekście stosunku jakości do ceny, odpowiadając na pytanie, czego można oczekiwać za darmo. I wreszcie po trzecie - tylko OpenFTA został zaprojektowany tak, by można go było uruchomić bez względu na system operacyjny (Windows, Linux, Mac OS). Wypada może dodać jeszcze, że firma Auvation ma swoją siedzibę w Cardiff (Wielka Brytania), a założona została w 1992 roku. Ponadto zgodnie z informacją na oficjalnej stronie internetowej, posługuje się certyfikatem jakości ISO-9001:2008/TickIT by Lloyd's Register Quality Assurance. Niestety niewiele wiadomo na temat samej współpracy Auvation z dużym przemysłem, a tym bardziej z przemysłem jądrowym. 75 8.2. Analiza porównawcza oprogramowania Poniższe tabele prezentują wyniki analizy porównawczej oprogramowania do PRA. Legenda: (*) Informacja opracowana w oparciu o help, manual lub stronę producenta danego software’u (k) Informacja zdobyta na drodze konsultacji z przedstawicielem handlowym firmy. Analizowane oprogramowanie Strona WWW Kontakt (e-mail) Licencja Wersja analizowana ITEM Toolkit (v 7.08.7.3) ITEM QRAS (v 2.2.0) http://www.itemsoft.com/ http://www.itemsoft.com/ [email protected] Demo (30 dni) [email protected] Demo (30 dni) 76 RiskSpectrum PSAP RW Edition (v 2.00.00) http://www.scandpower.co m/en/risk/ [email protected] Trial RELEX 2009 (update: 04/2010) http://www.ptc.com/produ cts/relex/ [email protected] Evaluation /koszty Pełna wersja (k) € 17570,96 (FL) (k) € 37790,54 (FL) (k) € 62000 (ceny i warunki przy założeniu obsługi oprogramowania przez pięciu jednoczesnych użytkowników) Każdy moduł podlega odrębnej licencji. Koszt oprogramowania jest zawsze ustalany indywidualnie. Reszta tak samo jak w ITEM Toolkit. Licencja wystawiana jest na organizację. Oprogramowanie dostarczane jest na płytach DVD z tzw. kluczem USB. Oprogramowanie może być zainstalowane na dowolnej liczbie komputerów, niemniej jednak jego uruchomienie wymaga użycia klucza USB wpiętego do danego komputera lub komputera podpiętego do sieci LAN z współpracującej z tym kluczem. Uaktualnienia i koszty dodatkowe Istnieje możliwość zakupu tzw. “ licencji pływającej” (floating license), umożliwiającej instalację oprogramowania na serwerze, a stamtąd dalej na dowolnej liczbie stacji roboczych (oczywiście z ograniczeniem dla określonej liczby jednoczesnych użytkowników na konkretny moduł) (k) W ramach licencji (k) Tak samo jak dla użytkownikowi ITEM Toolkit przysługuje pełne wsparcie techniczne m.in.: Zmiany na serwerze Uaktualnienie GUI Dostawa nowych podręczników 77 (k) Opłata licencyjna jest jednorazowa. Aby korzystać z coroczonych uaktualnień i wsparcia technicznego należy podpisać dodatkowo “support agreement”. Opłata za korzystanie z tej usługi to € 4078 (dla pojedynczej licencji), € 8825 (dla 5-ciu). (k) Licencja typu Enterprise na wszystkie dostępne moduły dla 5 użytkowników to koszt $224400 Konsultant zaleca wcześniejsze przedyskutowanie i dopasowanie aplikacji do potrzeb klienta. (k) Koszt rocznego pakietu wsparcia technicznego (w tym uaktualnień oprogramowania) dla powyższego pakietu to: $43380 Szkolenia 5 niezależnych kursów: ITEM ToolKit Workshop (3 dni) Advanced Reliability Topics (3 dni) Safety Modeling (3 dni) Introduction to Fault Tree Analysis (2 dni) Risk Assessment (3 dni) Nie ma kursu specjalnie dla ITEM QRAS, ale oferta firmy umożliwia korzystanie z kursów wymienionych wcześniej dla ITEM Toolkit. Koszt szkolenia liczony tak samo jak dla Toolkita. (k) Kursy odbywają się na ogół w Szwecji dwa razy do roku, ale na specjalne życzenie instruktor może przyjechać do Polski (k) Koszt takiego szkolenia dla grupy do 6 osób liczony jest na zasadzie: € 2400/dzień + koszty podróży. Szkolenie może się odbyć u nas w kraju. Osoby po takim kursie będą w stanie samodzielnie doszkalać się w oparciu o dostarczone przez firmę podręczniki i ćwiczenia. Rok wydania/wprowadzenia produktu 2010 2 poziomy: RiskSpectrum FTA and PSA Basic Training Course (4 dni) (€ 8050) RiskSpectrum PSA Advanced Training Course (3 dni) (€ 2300) Szkolenia zarówno grupowe jak I indywidualne, dzięki platformie PTC University. Program szkoleń podzielony został na 16 grup tematycznych, z czego 12 do przerobienia we własnym zakresie (eLearning) i 4-ech w postaci warsztatów o różnym wymiarze czasowym (2-4 dni). Przeciętny koszt warsztatu: $1350 (k) Producent zaproponował udział w dwóch szkoleniach: Relex 2009 Reliability Prediction Best Practices Relex 2009 FRACAS Best Practices oraz konsultacjach: PTC Implementation Consultant Za łączną sumę: $33240 2009 (manual z 2006) 78 2003 Szkolenie może odbyć się u klienta. 2009 Wymagania sprzętowe i software’owe Microsoft Windows® Vista, XP, 2000 lub 95/98, Microsoft Windows® NT® 4.0 (SP6 i późniejsze). Kompatybilne z MS Windows 7 Microsoft Office® 2007, 2003, 2000 lub 97. Intel Pentium® II or AMD K6-II 450MHzbased PC lub szybsze. 128MB RAM (256MB lub wyżej rekomendowane). 200MB wolnego na dysku. 17" monitor (1280 x 768) Mysz Napęd CD. Microsoft® Windows® 2000, Microsoft® Windows® XP , Microsoft® Windows NT® 4.0 (SP6 lub nowesze). Kompatybilne z MS Windows 7 Microsoft® Office® 2000 / 2005. Intel® Pentium® 4 lub wyżej. 1 GB RAM, większa przestrzeń rekomendowana. 200MB wolnej przestrzeni dyskowej. 17" monitor lub większy do prawidłowego wyświetlania parametrów i grafik w rozdzielczości minimum 1280 x 768. Mysz i napęd CD. MS Windows 95, MS Windows 98, MS Windows NT 3.51, a nawet MS Windows 3.1 z zainstalowanymi dodatkami Pentium 166 lub szybszy 11 MB wolnej przestrzeni dyskowej 8 MB RAM, rekomendowane więcej Mysz Monitor (800x600) Serwer baz danych: Windows 2000 (SP 4), 2000 Server (SP4), XP (SP3), 2003, 2003 Server, Vista (SP2), 2008 Server lub 7 Intel Pentium 4 (2 GHz) 1 GB RAM HDD 1,5 GB 1024x768, 16-bit napęd CD Aplikacja kliencka: OS identyczny z tym dla serwera Intel Pentium 4 (2 GHz) 512 MB RAM HDD 1 GB 1024x768, 16-bit Ogólna charakterystyka Instalacja programu i oprogramowanie dodatkowe 5 typów instalacji: 4 wersje: Standalone - na Standalone - na odizolowaną stację odizolowaną stację roboczą roboczą Network Server - pełna Network Server - pełna instalacja na serwerze instalacja na serwerze 79 Banalnie prosta. Instalacja z podziałem na pojedynczego lub wszystkich użytkowników danej stacji roboczej. Łatwa i stosunkowo szybka Możliwości wymiany danych z innymi aplikacjami (np. eksport do arkusza MS Excel) Pliki przykładowe/ Sample z dostępem dla licencjonowanych użytkowników License Server instalacja samego serwera licencji, oprogramowanie po stronie stacji roboczych Network Client instalacja aplikacji po stronie klienta serwera View-Only Client klient do przeglądania wyników Można wczytywać pliki z modelami konkretnych zdarzeń (*.itf), daje też możliwość eksportowania modeli awarii do formatów tabelarycznych (np. *.xls, *.csv) Tak (w tym m.in. LOCA) z dostępem dla licencjonowanych użytkowników License Server instalacja samego serwera licencji, oprogramowanie po stronie stacji roboczych Network Client instalacja aplikacji po stronie klienta serwera Import i export do: MS Access MS Excel (format zapisu b.d.) Ponadto export do: Tekst preformatowany MS Word (obraz) (*) Tak (k) Import i export do: *.rsa (plik ASCII), *.xls (MS Excel), *.xml Export: BOM, TXT z delimiterami, stare i nowe formaty MS Access i Excel oraz XML Tak (w tym przykład drzewa awarii charakterystycznego dla EJ) 80 Import: TXT, MS Access, MS Excel, XML Bezpośrednie wklejanie tabel z danymi i wynikami analiz do MS Excel Tak (brak przykładów dla EJ) Budowanie drzew błędów/zdarzeń Stosowane elementy: możliwe atrybuty elementów, stosowane funkcje (modele) rozkładów prawdopodobieństwa, 9 typów bramek logicznych 5 typów zdarzeń elementarnych Dla bramek: typ, nazwa, opis. Dla zdarzeń: typ, nazwa, opis, definicje awaryjności i dostępności oraz CCF (bardziej przejrzyste w definiowaniu w porównaniu z kwantyfikacją stosowaną w QRAS) i więcej O ustalonej wartości (Fixed), Średniego czasu do wystąpienia uszkodzenia (MTTF), Dla stanu bezczynności (Dormant), Dla stanu ciągłej gotowości (Standby), Weibulla, Weibulla (na 3 parametrach), Normalny logarytmiczny (LogNormal), Normalny (Normal), Gamma, 9 typów bramek logicznych 5 typów zdarzeń elementarnych Dla bramek: typ, nazwa, opis. Dla zdarzeń: typ, nazwa, opis + definicja kwantyfikacji 7 typów bramek logicznych 3 typy zdarzeń elementarnych Opcje o identycznych właściwościach jak w ITEM Toolkit, z tymże lepiej pogrupowane wizualnie. Bardziej przystępna nomenklatura poleceń. O ustalonej wartości (Fixed), Eksponencjalny (Exponential), Częściami ekspoknencjalny (Piecewise Exponential), Weibulla Logarytmicznie normalny (Lognormal), Gamma, Beta, Normalny (Normal), Jednostajny (Uniform), Logarytmicznie jednostajny (Loguniform), Wartości dyskretnych (Discrete) 15 typów bramek logicznych 4 typy zdarzeń elementarnych Standardowy opis: nazwa, typ 81 W module do budowania drzew błędów istnieją następujące modele: Dla ustalonej wartości prawdopodobieństwa (Constant Probability), Ze współczynnikiem awaryjności lub średnim czasem między awariami (Failure Rate/MTBF), Częstotliwości (Frequency), Awarii z możliwością naprawy (Failure with Repair), Awarii z okresowym Beta, Dwumianowy (BiNominal), Chi-kwadrat (ChiSquared), Poissona, Zmodyfikowany Poisson do niezawodności, Jednostajny (Uniform), Logarytmicznie jednostajny (LogUniform). Model zdarzenia inicjującego gałąź drzewa awaryjnego (ET Initiator) uwzględnianie zależności czasowych, Tak uwzględnianie cyklu monitoringu i napraw (k) Tak, w module Maintain CCF inne Tak Łatwość definiowania niedostępności i częstości awarii, a także CCF; Możliwość zdefiniowania przeglądem (Failure with Periodic Inspection Ponadto w module Weibull dostępne są: Weibulla, Logarytmicznie normalny (Lognormal), Normalny (Normal), Gumble’a- (dolny), Gumble’a+ (górny), Eksponencjalny (Exponential), Rayleigha, Gamma, Logistyczny (Logistic), Logarytmicznie logistyczny (LogLogistic) Aktywacja zdarzenia z opóźnieniem lub przy zastosowaniu funkcji niezawodności w czasie Nie Tak Tak Tak Tak (moduł: Maintainability) Tak (*) Możliwość zdefiniowania m.in. wymaganego wydarzenia inicjującego czy maksymalnej liczby rozgałęzień/ podzbiorów Tak Nie dotyczy Tak Nie dotyczy 82 Korzystanie z bibliotek danych niezawodnościowych m.in. wymaganego wydarzenia inicjującego czy maksymalnej liczby rozgałęzień/ podzbiorów Tak, można tworzy ć zarówno własne biblioteki, jak również korzystać z tych wbudowanych, aczkolwiek te wbudowane są spoza tematyki EJ (k). Zasadniczo własne biblioteki lub zgodnie z zapewnieniami przedstawiciela firmy ITEM, możliwość zaimportowania bazy EIREDA (k) Zgodnie z zapewnieniami przedstawiciela firmy ITEM, możliwe jest zaimportowanie bazy EIREDA Możliwość budowania własnych diagramów, zestawów danych i bibliotek do wtórnego wykorzystania oraz manipulowania częściami drzew Możliwość tworzenia własnych bibliotek zdarzeń (zapisywania ich do oddzielnych plików); Możliwość tworzenia zdarzeń i bramek typu globalnego (do powtórnego użycia) Ocena interfejsu do budowania drzew Możliwość zwijania i rozwijania gałęzi drzewa dla większej przejrzystości Przejrzyste GUI; Intuicyjna obsługa; Możliwość dowolnego kolorowania elementów, a Możliwość tworzenia własnych bibliotek zdarzeń; Możliwość tworzenia tylko zdarzeń globalnych; Możliwość zwijania i rozwijania gałęzi drzewa dla większej przejrzystości Przejrzyste GUI; Intuicyjna obsługa; Możliwość dowolnego kolorowania elementów, a 83 Brak bibliotek w standardowej instalacji. Na żądanie klienta dostarczają tzw. „T-Book data”. “T-Book” jest bazą danych niezawodnościowych zebranych z elektrowni jądrowych Europy Północnej. Właścicielem T-Booka jest TUD Sweden Możliwość budowania diagramów , jak również możliwość manipulacji czy zwijania gałęzi. Możliwość tworzenia własnych bibliotek zdarzeń. (*) Tak Bogata biblioteka o uszkodzeniach elementów (400 000) NPRD: 13 000+ EPRD: 17 000+ Biblioteki użytkownika Tak jak i w pozostałych badanych programach możliwość budowania drzew jest bardzo intuicyjna (po uprzednim skonfigurowaniu obszaru roboczego). Proste łamanie drzewa. Budowanie drzewa nie stanowi problemu i nie odbiega praktycznie niczym od aplikacji Bardzo przejrzyste GUI, z możliwością zawężania ilości opcji w zależności o poziomu złożoności Maksymalna ilość elementów drzewa także wprowadzania własnych ikon Nie dotyczy także wprowadzania własnych ikon Nie dotyczy pakietu ITEM projektu Nie dotyczy Nie dotyczy Analiza drzew błędów/zdarzeń Wyznaczanie nominalnych przekrojów drzewa (MCS minimal cut sets): wyznaczanie i rozwiązanie równań boolowskich Wyznaczanie wartości prawdopodobieństwa realizacji minimum awaryjnego, przejść pomiędzy stanami oraz znaczenia zdarzeń elementarnych w drzewie Możliwości wykonywania analiz zachowania się systemu w czasie Tak Tak Tak Tak Tak (w tym kolorowanie ścieżki zdarzenia krytycznego) Tak Tak Tak Tak (ale wersja trial nie umożliwia przeprowadzenia takiego badania) Tak Tak Między innymi: Zawodność [Unreliability(t)], Niezawodność [Reliability(t)], Niedostępność [Unavailability(t)], Współczynnik awaryjności [FR(t)] Tak, za pomocą modułu Life Cycle Cost (analiza kosztów) oraz Weibull (niepewność wyników) Tak Możliwości wykonywania analiz wrażliwości i niepewności wyników (k) Tak (k) Zgodnie z zapewnieniem przedstawiciela handlowego firmy ITEM dostępne są co najmniej: Zawodność [Unreliability(t)], Niedostępność [Unavailability(t)] Tak Możliwości uwzględnienia błędów ludzkich Tak Tak Zawodność [Unreliability(t)], Niedostępność [Unavailability(t)], Współczynnik awaryjności [FR(t)] 84 Określanie prawdopodobieństwa warunkowego stanów końcowych w "drzewie zdarzeń" oraz ich prawdopodobieństw bezwarunkowych, biorąc pod uwagę prawdopodobieństwa wystąpienia niepożądanych zdarzeń przypadkowych określonych w "drzewie błędów". Tworzenie wykresów F-N (przedstawiających na płaszczyźnie krzywe poziomu ryzyka w funkcji częstości - F i skutków - N) Sposób prezentacji wyników (k) Tak Tak Tak (k) Tak, w kontekście (k) Tak, w kontekście (k) Standardowa wersja bezpośredniego zagrożenia bezpośredniego zagrożenia oprogramowania nie dla zdrowia ludzkiego dla zdrowia ludzkiego posiada tej opcji. Producent zachwala w tym miejscu dodatkowy moduł o nazwie „Consequence Matrix” i zaznacza, że może być on użyty do analizy typu PSA 3-ego poziomu. Tabele, Wykresy, Tabele/Wykresy Zestawienia tabelaryczne Kolorowanie diagramów oraz wykresy Tak (choć funkcja ta jest wyłączona w wersji ewaluacyjnej) (k) Konsultant co prawda zapewnia, że jest taka opcja, ale w swoim opisie wymienia funkcje nie spełniające bezpośrednio tego kryterium. Powołuje się także na funkcje niedostępne w badanej wersji oprogramowania Tabele/wykresy podobnie jak w ITEM Toolkit Inne uwagi Wersja demo pracuje płynnie; Istnieje także możliwość przeprowadzenia analizy na własnym modelu Wersja demo ma tendencję do zamykania programu bez powodu i możliwości zapisu Łatwiejszy dostęp do informacji w pomocy, i dobry opis (np. skumulowanej Pomoc (z 2006 r.) nie pokrywa się w pełni z funkcjami programu (z 2009 r.) 85 Interesującym jest sposób budowy: najpierw systematyczne tworzenie biblioteki elementów, które dopiero w drugiej kolejności łączy się w pewną strukturę. Dostępna wersja programu daje duże możliwości w porównaniu z pozostałymi. Daje m.in. możliwość archiwizacji otwierania i zapisu plików drzew Możliwość zabezpieczenia projektu hasłem dystrybuanty – ang. CDF) Nieoficjalnie koszt według przetargu zorganizowanego przez WAT na dostawę kompletnego oprogramowania z licencją dla 20 użytkowników to: >87 000 PLN (netto) (4350 PLN/user) http://przetargi.money.pl/d ostawa;oprogramowania;it em;toolkit,info,900851.ht ml Możliwość obliczania kosztów naprawy awarii Możliwość rysowania konkretnych układów z użyciem ilustracji modelowanych obiektów RELEX współpracuje z Vattenfallem i E.Onem 86 Analizowane oprogramowanie Strona WWW Kontakt (e-mail) Licencja Wersja analizowana /koszty Pełna wersja (5-ciu jednoczesnych użytkowników) Uaktualnienia i koszty dodatkowe Szkolenia FaultTree+ (v 11.2.3) http://www.isographsoftware.com/ftpover.htm [email protected] Demo (k) Istnieją dwa warianty licencji: standalone (przypisana do konkretnego PC) network server licence (gdzie software można zainstalować na dowolnej liczbie PC-tów, określając z góry maksymalną liczbę jednoczesnych użytkowników). W obu przypadkach globalny koszt licencji wynosi €23520. (k) Licencja ma charakter trwały, nie wymaga odnowy. Update (z poziomu strony internetowej producenta) i wszelka pomoc techniczna dostępna opcjonalnie na żądanie klienta (roczna opłata – 15% od wartości licencji) 2 rodzaje: Introduction to Reliability Workbench Comprehensive FaultTree+ Workshop OpenFTA (v 1.0) http://www.openfta.com/ SAPHIRE (v 7.0 oraz 8.0) saphire.inl.gov [email protected] Darmowe GNU/GPL Darmowe [email protected] Tylko podręcznik (k) Licencja jest przyznawana na całą organizację. Zgodnie z zapewnieniem konsultanta wystarczy wypełnić wskazany formularz by bezpłatnie uzyskać określoną (z góry) liczbę kopii oprogramowania. Projekt nierozwijalny dalej. Wsparcie za pośrednictwem forum na stronie producenta. (k) Aby uzyskać pomoc techniczną należy się zarejestrować za pośrednictwem strony producenta. Roczna opłata za jednego użytkownika to: $900 Nie (k) Koszt: $10000 Czas: 3,5 dnia Trening może się odbyć w Polsce. 87 (razem 2 dni) (k) Istnieją dwa warianty szkoleń (oba dwudniowe) Rok wydania/wprowadzenia produktu Wymagania sprzętowe i software’owe w siedzibie firmy w Warrington (szkolenia organizowane co miesiąc) €1260/uczestnika za każdego kolejnego €1120 u klienta dla grupy do 12-tu osób. €4200 + koszty podróżne instruktora (przeloty, hotel, etc.) Podane ceny obowiązują przez najbliższe 30 dni (począwszy od 15.10) 2008 Działa pod MS Windows 95, 98, NT, 2000, Me, XP, Vista oraz 7. Prawdopodobnie 2005 (nie jest dalej rozwijany) 2008 B/D (ze strony producenta) Z własnego doświadczenia wynika, że wymagania są minimalne Minimum 128MB+ RAM Windows NT 4.0, 2000, XP Pentium III lub nowszy kompatybilny z IBM-PC 64 MB RAM dla Windows NT 15 MB wolnej przestrzeni HDD Ogólna charakterystyka Instalacja programu i oprogramowanie dodatkowe Szybka i bardzo prosta Szybka i bardzo prosta 88 SAPHIRE zaopatrzony jest w dodatkowy program o nazwie GEM. Jest to aplikacja dedykowana przemysłowi jądrowemu w kontekście oceny ryzyka. GEM Możliwości wymiany danych z innymi aplikacjami (np. eksport do Excela) Import: *.mdb, *.xls, *.csv, *.txt Export: zapis i eksport danych zablokowane w wersji demo Pliki przykładowe/ Sample Możliwość pisania dodatkowych interfejsów na bazie bibliotek DLL Tak Poza możliwością skopiowania obrazu drzewa, całkowity brak kompatybilności z oprogramowaniem firm trzecich automatyzuje procedurę obliczania CCDP (Conditional Core Damage Probability). Import i eksport plików do formatu ASCII. Ponadto eksport drzew do formatów graficznych: *.WMF, *.EMF, *.BMP. Tak (k) Nie Budowanie drzew błędów/zdarzeń Stosowane elementy: możliwe atrybuty elementów, stosowane funkcje (modele) rozkładów prawdopodobieństwa, 9 bramek logicznych 5 zdarzeń elementarnych Funkcjonalności spotykane we wszystkich poprzednich aplikacjach 5 bramek logicznych 6 zdarzeń elementarnych Bardzo uboga liczba funkcji. Zarówno w przypadku zdarzeń jak i bramek dostępne są tylko 2 atrybuty: nazwa i typ. W przypadku zdarzenia dochodzi jeszcze wartość prawdopodobieństwa O ustalonej wartości (Constant odpowiednik Fixed) O ustalonej wartości (Fixed), Współczynnikowy (Rate) w oparciu o współczynnik awaryjności i naprawy, Dla modelu średniego czasu do wystąpienia awarii (MTTF), Dla stanu bezczynności (Dormant), Sekwencyjny (Sequential), Model zdarzenia inicjującego 89 7 bramek logicznych 4 zdarzenia elementarne Dość duża ilość opcji, w tym możliwości spotykane w innych tego typu programach, a więc nazwa czy typ zdarzenia, możliwość wprowadzania danych kwantyfikacyjnych (współczynniki niezawodności, niepewności) etc. Blank (wykorzystuje metodę punktowego szacowania wartości), Logarytmiczno –normalny, Normalny, Beta, Dirichleta, Gamma, Chi-kwadrat, Wykładniczy, uwzględnianie zależności czasowych, uwzględnianie cyklu monitoringu i napraw CCF inne Korzystanie z bibliotek danych niezawodnościowych gałąź drzewa awaryjnego (ET Initiator), Dla stanu gotowości (Standby), Model okresu narażenia urządzenia na podwyższone ryzyko (Time at Risk), Dwumianowy (Binominal), Poissona, Dla modelu średniego czasu do naprawy (Rate/MTTR), Weibulla, Częściami stały (Fixed-Phased), Częściami zależny od współczynników (Rate-Phased) Sekwencyjne uruchamianie zdarzeń Nie Tak Tak Nie Tak Tak Nie Nie dotyczy Tak (w tym dane z IAEA), przy czym wersja demo pozwala jedynie na zapoznanie się z zawartością bibliotek, a nie z konkretnymi wartościami liczbowymi Tak Nie dotyczy Tak, z własnych (zapisywanych w plikach zewnętrznych) Tak (za pomocą edytora reguł logicznych) Nie dotyczy (k) Brak wbudowanych bibliotek niezawodnościowych. Istnieje możliwość ich wgrania. Możliwość budowania własnych diagramów, zestawów danych i bibliotek do wtórnego wykorzystania oraz manipulowania częściami drzew Ocena interfejsu do budowania drzew Istotne elementy interfejsu niezbędne do budowania drzew niedostępne z okna głównego. 90 Jednorodny, Histogram, Maksimum entropii, Sejsmiczny, Nieinformacyjny uwiązany (constrained non informative), Trójkątny Tak Tak Nie najgorszy, aczkolwiek adekwatny do niewielkich możliwości programu Przejrzyste GUI . Dość intuicyjna obsługa; Możliwość dowolnego kolorowania Maksymalna ilość elementów drzewa Wolniejsze tworzenie skomplikowanych drzew Nie ma ogracznień programowych (rekomendowane z uwagi na wydajność 20000) elementów Brak ograniczeń 64 000 (na cały projekt) Analiza drzew błędów/zdarzeń Wyznaczanie MCS (minimal cut sets): wyznaczanie i rozwiązanie równań boolowskich Wyznaczanie wartości prawdopodobieństwa realizacji minimum awaryjnego, przejść pomiędzy stanami oraz znaczenia zdarzeń elementarnych w drzewie Możliwości wykonywania analiz zachowania się systemu w czasie Tak Tak Tak Tak Tak Tak Tak Nie Możliwości wykonywania analiz wrażliwości i niepewności wyników Możliwości uwzględnienia błędów ludzkich (k) Tak Nie (k) Odpowiedź konsultanta brzmiała: „Nie”, aczkolwiek odpowiedź ta wydaje się niewiarygodna. Tak (k) Nie ma do tego celu dedykowanej opcji. Na ogół stosuje się tzw. Fixed failure model ze stałą wartością prawdopodobieństwa Tak Nie Tak (w tym nawet możliwość zamodelowania spóźnienia pracownika do pracy). Nie (program nie posiada funkcji generowania drzewa zdarzeń) Tak Określanie prawdopodobieństwa warunkowego stanów końcowych w "drzewie zdarzeń" oraz ich prawdopodobieństw bezwarunkowych, biorąc pod uwagę prawdopodobieństwa wystąpienia niepożądanych zdarzeń przypadkowych określonych w "drzewie błędów". 91 Tworzenie wykresów F-N (przedstawiających na płaszczyźnie krzywe poziomu ryzyka w funkcji częstości - F i skutków - N) Sposób prezentacji wyników Tak Nie (k) Nie Wykresy/Tabele Pliki tekstowe Wykresy/Tabele Inne uwagi Ograniczenia wersji demo natury ilościowej (z góry określona maksymalna liczba bramek czy zdarzeń) Możliwość robienia hiperłączy do plików oraz Internetu Podobnie jak w RiskSpectrum procedura projektowania drzewa odbywa się poprzez systematyczne tworzenie biblioteki elementów. Możliwość tworzenia reguł i makr Reguły są to mniej lub bardziej zaawansowane procedury o strukturze if-then-else Makra mogą służyć do automatycznego przeprowadzania żmudnych, powtarzających się zadań w analizie. Możliwość śledzenia ścieżki propagacji awarii (niedostępna w wersji demo) http://www.isographsoftware.com/video/FTDemo480.ht ml 92 8.3. Funkcjonalność oprogramowania referencyjnego Przedstawione w poprzednim rozdziale tabele wymagają niewątpliwie dodatkowego komentarza. Celem niniejszego rozdziału jest więc przybliżenie i wyjaśnienie zamieszczonych tam danych. Tym niemniej nie będziemy opisywać każdego z programów z osobna w najdrobniejszych detalach, w większości wypadków mijałoby się to z celem i jednocześnie zacierało istotę różnic występujących pomiędzy nimi. Toteż, by uwypuklić owe różnice oraz wykazać ich wpływ na wygodę i szybkość pracy z oprogramowaniem, przyjęto, że bardziej efektywną metodą będzie opis rekomendowanej aplikacji, a następnie porównanie jej z konkurencją. Owa aplikacja stanie się tym samym tzw. oprogramowaniem referencyjnym. Spośród omawianych tutaj aplikacji za najlepszy punkt odniesienia względem pozostałych obrane zostało RiskSpectrum PSA firmy Scandpower. Jest to jednocześnie jeden z produktów rekomendowanych przez MANHAZ, biorąc pod uwagę przyjęte kryteria. W opisie porównawczym wypada zacząć od wymagań systemowych. Trzeba przyznać, że pod tym względem RiskSpectrum wyróżnia się niezwykle niskim zapotrzebowaniem na zasoby sprzętowe w porównaniu z konkurencyjnym oprogramowaniem. Oczywiście jest to jego ogromna zaleta, tym niemniej musi zastanawiać, jak to możliwe, by różnice były tak diametralne. Wystarczy w tym miejscu porównać potrzeby RiskSpectrum z Relex-em. O ile ten pierwszy deklaruje minimalne wymagania na poziomie Pentium 166, 11 MB przestrzeni dyskowej oraz 8 MB RAMu, to już ten drugi oczekuje od użytkownika posiadania komputera w standardzie Pentium 4 (2 GHz), 1 GB miejsca i 512 MB RAMu. Z drugiej strony te wymogi Relexa generalnie nie odbiegają od obecnych standardów oprogramowania dostępnego na rynku. Aby jednoznacznie określić wpływ tych parametrów na proces analityczny, tzn. głównie na prędkość obliczeń, należałoby, po pierwsze, stworzyć odpowiednio duże, a po drugie, identyczne drzewa w obu aplikacjach, uruchamiając je na tym samym komputerze. Niestety wersje demonstracyjne takiej możliwości nie dają. Założyć przeto należy, że im mniejsze wymagania tym oprogramowanie lepiej spełnia kryteria zapotrzebowania klienta, nie ma bowiem potrzeby wydatkowania dodatkowych środków finansowych na nowy sprzęt. Kilka słów należy też poświęcić procesowi instalacyjnemu. Instalacja RiskSpectrum nie nastręcza żadnych problemów i jest dosyć szybka (tyle na ile można wywnioskować z dostępnej wersji demo). Na ogół wystarczy zatwierdzać kolejne komunikaty instalatora. W jednym miejscu tylko, pojawia się nieco trudniejsze pytanie. Mianowicie czy program będzie wykorzystywany przez wszystkich użytkowników danego komputera, czy też tylko jednego. Zdecydowanie najwięcej opcji pod tym względem oferują programy firmy ITEM Software, a konkretnie Toolkit i QRAS. Tylko Toolkit umożliwia instalację w 5-ciu różnych trybach: 93 License Server - wersja nie wymagająca instalacji całego oprogramowania na serwerze, a odpowiadająca jedynie za dostęp do/dystrybucję licencji; Network Client - wersja kliencka oprogramowania, która kontaktuje się z pełnym oprogramowaniem zainstalowanym na serwerze; Network Server - pełne oprogramowanie instalowane po stronie serwera, natomiast kontakt z nim jest realizowany na komputerach podpiętych do sieci za pośrednictwem aplikacji klienckich (patrz Network Client); Standalone – w pełni funkcjonalna wersja na samodzielną stację roboczą, działającą indywidualnie, poza siecią; View-Only Client - służący jedynie do przeglądania wyników. Takie możliwości świadczą z jednej strony o dobrze przemyślanej strukturze oprogramowania, ale z drugiej przede wszystkim o jej poziomie zaawansowania i złożoności. Ułatwia to też zarządzanie uprawnieniami i poziomami dostępu do wrażliwych danych modelowanego zakładu przemysłowego czy instalacji procesowej. W kontekście „dostępu” pewną dość unikalną zdolnością odznacza się RELEX, który umożliwia zabezpieczanie tworzonych w nim projektów hasłem. Jest to wartościowa cecha, która mogłaby być obowiązującym standardem w tego typu oprogramowaniu. Kolejnym dość istotnym kryterium porównawczym jest integralność badanych programów z aplikacjami zewnętrznymi. Chodzi konkretnie o możliwość importu, eksportu, ewentualnie konwersji danych, grafik; jednym słowem możliwości komunikacji i przekazywania pełnych wyników analiz do takiego oprogramowania jak na przykład pakiet MS Office. Tu też panuje bowiem spora różnorodność i choć wydaje się, że najpopularniejszym formatem zapisu jest *.xls (MS Excel), to trudno powiedzieć o jakiejkolwiek standaryzacji. Trzeba dodać, że wersje demo programów nie dawały możliwości zapisu, celem choćby porównania zawartości plików wynikowych. Co więcej, wypada nadmienić, że o ile RiskSpectrum pozwala otworzyć/zapisać dane w formatach *.rsa (plik typu ASCII skojarzony z RS), *.xls, *.xml, to już np. FaultTree+ radzi sobie z *.mdb (MS Access), *.xls, *.csv czy *.txt. Nieco odrębnym tematem jest tu kwestia zapisu grafik drzew błędów i zdarzeń. RiskSpectrum oferuje w tym względzie uniwersalny format *.wmf. Nieco lepiej wygląda tu SAPHIRE, który daje ponadto możliwość zapisu do *.emf czy *.bmp. Pozostałe programy czy to produkty firmy ITEM czy PTC na ogół umożliwiają przenoszenie grafik metodą kopiuj/wklej, bez zapisywania ich do zewnętrznych plików. Tak czy inaczej można uznać, że każdy z omawianych programów posiada mniej lub bardziej rozbudowane możliwości przekazywania informacji do ich dalszego wygodnego opracowania. Warto może tu jeszcze dodać, że najbardziej efektowne wydają się grafiki produkowane przez RELEXa, w tym zwłaszcza wykresy, których wykorzystanie na slajdach z pewnością wzbogaci niejedną prezentację. Przechodząc do właściwych funkcji programu, nie można zapomnieć wcześniej o tym co widać na pierwszy rzut oka, czyli o interfejsie użytkownika (GUI). Kolejne ilustracje przedstawiają interfejsy omawianych programów. Najpierw okno drzewa błędów/awarii z programu RiskSpectrum. 94 Rys. 11. Jak widać na rys. 11, RiskSpectrum odznacza się dużą prostotą przekazu. Można by rzec nieco archaiczną, tak jakby twórcy zapomnieli, że era czarno-białych monitorów dawno przebrzmiała. Nie jest to wcale efekt braku zaangażowania twórców w tzw. design. Tak naprawdę jest to skutek niskich wymagań sprzętowych oprogramowania. Pomimo nieco zastygłej formy, interfejs spełnia swoją rolę doskonale i nie ustępuje rywalom ani na krok. Górny pasek zadań daje nam pełen wachlarz symboli bramek logicznych i zdarzeń elementarnych. Tych pierwszych do dyspozycji mamy 7, a samych zdarzeń 3. Z pozycji okna drzewa błędów mamy też bezpośredni dostęp do innych drzew w projekcie, a także podstawowe informacje o zaznaczonych elementach drzewa. Chyba nic więcej nie potrzeba, a jeśli potrzeba wystarczy dwa razy kliknąć w konkretny symbol w strukturze drzewa, by dowiedzieć się więcej. O interfejsie SAPHIRE’a i jego funkcjonalności możemy powiedzieć najmniej, a to za sprawą braku dostępu do demonstracyjnej wersji programu, zaś na bazie zgromadzonych publikacji (głównie tekstowych, przeważnie nie ilustrowanych) trudno wyrokować o wyglądzie oprogramowania. Wiadomo jednak, że w najnowszej wersji oprogramowania, tj. w wersji 8. główny nacisk położono właśnie na „lifting” interfejsu użytkownika, przy jednoczesnym zachowaniu wszystkich dotychczasowych narzędzi, funkcji i opcji. Interfejs nowego SAPHIRE’a przedstawia rys. 12. 95 Rys. 12. Nie da się ukryć, a tym bardziej podważyć stwierdzenia, że na miano najbardziej kolorowego i urozmaiconego interfejsu zasługuje RELEX. Do złudzenia przypomina on w tym względzie produkty pakietu MS Office z serii 2003. Już na pierwszy rzut oka widać, że spośród wszystkich tu omawianych, to właśnie RELEX, wyraźnie przewyższa swoich rywali liczbą funkcji dostępnych bezpośrednio z pozycji paska narzędziowego (rys. 13). 96 Rys. 13. Na każdym kroku da się odczuć, że inżynierowie z PTC włożyli wiele wysiłku, aby interfejs przekazywał możliwie dużo informacji w sposób jak najbardziej praktyczny. Na rys. 13 widzimy zatem, bogate w opcje paski narzędzi oraz okno robocze podzielone na dwa obszary. Górny przeznaczony na stabelaryzowane, usystematyzowane informacje na temat drzewa oraz dolny do wizualizacji drzewa czy wyników w postaci wykresów. Pomysłowym rozwiązaniem z ergonomicznego punktu widzenia jest również możliwość wyboru modułów, z których będziemy korzystali, i to już na starcie programu. Moduły te możemy oczywiście uruchamiać i wyłączać w trakcie, tym samym lepiej wykorzystując pamięć komputera. Wypada może jeszcze na koniec dodać, że RELEX posiada największy zbiór elementów konstrukcyjnych drzew błędów. Do dyspozycji mamy bowiem 4 zdarzenia elementarne i aż 15 bramek logicznych. Te ostatnie sprawiają, że w pewnym sensie wyeliminowano problem, a może lepiej powiedzieć potrzebę, kombinowania układów logicznych z więcej niż jednej bramki. Bez dłuższej praktyki trudno powiedzieć, jak bardzo usprawnia to pracę, na pewno jednak musi upraszczać strukturę drzewa poprzez minimalizację ilości elementów. Produkty firmy ITEM Software, tj. Toolkit i QRAS z punktu widzenia interfejsu użytkownika są zwyczajnie identyczne, w związku z czym osobny opis dla każdego z nich mijałby się tu po prostu z celem. Nie powinno to nikogo dziwić, biorąc na wzgląd, że są to w końcu produkty rozwijane równolegle. Różnica polega jedynie na ich przeznaczeniu w zastosowaniu praktycznym oraz w ilości dostępnych modułów, o czym mowa była już wcześniej. 97 Rys. 14. Rys. 15. Tak czy inaczej warto powiedzieć choćby dwa słowa o ich interfejsie w kontekście całego zestawienia. Skupmy się zatem przez chwilę na Toolkit’cie. Rys. 16. Przyglądając się ilustracji z rys. 16, łatwo dostrzec, że GUI jest bardziej stonowane w porównaniu z RELEXem, ale z drugiej strony przestrzeń robocza wydaje się lepiej zorganizowana, bardziej przejrzysta, no i przede wszystkim mniej toporna niż w RiskSpectrum. Zamiast podwójnego okna tak, jak w RELEXie, producenci Toolkita wprowadzili bardzo użyteczne zakładki, dzięki czemu dostęp do większości opcji został zapewniony metodą jednego kliknięcia. GUI jest dość intuicyjne i nawet największy laik szybko opanuje jego obsługę. Drzewo 98 zdarzeń konstruuje się stosunkowo szybko, istnieje możliwość samodzielnego doboru kolorów poszczególnych elementów drzewa. To wszystko sprawia, że praca z programem nie nastręcza problemów i nie nudzi szybko oczu użytkownika. Ożywiony i nieco ubarwiony interfejs na pewno sprawia lepsze wrażenie niż oferowany przez Scandpower w RiskSpectrum przy niewiele większych wymaganiach sprzętowych. Szkoda tylko, że oprogramowanie firmy ITEM Software wyrosło na bazie doświadczeń przemysłu lotniczego, a nie jądrowego. Ocena interfejsu kolejnego programu, tj. FaultTree+ wydaje się nieco bardziej problematyczna. Z jednej strony bowiem interfejs jest równie klarowny i przejrzysty jak w RiskSpectrum, ale z drugiej pomimo większej ilości opcji na pasku zadań mniej funkcjonalny, Jest to spowodowane minimalizacją ilości ikon na paskach. Wyeliminowano w ten sposób również te najważniejsze, a mianowicie symbole elementów składowych drzewa (zdarzeń i bramek). Jest to odejście od dobrej praktyki stosowanej przez pozostałych producentów, gdzie wszystkie symbole są „na wierzchu” i dostępne od ręki. Tutaj natomiast dostępne są tzw. klawisze uniwersalne, które pozwalają wstawić obiekt, a dopiero w drugiej kolejności wybrać jego typ. Ciekawym urozmaiceniem natomiast jest możliwość wklejania obiektów zewnętrznych, np. obrazków czy schematów adekwatnych do modelowanego drzewa (rys. 17). Rys. 17. Generalnie jednak program jest dość prosty i przyjazny w obsłudze, nie ustępując przy tym 99 znacznie w funkcjonalności rywalom. Wypada też zwrócić uwagę na niewygórowane wymagania oraz stosunkowo niską opłatę licencyjną. Ostatni w zestawieniu, czyli OpenFTA jest w gruncie rzeczy tylko zalążkiem dobrego narzędzia inżynierskiego. Prosty interfejs, wynikający poniekąd z ograniczonych możliwości programu, w łatwy sposób pomaga w stworzeniu skomplikowanej struktury drzewa (rys. 18). Co więcej w kwestii projektowania drzewa działa dość podobnie do RiskSpectrum, tworząc automatycznie bazę elementów składowych drzewa, które można następnie wtórnie wykorzystać. Wymaga też od użytkownika systematycznego działania. Dzieje się tak, ponieważ program składa się niejako z dwóch niezależnych modułów. Jeden z nich to baza elementów składowych drzewa wraz z ich parametrami, drugi to nakładka graficzna, która wymaga od użytkownika samodzielnego linkowania danych z bazy z tzw. widokiem. Rys. 18. Choć była już o tym mowa, to trzeba w tym miejscu raz jeszcze podkreślić, że OpenFTA nie stanowi zamiennika dla oprogramowania opisywanego wcześniej. Należy go traktować bardziej jako ciekawostkę niż narzędzie użytkowe. Tym niemniej jest to projekt typu „open source”, który można samodzielnie rozwijać. Tyle tytułem wprowadzenia, przyjrzyjmy się teraz zatem procesowi projektowania drzewa, który na dobrą sprawę wygląda dość podobnie w każdej z analizowanych aplikacji, oczywiście z pewnym wyjątkami. W naszej analizie skupiamy się oczywiście dalej na oprogramowaniu referencyjnym, czyli RiskSpectrum. Należy przy tym zaznaczyć, że z uwagi 100 na ograniczone możliwości wersji demo, przykład przedstawia tylko metodę rozbudowy istniejącego drzewa oraz związane z tym działaniem opcje. Uruchomienie i wybór istniejącego projektu przenosi nas automatycznie do jego głównego okna (rys. 19), w którym zebrano wszystkie informacje na temat modelowanego systemu. Rys. 19. Mamy więc dostęp do widoku drzewa błędów, drzewa zdarzeń, listy poszczególnych zdarzeń już zdefiniowanych, a także atrybutów, jakie można im przypisywać, słowem główny indeks projektu. Wybierając opcję Fault Tree dostaniemy się do widoku drzewa błędów. 101 Rys. 20. Za pomocą podwójnego kliknięcia w dowolny element, dostajemy się bez trudu w jego właściwości/parametry. W przypadku bramki logicznej, tak jak to przedstawia rys. 20, najistotniejsze znaczenie ma jej typ, nazwa oraz unikatowa sygnatura. Spróbujmy teraz dodać nowe zdarzenie elementarne do istniejącego drzewa. Wybierając z górnego paska symbol koła, a następnie klikając raz na wybraną bramkę, rozpoczynamy definicję nowego zdarzenia. Możemy oczywiście wybrać z rozwijalnej listy jedno ze zdefiniowanych już wcześniej zdarzeń, ale my pozwolimy sobie stworzyć zupełnie nowe. 102 Rys. 21. Po wpisaniu nazwy i zatwierdzeniu komunikatu jak na rys. 21, pojawi się ono w oczekiwanym przez nas miejscu w strukturze drzewa. I tak oto stworzyliśmy nowy obiekt w bazie lub jak kto woli bibliotece projektu, który od tej pory będzie istniał pod swoją własną unikalną nazwą i który w razie potrzeby będzie można wtórnie wywołać w innym miejscu drzewa, np. jako wspólną przyczynę kilku awarii (CCF). Klikając w nasz nowy obiekt dwukrotnie, możemy przystąpić wreszcie do wprowadzania parametrów zdarzenia, podobnie jak miało to miejsce w przypadku bramki logicznej. 103 Rys. 22. Poza nazwą i opisem, najważniejszy z punktu widzenia dalszej analizy będzie wybór właściwego modelu zdarzenia (rys. 23). Mamy do dyspozycji następujące możliwości wyboru: Undef. – model niewymagający żadnych parametrów, przeznaczony dla przypadków trudnych do jednoznacznego zdefiniowania; Repairable – pozwalający na przyjęcie założenia o możliwości naprawy urządzenia natychmiast po jego awarii; Tested – uwzględniający potrzebę okresowego przeglądu urządzenia; Probability – wymagający jedynie podania stałej wartości prawdopodobieństwa wystąpienia zdarzenia, niezależnej od czasu czy innych warunków zewnętrznych; Mission time – umożliwia zamodelowanie urządzenia, które musi działać przez określony czas bez możliwości naprawy; Frequency – bazuje na stałej częstotliwości występowania zdarzeń i wykorzystywany jest głownie do tzw. zdarzeń inicjujących; Non-repairable – model przygotowany na okoliczność użycia urządzenia, którego nie można naprawiać w trakcie jego pracy. 104 Rys. 23. Rys. 24. Dla uproszczenia wybraliśmy model Probability i w związku z tym w dolnej części okienka musimy wprowadzić tylko jedną wartość, gdybyśmy jednak zdecydowali się powiedzmy na wariant Tested do zdefiniowania mielibyśmy już nie jeden a cztery współczynniki: Failure rate (r) – współczynnik uszkodzenia MTTR (Tr) – średni czas naprawy Test interval (Ti) – czas testu Time to first test (Tf) – czas do pierwszego testu Kolejny krok to wybór wartości, którą chcemy dalej wyliczyć, której oczekujemy jako wyniku działania zdarzenia. Do wyboru mamy w sumie cztery opcje (rys. 24). Wypada może wyjaśnić same oznaczenia, a więc po kolei mamy tu do czynienia z: Q – niedostępność/odstawienie urządzenia, F – prawdopodobieństwo wystąpienia co najmniej jednej awarii w zadanym okresie, W – intensywność (częstotliwość) bezwarunkowej awarii. Wypada poświęcić jeszcze dosłownie dwa słowa tworzeniu i linkowaniu informacji z drzew błędów do drzewa zdarzeń. Zamiast jednak tworzyć nowe postaramy się rozbudować istniejące drzewo zdarzeń. Procedura jest stosunkowo prosta. Rys. 25. 105 W przypadku RiskSpectrum wystarczy kliknąć lewym klawiszem myszy w dowolną przestrzeń z widokiem drzewa, aby rozwinęło się menu kontekstowe, z którego należy wybrać opcję Insert Function Event. Rys. 26. Jeśli dodajemy całkiem nowe zdarzenie tak, jak w prezentowanym przypadku (rys. 27), aplikacja zapyta nas faktycznie chcemy stworzyć w bazie nową pozycję. Rys. 27. Po zatwierdzeniu komunikatu, podwójnym kliknięciem wchodzimy we właściwości nowego zdarzenia. Możemy dla porządku uzupełnić pole opisu (Description) i przejść do kolejnej zakładki, tj. do Input. 106 Rys. 28. Teraz najważniejsza część, a mianowicie linkowanie z przygotowanym wcześniej drzewem błędów. Elementem szczytowym tamtego drzewa była bramka logiczna o nazwie @NT-1 i dlatego też w zakładce Input wybieramy z list rozwijalnych kolejno: Gate, a następnie @NT-1. Rys. 29. By ostatecznie zdarzenie znalazło się w projektowanym przez nas drzewie zdarzeń, musimy koniecznie dodać nową gałąź. W tym celu wybieramy opcję Insert branch z menu kontekstowego. 107 Rys. 30. Końcowy efekt naszego działania reprezentuje rys. 31. Rys. 31. Jak widać sam proces budowania drzew awarii/błędów i zdarzeń nie jest specjalnie trudny w oparciu o takie narzędzia jak RiskSpectrum, abstrahując oczywiście w tym miejscu od zagadnień merytorycznych czy gromadzenia i wprowadzania do niego odpowiednich danych. To jednak co najdobitniej odróżnia od siebie opisywane tutaj programy to ich możliwości analityczno-obliczeniowe. O tym czym się różnią w zasadzie jest zawarte w odpowiednich rubrykach tabeli z poprzedniego rozdziału. Niemniej jednak, wypada choćby skromnie przedstawić bogactwo i różnorodność danych wynikowych, jakie można osiągnąć przy ich pomocy. Tu oczywiście będziemy się posiłkowali możliwościami oprogramowania referencyjnego. W przypadku RiskSpectrum mamy pełną kontrolę nad procesem analitycznym. Należy przez to rozumieć, że zanim uruchomimy analizę jesteśmy w stanie określić, które drzewo i jaki 108 obszar analizy jest dla nas istotny. RiskSpectrum dzieli analizę na 4 obszary tutaj zwane specyfikacjami: MCS – krytyczna (minimalna) ścieżka propagacji awarii; Uncertainty – analiza niepewności; Importantce – analiza istotności; Time-dep. – analiza parametrów zależnych od czasu. Rys. 32. Gdy wybór został już dokonany, wystarczy z paska narzędzi wybrać ikonkę Run analysis i czekać na wyniki. W zależności od poziomu skomplikowania drzewa, po pewnym czasie powinno nam się pojawić okno, ze statystyką badania oraz komunikatem, że analiza została ukończona. 109 Rys. 33. Wybierając z głównego menu Analysis > View result, możemy prześledzić otrzymane wyniki, a jest ich, jak widać na rys. 34, niemało. Wystarczy zerknąć na ilość zakładek albo przejść bezpośrednio do ostatniej z nich, czyli Chart (wykres). Rys. 34. Kolejne ilustracje przedstawiają tylko dwa z 38-miu dostępnych w programie wykresów i diagramów. 110 Rys. 35. Rys. 36. Kompletna lista wykresów i danych stabelaryzowanych oferowana przez RiskSpectrum jest następująca: MCS contributions – wkład poszczególnych zdarzeń elementarnych (ZE) zbioru minimalnych przekrojów drzewa MCS, wyznaczających minimalne kombinacje ZE (ścieżki zdarzeń) prowadzące do zdarzenia szczytowego (ZT); Module-MCS contributions – jak wyżej, z tymże zdarzenia elementarne zostały pogrupowane w tzw. moduły; PDF – funkcja rozkładu prawdopodobieństwa zdarzenia szczytowego; CDF – skumulowana funkcja rozkładu (dystrybuanta); Basic event FV – miara Fussell-Vessely wagi zdarzenia elementarnego (ZE); Basic event FC – wkład pojedynczego ZE do całkowitego prawdopodobieństwa wystąpienia zdarzenia szczytowego drzewa; Basic event RDF – współczynnik redukcji ryzyka dla ZE; Basic event RIF – współczynnik wzrostu ryzyka dla ZE; Basic event Sens. – wrażliwość wyniku na ZE; CCF Group FC – podobnie jak w przypadku „Basic event FC” tyle, że w ujęciu dla 111 całych grup zdarzeń o tej samej przyczynie (CCF); CCF Group RDF - współczynnik redukcji ryzyka w odniesieniu do grupy elementów narażonych na to samo zdarzenie CCF; CCF Group RIF - współczynnik wzrostu ryzyka w odniesieniu do grupy elementów narażonych na to samo zdarzenie CCF; CCF Group Sens. – wrażliwość wyniku na zmiany zachodzące w grupie elementów narażonych na to samo, wspólne zdarzenie inicjujące (CCF); Parameter FC – wkład parametru pojedynczego zdarzenia (ZE) do wystąpienia zdarzenia szczytowego; parametr ten w RiskSpectrum definiowany jest najczęściej jako wartość średnia ze współczynnika niezawodności oraz jego rozkładu; Parameter RDF – współczynnik redukcji ryzyka ze względu na parametr; Parameter RIF – współczynnik wzrostu ryzyka ze względu na parametr; Parameter Sens. – wrażliwość wyniku ze względu na zmianę parametru; Attribute FC – wkład atrybutu/-ów zdarzenia elementarnego do zdarzenia szczytowego; przez atrybut RiskSpectrum rozumie wspólną cechę opisową kilku urządzeń np. z uwagi na ich lokalizację w zakładzie, realizowane zadanie, producenta etc.; Attribute RDF – współczynnik redukcji ryzyka z uwagi na atrybut; Attribute RIF – współczynnik wzrostu ryzyka z uwagi na atrybut; Attribute Sens. – wrażliwość wyniku ze względu na atrybut; Component FC – wkład komponentu zdarzenia elementarnego do zdarzenia szczytowego, gdzie komponent rozumiany jest jako grupa zdarzeń dotycząca tego samego urządzenia; Component RDF – współczynnik redukcji ryzyka z uwagi na komponent; Component RIF – współczynnik wzrostu ryzyka z uwagi na komponent; Component Sens. – wrażliwość wyniku z uwagi na komponent; System FC – wkład grupy zdarzeń elementarnych o jednakowej sygnaturze systemowej; System RDF – współczynnik redukcji ryzyka ze względu na oznaczenie systemowe; System RIF - współczynnik wzrostu ryzyka ze względu na oznaczenie systemowe; System Sens. – wrażliwość wyniku ze względu na oznaczenie systemowe; BE Group FC – wkład całych grup zdarzeń elementarnych do zdarzenia szczytowego, gdzie grupa ta definiowana jest samodzielnie przez użytkownika np. za pomocą filtrów atrybutów; BE Group RDF – współczynnik redukcji ryzyka z uwagi na grupę; BE Group RIF – współczynnik wzrostu ryzyka z uwagi na grupę; BE Group Sens. – wrażliwość wyniku ze względu na grupę; Q(t) Unavailability – niedostępność w funkcji czasu; W(t) Uncond. failure int. – częstotliwość uszkodzenia w funkcji czasu; L(t) Cond. failure int. – intensywność warunkowa uszkodzenia w funkcji czasu; E(0,t) Expected no. of failures – oczekiwana liczba awarii w przedziale czasu; F(t) Prob. of >= 1 failure – prawdopodobieństwo wystąpienia co najmniej jednej awarii w określonym przedziale czasu; Z tego zestawu widać jak duże są możliwości analityczne programu RiskSpectrum. 112 9. WNIOSKI KOŃCOWE Testy dostępnego na rynku i dostarczonego przez producenta oprogramowania do analiz niezawodności systemów technologicznych i oszacowań prawdopodobieństwa ciągów zdarzeń awaryjnych występujących w takich systemach na potrzeby PSA, sugerują wybór aplikacji RiskSpectrum PSA firmy Scandpower. Do chwili przygotowania niniejszego raportu nie uzyskano jakiejkolwiek wersji programu SAPHIRE, co uniemożliwiło pełne porównanie jego funkcjonalności w praktyce z innymi programami dla których przeprowadzono testy, w szczególności z RiskSpectrum. Za wyborem tym przemawiają liczne czynniki. Po pierwsze grunt na jakim oprogramowanie to powstało. Należy przez to rozumieć, że RiskSpectrum od samego początku projektowany i rozwijany był zawsze głównie z myślą o energetyce jądrowej. Po drugie, firma w dziedzinie PRA ma wieloletnie doświadczenie, przekraczające 20 lat. Są to czynniki niebagatelne, dające użytkownikowi poczucie wiarygodności uzyskiwanych wyników. Należy też wymienić bardzo dobry kontakt z przedstawicielami handlowymi i niewielką odległość do najbliższej siedziby firmy (Sztokholm, Szwecja) oraz jasną politykę cenową oraz licencyjną. W dalszej kolejności należy podkreślić niskie wymagania sprzętowe i jednocześnie bardzo duże możliwości obliczeniowe. Prosty interfejs użytkownika, łatwość obsługi, logika i systematyka działania. Wreszcie możliwość implementacji zewnętrznych bibliotek niezawodnościowych. To wszystko właśnie wpływa na ostateczną bardzo pozytywną ocenę programu RiskSpectrum. Innym programem, który koniecznie należałoby rozważyć jest SAPHIRE, dla którego dostępna jest bardzo obszerna 6-tomowa dokumentacja [17]. Wskazuje ona na to, że SAPHIRE jest środowiskiem informatycznym, idealnym do przeprowadzenia kompleksowych analiz probabilistycznych bezpieczeństwa EJ w zakresie Poziomu 1 PSA, a także w zakresie Poziomu 2 PSA, w części dotyczącej analiz probabilistycznych dla fenomenologicznych drzew zdarzeń odnoszących się do zachowania obudowy bezpieczeństwa EJ po wystąpieniu poważnych awarii uszkodzenia rdzenia reaktora energetycznego. SAPHIRE pozwala na łatwe tworzenie i manipulację wynikami analiz dużych drzew błędów i drzew zdarzeń, m.in. w celu dodatkowych analiz probabilistycznych zdarzeń wewnętrznych takich jak pożary i zalania pomieszczeń, a także zewnętrznych wywołanych zjawiskami naturalnymi, upadkami samolotów i.t.p.. SAPHIRE dodatkowo umożliwia analizowanie wpływu działań naprawczych (odnowy) na poziomie poszczególnych systemów lub całych ciągów zdarzeń awaryjnych. Program oferuje szeroki zestaw funkcji rozkładu prawdopodobieństwa uszkodzeń i jest oparty o nowoczesne rozwiązania informatyczne wpływające na szybkości przeprowadzanych analiz. Biorąc ponadto pod uwagę, że: - produkt ten jest rekomendowany przez U.S. Nuclear Regulatory Commission,. - od samego początku został opracowany do zastosowań w energetyce jądrowej, - istnieje sposobność darmowego pozyskania z USA, należy bardzo poważnie rozważyć jego zastosowanie w Polsce do analiz probabilistycznych bezpieczeństwa EJ na poziomie projektowania, budowy i eksploatacji. 113 10. BIBLIOGRAFIA [1] NUREG/CR-2300. Vol. 1. PRA Procedures Guide. A Guide to the Performance of Probabilistic Risk Assessments for Nuclear Power Plants. December 1982. [2] IAEA Safety Standards. Development and Application of Level 1 Probabilistic Safety Assessment for Nuclear Power Plants. Specific Safety Guide. No. SSG-3. 2010. [3] IAEA Safety Standards. Development and Application of Level 2 Probabilistic Safety Assessment for Nuclear Power Plants. Specific Safety Guide. No. SSG-4, 2010. [4] NUREG-0492. Fault three handbook. U.S. Nuclear Regulatory Commission.1981. [5] IAEA-TECDOC-1200. Applications of probabilistic safety assessment (PSA) for nuclear power plants. 2001. [6] NASA Office of Safety and Mission Assurance NASA Headquarters. Fault Tree Handbook with Aerospace Applications. Version 1.1. 2002. [7] IAEA Safety Standards. Safety Assessment for Facilities and Activities. General Safety Requirements. No. GSR Part 4. 2009. [8] W.E. Vesely, et al., Fault Tree Handbook, U.S. Nuclear Regulatory Commission, NUREG - 0492, 1981. [9] PRA Procedures Guide, U.S Nuclear Regulatory Commission, NUREG/CR-2300, 1983. [10] M. Borysiewicz, Z. Koszela, M. Kulig, "Ustalenie szczegółowej metodologii analiz probabilistycznych oceny ryzyka dla EJ z WWER w, opracowanie wewnętrzne IEA Nr 0144/EII/84. [11] J.G. Waddington, A. Wild, "The Fault Tree as a Tool in Safety Analysis in Nuclear Power Plants”, Atomic Energy Control Board, Ottawa, Canada, INPO-0036, June 10, 1981. [12] Regulatory Guide on the Use of Fault Trees in Licensing Submissions, Atomic Energy Control Board Ottawa, Canada, Consultative Document C-70, May 31, 1983. [13] Reactor Safety Study: An Assessment of Accident Risk in U.S. Commercial Nuclear Power Plants, WASH-1400 /NUREG 75/014/, 1975. [14] R.B. Worrell, "SETS Reference Manual", Sandia National Laboratories, Albuquerque, New Mexico, NUREG/CR-4213, May 1985. [15] M. Borysiewicz, J, Nowak, "Funkcjonalne drzewa zdarzeń dla EJ z reaktorami typu Westinghouse i Babcock-Wilcox. Wskazania dla EJ z WWER", opracowanie wewnętrzne ISA 0121/EII/85. [16] M. Borysiewicz, J. Nowak, "Wstępna wersja systemowych drzew zdarzeń dla EJ Żarnowiec", opracowanie wewnętrzne IEA /EII/86. [17] NUREG/CR-6952. Vol. 1. INL/EXT-05-00248. Systems Analysis Programs for Hands-on Integrated Reliability Evaluations (SAPHIRE). Vol. 1. Summary Manual. U.S. NRC. 2008. [18] M. Kulig, Wytyczne dotyczące opracowania systemowych drzew uszkodzeń dla EJ, 0-143/EII/86 114
