Tutorial pakietu FaultTree na podstawie strony:

http://www.openreliability.org/fault-tree-analysis-on-r

1. Fault Tree Basics

W tym przykładzie zachęcamy do myślenia o wodzie przepływającej przez dwa zawory A i B. Bardziej ekscytujące może być myślenie o niej jako o paliwie rakietowym z magazynu paliwa przechodzącym przez pompę A i zawór B do silnika rakietowego.
Zdarzenie górne zostało utworzone jako bramka OR (typ=“lub”), ponieważ wiadomo, że mogą istnieć dwie możliwe przyczyny braku przepływu do Odbiorcy. Te zdarzenia przyczynowe to „brak przepływu w wierszu 2” lub „przepływ bloków komponentu B”. Istnienie dowolnego zdarzenia spowoduje brak przepływu do Odbiorcy.

Można zauważyć, że funkcja addLogic jest bardzo podobna do funkcji ftree.make z wyjątkiem pierwszego argumentu, który pozornie powtarza nazwę drzewa i argument „at”. Pierwszy argument przekazuje obiekt ramki danych drzewa do funkcji, aby można go było zmodyfikować. Wynikiem funkcji będzie zmodyfikowany obiekt dataframe. To jest przykład programowania funkcjonalnego. Argument „at” określa identyfikator rodzica.

Wpisy zdarzeń podstawowych komponentów, takie jak addProbability, mają wystarczająco różne listy argumentów, więc zostały zaimplementowane niezależnie dla każdego typu. Wcześniej zauważono, że każde z tych dwóch zdarzeń może spowodować utratę przepływu do odbiornika, co jest naszym najważniejszym zdarzeniem. Oba są połączone w górnym węźle, który ma identyfikator 1

nasa1<-ftree.make(type="or", name="no flow to", name2="Receiver")
nasa1<-addLogic(nasa1, at=1, type="or", name="no flow in", name2="Line 2")
nasa1<-addProbability(nasa1, at=1, prob=0.1, name="Component B", name2="blocks flow")
nasa1<-addProbability(nasa1, at=2, prob=0.01, name="No Flow", name2="From Source")
nasa1<-addProbability(nasa1, at=2, prob=0.1, name="Component A", name2="blocks flow") 
ftree2html(nasa1, write_file=TRUE)
#browseURL("nasa1.html") otwiera zewnetrzna przegladarke

Połączenie szeregowe kompontentów odpowiada funkcji OR przy drzewie zawodności.

Obliczenie dla bramki OR sumuje jej wpisy podrzędne.
Ale dla prawdopodobieństw musi to być suma probabilistyczna, ponieważ prawdopodobieństwa muszą zawsze znajdować się w przedziale mniejszym niż jeden, większym niż zero.
Suma probabilistyczna wykonywana na bramce OR w ID=2 wynosi:
1-(1-0.01)*(1-0.1)

Należy tutaj zauważyć, że obliczenia bramka po bramce, takie jak ta, nie są zwykle uwzględniane w probabilistycznej analizie ryzyka, ponieważ nieuniknione powielanie zdarzeń i gałęzi w drzewie błędów może generować poważną niedokładność w prawdopodobieństwie wystąpienia największego zdarzenia. W tym przykładzie proste rozwiązanie jest równie dokładne, ponieważ nie ma zduplikowanych wpisów.
Dla niektórych może być kłopotliwe, że węzły z pustymi polami etykiet wskazującymi „brak przepływu w linii 3” i „brak przepływu ze źródła” zostały zignorowane w tym przykładzie. Pakiet FaultTree nie obsługuje używania takich pustych węzłów. Chociaż nie jest to zalecana praktyka, można je wprowadzić jako bramki OR.

Cały powyższy przykład można zapisać prościej jako umieszczenie wszystkich trzech podstawowych zdarzeń pod pojedynczą bramką OR na najwyższym identyfikatorze zdarzenia=1.

nasa2<-ftree.make(type="or", name="no flow to", name2="Receiver")
nasa2<-addProbability(nasa2, at=1, prob=0.01, name="No Flow", name2="From Source")
nasa2<-addProbability(nasa2, at=1, prob=0.1, name="Component A", name2="blocks flow")
nasa2<-addProbability(nasa2, at=1, prob=0.1, name="Component B", name2="blocks flow")
ftree2html(nasa2, write_file=TRUE)


2. Non-Repairable System Models

Geneza analizy drzewa zawodności pojawiła się podczas ewaluacji Minuteman Launch Control System. Technika rozwinęła się w przemyśle lotniczym, głównie w badaniach nad bezpieczeństwem samolotów, statków kosmicznych i broni. Wszystkie te modele charakteryzują się misją, dzięki której system ma działać bez możliwości naprawy. W ujęciu ilościowym podstawową miarą zainteresowania jest prawdopodobieństwo niepowodzenia misji w określonym czasie. Jest to oczywiście dopełnienie niezawodności, czyli prawdopodobieństwa sukcesu w określonym czasie, w określonych warunkach.

Aby zbadać tę lekcję, wybrano przykład z notatek Cliftona Ericksona. Ten doskonały materiał do recenzji można pobrać ze strony: http://www.cs.ucf.edu/~hlugo/cop4331/ericson-fta-tutorial.pdf

Przykład do zbudowania przy użyciu pakietu FaultTree znajduje się na slajdzie 53. Uproszczony diagram dla tego przykładu został zmodyfikowany na podstawie późniejszego, bardziej złożonego przykładu w tym samym tekście.

Niepożądanym zdarzeniem w tym przypadku jest nieumyślne uzbrojenie głowicy.
Przypuszczalnie czas ekspozycji zaczyna się, gdy akumulator jest podłączony do obwodu.


arm1<-ftree.make(type="or", name="Warhead Armed", name2="Inadvertently")
arm1<-addLogic(arm1, at= 1 , type="and", name="Arm Circuit", name2="Relays Closed")
arm1<-addExposed(arm1, at= 2, mttf=1/1.1e-6, exposure=10, tag="E1", name="Relay 1", name2="Fails Closed")
arm1<-addExposed(arm1, at= 2, mttf=1/1.1e-6, exposure=10, tag="E2", name="Relay 2", name2="Fails Closed")
arm1<-addLogic(arm1, at= 1, type="inhibit", name="Arm Power", name2="Is Present")
arm1<-addProbability(arm1, at= 5, prob=1, tag="W1", name="Battery Power", name2="Is Available")
arm1<-addLogic(arm1, at= 5, type="or", name="Arm Circuit Closed", name2="By Computer")
arm1<-addExposed(arm1, at= 7, mttf=1/1.1e-6, exposure=10, tag="E3", name="CPU", name2="Failure")
arm1<-addExposed(arm1, at= 7, mttf=1/1.1e-6, exposure=10, tag="E4", name="Software", name2="Failure")
arm1<-ftree.calc(arm1)
# ftree2html(arm1, write_file=TRUE)


Należy tutaj zwrócić uwagę na kilka kwestii. Najpierw do drzewa dodawane są dane dotyczące podstawowych zdarzeń składowych za pomocą funkcji addExposed. Dwie części danych kwantyfikacji są wprowadzane jako mttf (zgodnie z innymi funkcjami FaultTree addXxx) i ekspozycja [czas]. Grecka litera lambda jest typowo używana do oznaczania wskaźnika awaryjności. Odwrotność wskaźnika awaryjności to średni czas do awarii. Wpisy do argumentów funkcji w R mogą być wyrażeniem zwracającym pożądany wynik. Dla jasności w tym, co się robi, mttf jest wprowadzane jako odwrotność wymienionej lambdy. Wszystkie wprowadzone jednostki muszą być na tej samej podstawie. Oznacza to, że średni czas do awarii wszystkich komponentów w tym przykładzie jest rzędu 1 miliona godzin (~100 lat), a czas ekspozycji dla tej misji wynosi 10 godzin.

Wartości ID są kluczowe dla identyfikacji wszystkich węzłów podczas korzystania z FaultTree. Atrybut tag umożliwia nazywanie wpisów zdarzeń komponentu i wpisów warunków na liściach drzewa. Tagi mogą być bardziej rozpoznawalnymi kombinacjami liter i cyfr, które charakteryzują elementy i są wyświetlane powyżej i po prawej stronie pola etykiety.
Podczas gdy podstawowe komponenty mają wypadkową wartość prawdopodobieństwa (prawdopodobieństwo awarii), w tym przykładzie „Zasilanie z baterii jest dostępne” reprezentuje stan. Warunki są również określane ilościowo za pomocą wartości prawdopodobieństwa. Oczywiście prawdopodobieństwo tego warunku nie oznacza niepowodzenia; wyraźne rozróżnienie między podstawowymi zdarzeniami składowymi a tym stanem. Samouczek kursu Cliftona Ericksona umieścił ten szczególny warunek w węźle graficznym „domu”. To identyfikuje „obecny stan”, a wartość warunku powinna być ograniczona do 1. Grafika domu nie została zaimplementowana w pakiecie FaultTree jako kwestia preferencji. Tutaj rozróżnienie dla wpisu warunku jest zapewnione przez użycie bramki INHIBIT. Należy zauważyć, że kwantyfikacja jest taka sama, niezależnie od tego, czy używana jest bramka AND czy INHIBIT. W przypadku nienaprawialnego modelu systemu użycie INHIBIT dla wpisów warunków jest czysto graficznym sposobem rozróżnienia. Pierwszy wpis w bramce INHIBIT będzie domyślnie traktowany jako warunek, więc kolejność linii funkcji addXxx w skrypcie FaultTree może być znacząca.

3. Repairable System Models


Po początkowych sukcesach analizy drzewa zawodności na arenie lotniczej w latach sześćdziesiątych, raport Rasmussena z połowy lat siedemdziesiątych zapowiedział, że amerykański przemysł jądrowy przyjął analizę drzewa zawodności i probabilistyczną ocenę ryzyka. Uwagę opinii publicznej zwróciła obawa, że utrata chłodzenia rdzenia reaktora, prowadząca do utraty hermetyczności „syndromu chińskiego”. Jako tło historyczne należy przypomnieć, że załogowy lot na Księżyc miał miejsce po raz pierwszy w 1969 r., podczas gdy embargo naftowe z 1973 r. doprowadziło do znacznego rozwoju budowy energetyki jądrowej. Dodatkowo, incydent z 1974 r. w Flixborough w Anglii położył nowy nacisk na bezpieczeństwo procesów w przemyśle chemicznym, naftowym i gazowym, w tym na wykorzystanie analizy drzewa usterek.

To rozszerzone zastosowanie technik drzewa błędów wprowadziło nowy aspekt, polegający na tym, że naprawa lub wymiana uszkodzonych komponentów miała utrzymać ciągłość działania. W tej sferze prawdopodobieństwo niepowodzenia w trakcie misji (niezawodność) jest zastępowane prawdopodobieństwem niepowodzenia w czasie (niedostępność), podczas gdy częstotliwość niepowodzeń staje się ogniskiem większości „najważniejszych” niepożądanych zdarzeń. W tym modelu czas naprawy staje się wymaganym parametrem wejściowym, oprócz wskaźnika awaryjności dla scharakteryzowania komponentów.

Aby wprowadzić ten temat, rozważ hipotetyczny scenariusz pompowania chłodziwa. Niepożądanym zdarzeniem w tym przykładzie jest utrata odpowiedniego przepływu chłodziwa. Taka strata w procesie egzotermicznym, czy to chemicznym, czy nuklearnym, może prowadzić do poważnych obaw o bezpieczeństwo. Chłodziwo jest napędzane przez parę pomp odśrodkowych umieszczonych we wspólnym układzie obciążeń w celu zapewnienia nadmiarowości. Dopóki pracuje jedna z dwóch pomp, można zapewnić odpowiedni przepływ chłodzenia. Zawór sterujący przepływem na połączonym wylocie pomp powoduje ciśnienie wsteczne w pompach, powodując ich „podnoszenie” krzywej pompy w celu zmniejszenia przepływu chłodziwa do normalnego natężenia, ponieważ obie pompy pracują w sposób ciągły. Ta kontrola oszczędza energię i zmniejsza zużycie dalszych komponentów. Zawory zwrotne na wylocie każdej pompy zapobiegają zawracaniu przepływu do tyłu przez niedziałającą pompę.

Obie pompy są napędzane silnikiem elektrycznym. Zasilanie jest kondycjonowane przez transformator i kontrolowane przez kilka wyłączników.


Są to dość realistyczne wartości dla porażki. Czasy naprawy odzwierciedlają założenia dotyczące dostępności części zamiennych, części i personelu naprawczego.

Drzewo błędów dla tego systemu jest konstruowane, obliczane i przeglądane za pomocą następującego skryptu:

cool<-ftree.make(type="or", name="Coolant Flow", name2="Insufficient")
cool<-addLogic(cool, at= 1, type="and", name="Pumps Fail", name2="Independently")
cool<-addLogic(cool, at=1, type="or", name="Common Cause", name2="Pumping Failure")
cool<-addLogic(cool, at=2, type="or", name="Pump 1", name2="Failure")
cool<-addActive(cool, at=4, mttf=30, mttr=24/8760, tag="P1", name="Pump Impeller", name2="Fails")
cool<-addActive(cool, at=4, mttf=10, mttr=24/8760, tag="P1a", display_under=5,
name="Pump Bearings", name2="Fail")
cool<-addActive(cool, at=4, mttf=6, mttr=12/8760, tag="P1b", display_under=6,
name="Pump Seal", name2="Fails")
cool<-addActive(cool, at=4, mttf=10, mttr=24/8760, tag="M1", display_under=7,
name="Pump Motor", name2="Fails")
cool<-addActive(cool, at=4, mttf=25, mttr=8/8760, tag="B1", display_under=8,
name="Pump Motor Control", name2="Breaker Opens")
cool<-addLogic(cool, at=2, type="or", name="Pump 2", name2="Failure")
cool<-addActive(cool, at=10, mttf=30, mttr=24/8760, tag="P2",
name="Pump Impeller", name2="Fails")
cool<-addActive(cool, at=10, mttf=10, mttr=24/8760, tag="P2a", display_under=11,
name="Pump Bearings", name2="Fail")
cool<-addActive(cool, at=10, mttf=6, mttr=12/8760, tag="P2b", display_under=12,
name="Pump Seal", name2="Fails")
cool<-addActive(cool, at=10, mttf=10, mttr=24/8760, tag="M2", display_under=13,
name="Pump Motor", name2="Fails")
cool<-addActive(cool, at=10, mttf=25, mttr=8/8760, tag="B2", display_under=14,
name="Pump Motor Control", name2="Breaker Opens")
cool<-addLogic(cool, at=3, type="or", name="Flow Control", name2="Restricts Flow")
cool<-addActive(cool, at=16, mttf=25, mttr=8/8760, tag="FV", name="Flow Valve Closed",
name2="By Positioner")
cool<-addActive(cool, at=16, mttf=100, mttr=8/8760, tag="FC", display_under=17,
name="Flow Valve Closed", name2="By Flow Controller")
cool<-addActive(cool, at=16, mttf=100, mttr=8/8760, tag="FT", display_under=18,
name="Flow Valve Closed", name2="By Flow Transmitter")
cool<-addLogic(cool, at=3, type="or", name="Flow Recycles Through", name2="Failed Check Valve")
cool<-addLogic(cool, at=20, type="inhibit", name="Pump 1 Stops", name2="with CV1 Failed")
cool<-addProbability(cool, at=21, prob= .01, tag="CV1",
name="Check Valve", name2="Fails on Demand")
cool<-addDuplicate(cool, at=21, dup_id=4)
cool<-addLogic(cool, at=20, type="inhibit", name="Pump 2 Stops", name2="with CV2 Failed")
cool<-addProbability(cool, at=29, prob= .01, tag="CV2",
name="Check Valve", name2="Fails on Demand")
cool<-addDuplicate(cool, at=29, dup_id=10)
cool<-addLogic(cool, at=3, type="or", name="Power Interrupted", name2="To all Pumps")
cool<-addActive(cool, at=37, mttf=25, mttr=12/8760, tag="B3", name="MCC Breaker", name2="Opens")
cool<-addActive(cool, at=37, mttf=25, mttr=12/8760, tag="B4", display_under=38,
name="Transformer Breaker", name2="Opens")
cool<-addActive(cool, at=37, mttf=300, mttr=72/8760, tag="TX", display_under=39, name="Transformer", name2="Fails")
cool<-ftree.calc(cool)
ftree2html(cool, write_file=TRUE)

Ten skrypt wykorzystuje funkcję addActive do definiowania podstawowych zdarzeń. Zwykle okazuje się, że aktywne komponenty działają. Jednak prawdziwym wyznacznikiem jest to, że awarie aktywnych komponentów będą realizowane natychmiast. Ponieważ jest to model, który można naprawić, do zdefiniowania aktywnego komponentu wymagane są zarówno wartości mttf, jak i mttr. W niektórych przypadkach użyto argumentu display_under. Argument ten po prostu pozwala na graficzne przedstawienie podstawowych zdarzeń rodzeństwa w formie pionowego łańcucha pod bramką OR. Gdy ten argument jest ustawiony, sprawdzane są wspólne pochodzenie pod bramką OR, a następnie dokonywana jest modyfikacja pola GParent wiersza komponentu w ramce danych. W tym przypadku szeroki wyświetlacz 5 dzieci pod każdym wyglądem bramki OR definiującej awarię pojedynczej pompy byłby trudny do zobaczenia, gdyby został umieszczony poziomo.

Każdy z zaworów zwrotnych na wylocie pompy modelowano jako stan o prawdopodobieństwie wystąpienia stanu awaryjnego. Te zawory zwrotne nie przejdą definicji aktywnego komponentu, ponieważ nie można stwierdzić, że taki zawór zwrotny mógł zostać uszkodzony podczas normalnej pracy systemu.

Niedostępność każdego aktywnego składnika jest obliczana zgodnie z mttr/(mttf+mttr). Jest to prawdopodobieństwo, że komponent jest w stanie awarii w czasie. Wskaźnik niepowodzeń widoczny na grafice dla każdego aktywnego komponentu wynosi 1/mttf. Wszystkie jednostki czasu muszą być utrzymywane w sposób spójny na wejściu. W tym przypadku lata zostały wybrane w taki sposób, że godziny czasu naprawy muszą być wprowadzone jako godziny/8760, tak aby czas naprawy był reprezentowany jako ułamek roku.

W bramkach OR prawdopodobieństwo wyjściowe jest wynikiem sumy probabilistycznej ze zdarzeń wejściowych, identycznej z obliczeniami w modelu nienaprawialnym. Połączony wskaźnik błędów to bezpośrednia suma wejściowych wskaźników błędów. Czas naprawy jest obliczany na podstawie łącznego współczynnika awarii i niedostępności aktywnego składnika, aby przedstawić średni czas naprawy.

Na bramkach INHIBIT, wskaźnik awaryjności i niedostępność awarii pojedynczej pompy połączone w zduplikowanej bramce OR są mnożone przez prawdopodobieństwo awarii zaworu zwrotnego. Jeżeli tylko 1% przypadków awarii zaworu zwrotnego, to tylko 1% przypadków awarii pojedynczej pompy spowoduje awarię recyklingu. Przyjęto założenie, że czas naprawy w przypadku awarii pojedynczej pompy pozostaje niezmieniony, dlatego wypadkowa niedostępność po obliczeniu hamowania jest iloczynem prawdopodobieństwa stanu i niedostępności węzła zasilającego.

Obliczanie bramki AND jest podobne do dwóch bramek INHIBIT połączonych operatorem OR. Niezależna podwójna awaria występuje pod warunkiem, że jeden składnik jest w stanie awarii, podczas gdy drugi ulega awarii. Dwie bramki hamujące połączone w ten sposób byłyby nieco niedokładne z powodu podwójnego liczenia czasów, gdy obie są wyłączone. Rzeczywiste obliczenie ‘międzyproduktów’ dla współczynników błędów na bramce AND jest wykonywane według następującej formuły: fail_rate1 * prob2 + fail_rate2 * prob1 - (fail_rate1+fail_rate2) * prob1 *prob2. Prawdopodobieństwa niedostępności są łączone w AND jako iloczyn prawdopodobieństw wejściowych, identyczny z obliczeniami w modelu nienaprawialnym. Czas naprawy po połączeniu ORAZ jest następnie obliczany na podstawie łącznego współczynnika awarii i niedostępności składnika aktywnego, podobnie jak w przypadku bramki OR.

Zalecanym ćwiczeniem dla uczniów jest wykonanie sprawdzenia obliczeń bramki dla tego przykładu w arkuszu kalkulacyjnym, aby potwierdzić zrozumienie tych procesów.

W tym przykładzie pętla kontroli przepływu w znacznym stopniu obciąża powodzenie odpowiedniego chłodzenia. Nierzadko zdarza się, że w projekcie znajdują się funkcje zapewniające bezpieczeństwo, efektywność energetyczną, a nawet przypuszczalne zwiększenie niezawodności, które mają negatywny wpływ na niepożądane zdarzenie. W takich przypadkach może być bardziej efektywne, aby analityk drzewa błędów nie próbował eliminować funkcji (która z pewnością napotka opór), ale zidentyfikował zalecenia, które mogą ulepszyć system dzięki ich zastosowaniu. Pętla kontroli przepływu w tym przykładzie przyczynia się do nie więcej niż połowy obliczonego wskaźnika niepowodzeń dla zdarzenia szczytowego. Samo posiadanie obu pomp napędzanych silnikiem elektrycznym ma równoważne znaczenie. Zazwyczaj, jeśli wymagana jest poprawa rzędu wielkości, można rozważyć takie cechy, jak pompy zasilane parą i/lub olejem napędowym we wtórnym układzie chłodzenia. Chociaż nie zostało to zbadane w tym przykładzie, różnorodność źródeł chłodziwa może być uzasadniona jako dodatkowa rezerwa.

Główny nacisk na znaczenie to udział w częstości niepowodzeń w bramkach OR bezpośrednio pod szczytowym wydarzeniem. Wartości prawdopodobieństwa, niedostępność, mają mniejsze znaczenie, dopóki awaria tego systemu nie zostanie uznana za warunek połączenia z innymi zabezpieczeniami.