Ocena programów komputerowych do analiz drzew błędów/zdarzeń

Komentarze

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  K11  K 21  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

Podobne dokumenty