Wprowadzenie do analizy FTA - czyli techniczne informacje niezbędne do przeprowadzenia analizy
FTA, czyli Fault Tree Analysis, to dedukcyjna metoda badania przyczyn awarii. Punktem wyjścia jest zawsze konkretne zdarzenie - awaria, której chcemy zapobiec. Od tego momentu schodzimy coraz głębiej, rozbijając problem na mniejsze elementy i sprawdzając, co dokładnie musi się wydarzyć, żeby do awarii doszło.
Fault tree analysis - Analiza Drzewa Błędów
Analiza FTA to świetne narzędzie do zrozumienia, jak i dlaczego system może zawieść (lub dlaczego zawiódł, ale skupmy się na działaniu proaktywnym), jednak temat jest na tyle obszerny, że zmieszczenie wszystkiego w pojedynczym artykule byłoby niepraktyczne. Żeby nie zarzucać Cię wszystkim naraz, całość zostanie podzielona na kilka mniejszych artykułów, z których każdy prowadzi krok po kroku przez kolejne elementy metody. Dzięki temu łatwiej wejść w temat i od razu przełożyć teorię na praktykę.
Poniżej będą pojawiać się linki do nowych części, gdy tylko zostaną opublikowane.
- Wprowadzenie do analizy FTA - czyli techniczne informacje niezbędne do przeprowadzenia analizy
Co to jest FTA?
Przejdźmy od razu do konkretów: co to jest FTA? FTA, czyli Fault Tree Analysis, to dedukcyjna metoda badania przyczyn awarii. Punktem wyjścia jest zawsze konkretne zdarzenie - awaria, której chcemy zapobiec. Od tego momentu schodzimy coraz głębiej, rozbijając problem na mniejsze elementy i sprawdzając, co dokładnie musi się wydarzyć, żeby do awarii doszło. To trochę jak śledztwo prowadzone przez Sherlocka Holmesa. Zaczynamy od skutku, a potem spokojnie podążamy w stronę przyczyny, eliminując przypadkowość i krok po kroku dochodząc do przyczyny źródłowej. Dzięki temu FTA zamienia pozorny chaos awarii w czytelną mapę tego, co naprawdę jest źródłem problemu.
Pokażmy to na prostym przykładzie awarii, z którą wielu z nas miało do czynienia. Wracasz wieczorem do domu, chcesz wziąć prysznic, odkręcasz wodę i nic się nie dzieje. Hydraulik mógłby działać na wyczucie, ale może też podejść do sprawy metodycznie. W głowie pojawia się coś na kształt FTA. Zdarzenie szczytowe to brak wody. Zadajemy więc pytanie: dlaczego jej nie ma? Możliwe przyczyny są trzy: brak zasilania z sieci, brak doprowadzenia wody do prysznica albo brak przepływu przez samą baterię prysznicową.
W tym momencie można zacząć testować kolejne gałęzie. Jeśli woda leci z umywalki, to zasilanie mamy z głowy. Możemy wtedy zdemontować baterię prysznica i sprawdzić, czy woda w ogóle do niej dociera. Jeśli nie dociera, badamy dalej: rura jest pęknięta, zatkana albo wystąpiła inna usterka. I tak krok po kroku dochodzimy do źródła problemu.
Każdy robił kiedyś taką analizę, tylko zwykle nie nazywał jej w ten sposób. Co innego jednak poradzić sobie z awarią w praktyce, a co innego jasno przedstawić cały tok rozumowania. Widać, jak nieporęczne bywa opisywanie tego słowami, a w bardziej złożonych systemach staje się to jeszcze trudniejsze. Dlatego właśnie graficzna forma analizy dedukcyjnej, czyli FTA, jest tak pomocna.
Rodzaje analizy FTA
W analizie FTA można pójść dwiema ścieżkami i obie mają sens, choć każda służy innemu celowi. Pierwsza to podejście jakościowe. Tutaj celem jest zrozumienie, jak dana awaria może powstać i jakie kombinacje zdarzeń do niej prowadzą. Nie bawimy się w liczby, bardziej w logiczne zależności. Taki wariant świetnie sprawdza się, gdy chcemy znaleźć słabe punkty systemu, zdecydować, gdzie dodać redundancję albo które elementy wymagają większej kontroli.
Ilościowa analiza FTA to już inna zabawa. Tutaj liczy się prawdopodobieństwo wystąpienia awarii i to, jak często dane zdarzenia podstawowe mogą się zrealizować. Żeby to zrobić, trzeba dysponować danymi o niezawodności elementów, wiedzieć, jak działają poszczególne komponenty i mieć kogoś, kto umie potem przeliczyć to na ryzyko końcowe. Efekt jest znacznie bardziej konkretny: dostajemy miary ryzyka, prawdopodobieństwa i możemy sprawdzić, czy system spełnia wymagania norm, na przykład SIL (IEC 61508).
Obie formy FTA świetnie się uzupełniają. Jedna skupia się na błędach systematycznych oraz ogólnym zrozumieniu, co może pójść nie tak, a druga na błędach losowych i odpowiada jak często może wystąpić awaria. Wspominałem o tym w tym artykule o błędach losowych i systematycznych. Połączenie tych wyników daje obraz, który pozwala podejmować sensowne decyzje projektowe zamiast zgadywać.
Podstawowe symbole używane w drzewie FTA
Żeby w ogóle zabrać się za analizę FTA, trzeba znać symbole opisane w normie IEC 61025. Bez nich drzewo wygląda jak losowy zbiór geometrycznych znaków, a nie logiczny model awarii.
Bramki logiczne
Bramka AND
To jedna z podstawowych bramek. Oznacza sytuację, w której wszystkie zdarzenia wejściowe muszą wystąpić, żeby powstało zdarzenie wyjściowe. Opiszmy to trochę bardziej życiowo, żeby lepiej zobrazować użycie bramki AND. Bramka AND pokazuje sytuację, w której pojedyncza porażka jeszcze nie prowadzi do kłopotu. To taki techniczny sposób powiedzenia: mamy zabezpieczenie, mamy redundancję, coś musi naprawdę pójść mocno nie tak, żeby zdarzenie szczytowe faktycznie wystąpiło. Dopiero gdy minimum dwa elementy zawiodą jednocześnie, łańcuch przyczyn zaczyna być realny.
Przykład z robotem przemysłowym jest tu idealny. Jeśli analizujemy zdarzenie: uderzenie człowieka przez robota, to pod bramką AND mogłyby znaleźć się na przykład takie trzy zdarzenia:
- Brak detekcji człowieka w strefie pracy robota.
- Brak bariery chroniącej przed dostępem do strefy pracy robota
- Niekontrolowany ruch Robota.
Każde z tych zdarzeń samo w sobie nie musi od razu prowadzić do wypadku. Bo przecież jeśli nie ma detekcji człowieka w strefie, ale człowiek zostanie wykryty przy wchodzeniu do strefy i robot nie wykona niekontrolowanego ruchu, to nic się nie wydarzy. Jednak gdy wszystkie zdarzenia dochodzi do zdarzenia, któremu mamy zapobiec. Właśnie to odzwierciedla AND: sekwencję jednoczesnych, niepożądanych zdarzeń, które dopiero łącznie tworzą realne zagrożenie.
OR – bramka alternatywy
Skoro mamy już AND, to naturalnie przechodzimy do OR, zostając przy tym samym przykładzie z robotem. Wcześniej pojawił się tam punkt dotyczący bariery chroniącej przed dostępem. Teraz bierzemy na warsztat właśnie to zdarzenie: brak bariery. Bramka OR świetnie się tu nadaje, bo pokazuje sytuację, w której istnieje kilka możliwych dróg prowadzących do tego samego skutku. Wystarczy, że wystąpi jedno zdarzenie bariera przestaje pełnić swoją funkcję.
Dla zdarzenia “brak bariery chroniącej przed dostępem" pod OR mogą znaleźć się takie przyczyny:
- fizyczna awaria bariery, na przykład uszkodzone słupki albo zerwana kotwa,
- całkowity brak bariery, czyli nie została w ogóle zamontowana,
- nieprawidłowe działanie systemu logicznego, który ma wykrywać obecność bariery lub jej stan (np. błędna konfiguracja, zła logika w sterowniku).
Każde z tych zdarzeń jest inną historią, ale wszystkie prowadzą do tego samego efektu: dostęp do strefy robota jest niekontrolowany. OR pozwala to pokazać bardzo przejrzyście, bo podkreśla, że wystarczy pojedyncza przyczyna, żeby ochrona przestała istnieć.
XOR - bramka wykluczająca
Występuje rzadziej, ale się przydaje. Oznacza sytuację, w której do zdarzenia wyjściowego prowadzi dokładnie jedno ze zdarzeń wejściowych, ale nie ich kombinacja. Używamy jej wtedy, gdy skutek zależy od jednej, konkretnej przyczyny z grupy alternatyw.
Priority AND (PAND) - bramka sekwencyjna
To bramka AND z dodatkowym wymogiem kolejności. Zdarzenia muszą wystąpić w określonej sekwencji, żeby dały efekt na wyjściu. Ma sens tam, gdzie kolejność ma kluczowe znaczenie, jak przy zjawiskach dynamicznych.
Voting Gate
Voting gate w FTA to bramka, która uruchamia zdarzenie wyjściowe dopiero wtedy, gdy określona liczba zdarzeń wejściowych wystąpi jednocześnie. Nie wszystkie wejścia muszą zawieść, tylko ustalona minimalna ich liczba. Dzięki temu można modelować sytuacje, w których system toleruje część usterek, ale przekroczenie pewnego progu prowadzi już do zdarzenia niepożądanego.
Inhibit Gate
Działa jak bramka AND, ale z dodatkowym symbolem warunku. Czytamy ją tak: zdarzenie wyjściowe pojawia się tylko wtedy, gdy zdarzenie wejściowe *i* warunek są spełnione. Stosujemy ją, gdy awaria może zajść tylko w specyficznym kontekście.
Transfer Symbol – symbol odwołania
Stosujemy go, kiedy drzewo robi się zbyt rozbudowane. Pozwala przenieść fragment analizy w inne miejsce lub na inną stronę dokumentu. Dzięki temu nie tworzymy gigantycznych schematów, które trudno czytać.
Zdarzenia
Basic Event – zdarzenie podstawowe
Basic event to pojedyncza, elementarna przyczyna awarii, której nie rozbija się już na mniejsze składowe. W drzewie błędów stanowi końcowy punkt analizy. Oznacza konkretny błąd lub usterkę, która może wystąpić samodzielnie, na przykład uszkodzony element, zatkanie, przerwa w obwodzie czy inny prosty mechanizm prowadzący do błędu. Basic events wyznaczają zestaw potencjalnych przyczyn, które bezpośrednio wpływają na zdarzenie szczytowe.
Intermediate Event – zdarzenie pośrednie
Opisuje stan, który powstaje z połączenia niższych przyczyn. Nie jest ostateczną awarią, ale kolejnym krokiem w logicznej układance. Pojawia się na wyjściu bramki.
Undeveloped Event – zdarzenie nierozwinięte
Oznacza potencjalną przyczynę, której nie rozwijamy, bo brakuje danych albo jej rola w analizie jest marginalna. Stosujemy je ostrożnie, żeby nie udawać, że coś wiemy, jeśli w rzeczywistości nie wiemy. Przykładem takiego zdarzenia może być usterka mechaniczna jakiegoś układu, ale w naszej analizie skupiamy się na bezpieczeństwie funkcjonalnym.
Podsumowanie
Analiza FTA pozwala uporządkować proces szukania przyczyn awarii i przedstawić go w przejrzanej formie graficznej. Dzięki temu łatwiej zrozumieć, jak poszczególne elementy systemu wpływają na zdarzenie szczytowe. Niezależnie od tego, czy analiza ma charakter jakościowy czy ilościowy, jej celem jest wskazanie słabych punktów i umożliwienie świadomego podejmowania działań zapobiegawczych. Omówione symbole i struktura drzewa stanowią podstawę do dalszego zgłębiania metody i stosowania jej w bardziej złożonych przypadkach.