Schemat blokowy niezawodności: wizualne narzędzie, które pokazuje, czy redundancja faktycznie przynosi jakiekolwiek korzyści

Kluczowe wnioski

• Diagram blokowy niezawodności (RBD) = wizualny model pokazujący, jak niezawodność poszczególnych elementów składa się na niezawodność systemu.
• Komponenty w szeregu: niezawodność systemu = iloczyn niezawodności komponentów (znacznie niższa).
• Komponenty równoległe: niezawodność systemu = 1 - (iloczyn nieskuteczności) (znacznie wyższa).
• Inwestycje w redundancję oceniane przez RBD przed zakupem pokazują, czy matematyka uzasadnia wydatki.
• Większość zakładów podejmuje decyzje o redundancji bez obliczeń RBD i przepłaca lub przypadkowo niedoinwestowuje.

Krótko: Diagram blokowy niezawodności (RBD) modeluje, jak niezawodność komponentów składa się na niezawodność systemu. Komponenty w szeregu mnożą się (znacznie obniżają niezawodność systemu); komponenty równoległe zwiększają pokrycie (znacznie podnoszą niezawodność). Ocena RBD przed inwestycją w redundancję pokazuje, czy matematyka uzasadnia wydatki. Większość zakładów podejmuje decyzje o redundancji bez RBD i przepłaca lub niedoinwestowuje, kierując się intuicją. Zobacz też Rola inżyniera ds. niezawodności.

Czym jest RBD

Diagram przedstawiający komponenty systemu ułożone w szeregu, równolegle lub w kombinacji. Każdy komponent ma znaną niezawodność (prawdopodobieństwo działania w określonym okresie).

Diagram oblicza niezawodność systemu na podstawie niezawodności komponentów.

Komponenty szeregowe

Jeśli komponent A i komponent B są w szeregu (oba muszą działać):

R(system) = R(A) x R(B)

Dwa komponenty o niezawodności 95% w szeregu dają niezawodność systemu 90,25%. Szereg mnoży karę.

Komponenty równoległe

Jeśli komponent A i komponent B są równoległe (wystarczy, że jeden działa):

R(system) = 1 - (1 - R(A)) x (1 - R(B))

Dwa komponenty o niezawodności 95% w konfiguracji równoległej dają niezawodność systemu 99,75%. Równoległość mnoży pokrycie.

Dlaczego to ma znaczenie przy decyzjach o redundancji

Trzy zakłady rozważają redundancję:

Zakład A: pompa o niezawodności 95%, rozważa drugą pompę. RBD pokazuje, że nowa niezawodność to 99,75%. Solidna inwestycja dla krytycznej usługi.

Zakład B: sterownik o niezawodności 99,5%, rozważa redundantny sterownik. RBD pokazuje, że nowa niezawodność to 99,9975%. Inwestycja marginalna; oryginał był już bardzo niezawodny.

Zakład C: linia o niezawodności 90% z 5 stanowiskami w szeregu. Dodanie redundancji tylko na jednym stanowisku poprawia je z 90% do 99%, ale linia nadal ma 81% (po karze szeregowej). Trzeba poprawić wszystkie stanowiska, nie tylko jedno.

RBD jasno ujawnia każdy przypadek. Bez niego decyzje o redundancji są podejmowane intuicyjnie.

Jak zbudować RBD

1. Zdefiniuj granice systemu. Co jest systemem; co liczy się jako awaria.
2. Wypisz komponenty. Urządzenie, czujnik, sterownik itp.
3. Mapuj zależności. Szereg (wymagane wszystkie) vs równoległe (wystarczy jeden z N).
4. Przypisz niezawodności komponentów. Z danych historycznych, specyfikacji producenta lub oszacowania.
5. Oblicz niezawodność systemu. Ręcznie dla małych systemów; oprogramowaniem dla złożonych.
6. Przetestuj alternatywy. Co się stanie, jeśli dodamy redundancję tu vs tam?

Typowe wzorce

1. Systemy z dominacją szeregu. Linie produkcyjne, gdzie każde stanowisko jest wymagane. Niezawodność szybko spada wraz ze wzrostem liczby elementów w szeregu. Poprawa wymaga podniesienia niezawodności każdego komponentu lub dodania elementów równoległych.

2. Systemy z dominacją równoległości. Systemy zasilania z redundantnym źródłem, sieci z redundantnymi ścieżkami. Dobrze tolerują awarie komponentów.

3. Mieszane. Większość rzeczywistych systemów. Niektóre segmenty są równoległe, inne szeregowe.

Obliczanie ROI redundancji

1. Obecna niezawodność systemu. R(obecne).
2. Niezawodność po proponowanej redundancji. R(nowe).
3. Poprawa. Redukcja prawdopodobieństwa awarii.
4. Oszczędzony koszt przestojów na okres. Poprawa x koszt przestoju x długość okresu.
5. Porównaj z kosztem redundancji. Koszt kapitałowy + koszty operacyjne redundantnych komponentów.

RBD sprawia, że to obliczenie jest uzasadnione.

Częste błędy

1. Dodawanie redundancji do komponentów, które nie są wąskim gardłem. Podwajanie najbardziej niezawodnego komponentu niewiele daje.

2. Zakładanie niezależności. Komponenty mogą mieć wspólne tryby awarii (wspólne zasilanie, wspólne chłodzenie), które unieważniają redundancję równoległą.

3. Statyczne założenie niezawodności. Niezawodność komponentu pogarsza się z wiekiem; przy decyzjach długoterminowych przyjmij konserwatywne wartości.

4. Ignorowanie czasu przełączenia. Redundancja aktywna zapewnia natychmiastowe przełączenie; redundancja pasywna ma opóźnienie, podczas którego system jest niedostępny.

Czego RBD nie uwzględnia

• Konserwacja przywraca niezawodność; RBD jako migawka statyczna tego nie pokazuje.
• Awaria wynikająca z wspólnej przyczyny (wspólne zasilanie, wspólne środowisko) wymaga analizy drzewa błędów.
• Efekty starzenia/wytarcia wymagają innej matematyki.

W tych przypadkach RBD jest punktem wyjścia, a nie ostateczną odpowiedzią.

Związek z OEE

Dostępność w ramach OEE pogarsza się przy niskiej niezawodności systemu. Ocena architektury zasobów przez RBD wspiera ukierunkowane poprawy niezawodności, podnosząc dostępność OEE.

Jak nowoczesny CMMS wspiera RBD

Nowoczesny CMMS pozyskuje niezawodności komponentów z historii zleceń roboczych, wspiera modelowanie RBD na poziomie hierarchii zasobów i ocenia opcje redundancji w odniesieniu do rzeczywistych danych o awariach.

CMMS Fabrico pozyskuje niezawodności komponentów z historii zleceń roboczych i obsługuje analizę w stylu RBD przy decyzjach o redundancji.

Zobacz, jak Fabrico robi to automatycznie — poznaj OEE dla produkcji lub umów się na demo.

Powiązana lektura

• Rola inżyniera ds. niezawodności

Najczęściej zadawane pytania

Skąd wziąć liczby niezawodności komponentów?

Dane historyczne MTBF z Twojego CMMS; specyfikacje producenta; bazy danych branżowych (OREDA dla sektora naftowego i gazowego, inne dla poszczególnych branż).

Czy RBD wymaga oprogramowania?

Małe systemy można policzyć w arkuszu kalkulacyjnym. Złożone, wieloelementowe systemy zyskują na użyciu oprogramowania RBD.

Jaki jest związek z analizą drzewa błędów?

FTA (analiza drzewa błędów) jest bardziej ogólna i uwzględnia wspólne przyczyny awarii. RBD jest prostsze i szybsze dla oczywistych struktur szereg/równoległość.

Jak dokładne są liczby niezawodności?

Tak dokładne, jak dane źródłowe. Najbardziej wiarygodne są dane historyczne z podobnego trybu pracy.

Czy każdy zasób powinien mieć RBD?

Nie. Stosuj tam, gdzie rozważane są decyzje o redundancji lub większe inwestycje w niezawodność.