Pięć technik niezawodności w analizie odporności przemysłowych systemów na awarie

Poznaj pięć praktycznych technik oceny niezawodności systemów odpornych na uszkodzenia. Dowiedz się, jak analiza drzewa błędów (FTA), analiza rodzajów i skutków możliwych błędów (FMEA), symulacja M...

Dlaczego odporność na uszkodzenia wymaga czegoś więcej niż redundantnego sprzętu

Każdy system przemysłowy wcześniej czy później doświadczy usterek. Czujniki ulegają rozkalibrowaniu, zasilacze się zużywają, łącza komunikacyjne stają się niestabilne, a elementy mechaniczne zużywają się pod wpływem powtarzających się obciążeń. Celem inżynierii odporności na uszkodzenia nie jest więc tworzenie urządzeń, które nigdy nie ulegną awarii. Jej celem jest zapewnienie, aby przewidywalne usterki nie przeradzały się natychmiast w niekontrolowane awarie systemu.

System odporny na uszkodzenia może nadal realizować akceptowalną funkcję po utracie dostępności jednego lub większej liczby komponentów. W niektórych zastosowaniach system musi utrzymać pełną produkcję. W innych zmniejszona wydajność jest dopuszczalna do czasu, aż konserwacja przywróci uszkodzony kanał. Systemy o znaczeniu krytycznym dla bezpieczeństwa mogą natomiast przechodzić do kontrolowanego stanu bezpiecznego, gdy dalsza praca stwarzałaby niedopuszczalne ryzyko.

Elementy redundantne często stanowią część tej strategii, ale samo powielenie nie dowodzi odporności na uszkodzenia. Dwa sterowniki mogą nadal zależeć od jednego zasilacza, jednego przełącznika sieciowego lub jednej konfiguracji oprogramowania. Dwa przetworniki mogą współdzielić tę samą linię impulsową i ulec awarii z powodu tej samej blokady. Analiza niezawodności musi zatem obejmować całą architekturę, w tym zależności, które nie są od razu widoczne na liście urządzeń.

W tej pracy szczególnie przydatnych jest pięć metod. Analiza drzewa błędów bada, w jaki sposób kombinacje uszkodzeń mogą doprowadzić do określonego zdarzenia szczytowego. Analiza rodzajów i skutków uszkodzeń bada, w jaki sposób mogą ulec awarii poszczególne komponenty oraz jak te awarie wpływają na cały system. Symulacja Monte Carlo pozwala analizować niepewność w wielu możliwych scenariuszach pracy i awarii, natomiast analiza przyczyn źródłowych bada, dlaczego doszło do rzeczywistego zdarzenia. Modele Markowa opisują, jak systemy naprawialne przechodzą w czasie między stanami sprawności, pogorszenia działania, awarii i przywrócenia do działania.

Inżynieria niezawodności przemysłowej systemów, które nie mogą uniknąć każdej usterki

Rysunek 1. Systemy przemysłowe nie mogą uniknąć każdej usterki, ale zdyscyplinowane podejście do inżynierii niezawodności może zapobiec przekształceniu wielu usterek w całkowite awarie.

Niezawodność, dostępność, bezpieczeństwo i utrzymywalność to nie to samo

Terminologia dotycząca niezawodności jest często stosowana nieprecyzyjnie, co może powodować nieporozumienia podczas przeglądów projektowych. Niezawodność opisuje prawdopodobieństwo, że urządzenie będzie pełnić wymaganą funkcję przez określony czas. Dostępność opisuje, czy urządzenie jest gotowe do pracy wtedy, gdy potrzebuje go proces. System może sporadycznie ulegać awariom, a mimo to utrzymywać wysoką dostępność, jeśli naprawy przebiegają szybko, a części zamienne są natychmiast dostępne.

Utrzymywalność opisuje, jak skutecznie można zdiagnozować uszkodzony system i przywrócić go do działania. Bezpieczeństwo opisuje, czy skutki awarii pozostają w akceptowalnych granicach ryzyka dla personelu, środowiska i urządzeń. Właściwości te wzajemnie na siebie wpływają, ale poprawa jednej z nich nie oznacza automatycznej poprawy wszystkich pozostałych. Wyłączenie ochronne może zmniejszyć dostępność produkcyjną, jednocześnie znacząco poprawiając bezpieczeństwo zakładu.

Tolerancja uszkodzeń obejmuje wszystkie te dziedziny. Zależy od redundancji, diagnostyki, izolacji, możliwości naprawy i kontrolowanej degradacji. Zależy również od jasnego zdefiniowania wymaganej funkcji. Inżynierowie nie mogą określić, czy system jest odporny na uszkodzenia, dopóki nie wiedzą, jaka wydajność musi zostać zachowana po każdym wiarygodnym uszkodzeniu.

Na przykład system zabezpieczenia sprężarki może wymagać zachowania możliwości awaryjnego wyłączenia po awarii jednego czujnika. System sterowania procesem może wymagać jedynie utrzymania stabilnej pracy podczas wymiany jednego sterownika. Układ zabezpieczeń elektroenergetycznych może wymagać niezależnych kanałów, aby pojedyncza usterka wspólna nie mogła wyłączyć zarówno podstawowego, jak i rezerwowego zabezpieczenia. Techniki niezawodności pomagają inżynierom przełożyć te wymagania na projekty, które można poddać testom.

Wybór metody na podstawie pytania inżynierskiego

Pięć technik niezawodności dotyczy różnych aspektów tego samego problemu. FTA rozpoczyna się od niepożądanego zdarzenia w systemie i prowadzi wstecz do uszkodzeń, które mogły je spowodować. FMEA rozpoczyna się od komponentów lub funkcji i analizuje kolejne skutki każdego trybu uszkodzenia. Symulacja Monte Carlo bada wpływ niepewności, wielokrotnie uruchamiając model systemu dla wielu losowo wygenerowanych warunków.

RCA zwykle rozpoczyna się po rzeczywistym incydencie i wykorzystuje dowody do oddzielenia widocznych objawów od leżących u ich podstaw przyczyn technicznych i organizacyjnych. Modelowanie Markowa koncentruje się na stanach systemu oraz szybkościach, z jakimi system przechodzi między tymi stanami. Jest szczególnie użyteczne, gdy naprawy, praca w trybie gotowości, obniżona wydajność i zakres diagnostyki w znacznym stopniu wpływają na dostępność.

Właściwy wybór zależy od stawianego pytania. Zespół badający, w jaki sposób może dojść do całkowitej utraty chłodzenia, zwykle rozpocznie od FTA. Zespół projektowy analizujący każdą możliwą awarię przetwornika, sterownika i zaworu uzyska więcej korzyści z FMEA. Menedżer ds. majątku porównujący niepewne okresy między przeglądami może zastosować symulację Monte Carlo, natomiast inżynier niezawodności obliczający długoterminową dostępność redundantnej pary sterowników może wybrać model Markowa.

Metody te wzajemnie się uzupełniają, ale nie można ich stosować zamiennie. FMEA może zidentyfikować tryby uszkodzeń, które później staną się zdarzeniami podstawowymi w drzewie błędów. Wyniki RCA mogą skorygować nierealistyczne założenia dotyczące uszkodzeń w modelu Markowa. Symulacja Monte Carlo może sprawdzić, jak niepewność prawdopodobieństw wpływa na wnioski wyciągnięte z FTA lub planowania utrzymania.

Analiza drzewa błędów rozpoczyna się od skutku

Analiza drzewa błędów jest metodą dedukcyjną, która rozpoczyna się od jednego jasno zdefiniowanego niepożądanego zdarzenia. Zdarzenie to nazywa się zdarzeniem szczytowym. Odpowiednie przykłady obejmują całkowitą utratę wody zasilającej kocioł, niesprawność funkcji wyłączenia awaryjnego turbiny, całkowitą utratę komunikacji ze sterownikiem lub niekontrolowany wzrost ciśnienia w reaktorze. Definicja musi być na tyle szczegółowa, aby umożliwiać przeprowadzenie miarodajnej analizy.

Zdarzenie szczytowe opisane wyłącznie jako „awaria systemu” jest zwykle zbyt nieprecyzyjne. Nie określa, która funkcja uległa awarii, jak długo trwała awaria ani jaki stan pracy obowiązywał. Lepsza definicja mogłaby brzmieć: „utrata całego przepływu wody chłodzącej przez ponad sześćdziesiąt sekund podczas normalnej produkcji”. Takie sformułowanie wyznacza jasne granice analizy.

Po zdefiniowaniu zdarzenia szczytowego zespół identyfikuje bezpośrednie warunki, które mogą do niego doprowadzić. Warunki te są rozkładane na zdarzenia niższego poziomu aż do osiągnięcia podstawowych awarii komponentów, zakłóceń zewnętrznych lub działań człowieka. Bramki logiczne łączą zdarzenia i opisują sposób, w jaki się one kombinują. Bramki LUB wskazują, że dowolne wymienione zdarzenie może wywołać zdarzenie wyższego poziomu, natomiast bramki I wymagają jednoczesnego wystąpienia kilku zdarzeń.

Ukończone drzewo przedstawia wizualnie logikę awarii. Umożliwia specjalistom ds. elektryki, mechaniki, oprzyrządowania, procesu, utrzymania ruchu i bezpieczeństwa wspólną analizę tego samego systemu. Ten wspólny model jest jedną z największych praktycznych zalet FTA. Ułatwia kwestionowanie ukrytych założeń, zanim zostaną one utrwalone w projekcie.

Analiza drzewa uszkodzeń łącząca awarie komponentów ze zdarzeniem szczytowym w instalacji przemysłowej

Rysunek 2. Drzewo uszkodzeń działa wstecz od zdefiniowanego zdarzenia szczytowego i identyfikuje kombinacje awarii niższego poziomu, które mogą do niego doprowadzić.

Opracowywanie drzewa uszkodzeń krok po kroku

Pierwszym praktycznym zadaniem jest ustalenie granic systemu. Inżynierowie muszą zdecydować, które urządzenia, media pomocnicze, oprogramowanie, działania operatorów i usługi zewnętrzne należy uwzględnić w analizie. Analiza systemu chłodzenia może obejmować pompy, zawory, dystrybucję energii, oprzyrządowanie oraz logikę sterowania. Może być również konieczne uwzględnienie źródła wody, warunków środowiskowych i reakcji operatora, jeśli czynniki te mogą wpływać na zdarzenie szczytowe.

Zespół identyfikuje następnie przyczyny bezpośrednie. Całkowita utrata chłodzenia może nastąpić, ponieważ wszystkie pompy stają się niedostępne, wspólny kolektor zasilający zostaje zablokowany lub zawory odcinające zamykają się nieprawidłowo. Każda przyczyna bezpośrednia jest dalej rozkładana. Niedostępność pompy może wynikać z awarii silnika, zatarcia łożyska, utraty ssania, awarii sterownika lub utraty zasilania elektrycznego.

Proces trwa do momentu, gdy dalszy podział nie poprawiłby już oceny. Zdarzenia najniższego poziomu traktuje się jako zdarzenia podstawowe i można im przypisać prawdopodobieństwa lub częstości występowania awarii. Następnie strukturę logiczną można ocenić jakościowo lub ilościowo. Nawet gdy nie są dostępne dokładne dane liczbowe, drzewo nadal może ujawnić pojedyncze punkty awarii i nieoczekiwane współdzielone zależności.

Ilościowa analiza FTA łączy prawdopodobieństwa zdarzeń zgodnie ze strukturą bramek. Obliczenia mogą wydawać się proste, jednak założenia dotyczące niezależności wymagają wnikliwej oceny. Dwa zdarzenia, które mają wspólne źródło zasilania, środowisko, czynność konserwacyjną lub defekt oprogramowania, nie są w pełni niezależne. Ignorowanie tych zależności może sprawić, że redundantny projekt będzie wyglądał na znacznie bezpieczniejszy, niż jest w rzeczywistości.

Minimalne zbiory odcinające pokazują najgroźniejsze kombinacje

Zbiór odcinający to kombinacja zdarzeń podstawowych, która powoduje zdarzenie szczytowe. Minimalny zbiór odcinający nie zawiera zbędnych zdarzeń, co oznacza, że usunięcie dowolnego z nich uniemożliwiłoby wystąpienie zdarzenia szczytowego. Kombinacje te pomagają inżynierom identyfikować najkrótsze i najważniejsze ścieżki awarii. Są szczególnie cenne, gdy duże drzewo uszkodzeń zawiera setki zdarzeń.

Minimalny zbiór odcinający zawierający jedno zdarzenie wskazuje, że jedna awaria może bezpośrednio spowodować zdarzenie szczytowe. Takie ustalenia zwykle wymagają natychmiastowej uwagi projektowej. Zespół może dodać redundancję, usprawnić izolację, zapewnić oddzielne zasilanie lub wprowadzić kolejną warstwę ochronną. Zbiory odcinające zawierające dwa lub trzy zdarzenia często reprezentują awarie w architekturach redundantnych.

Nie każdy krótki zbiór odcinający wiąże się z takim samym ryzykiem. Kombinacja dwóch zdarzeń obejmujących częste awarie może mieć większe znaczenie niż pojedyncze, niezwykle rzadkie zdarzenie zewnętrzne. Na istotność wpływają również czas wykrycia i naprawy. Ukryta awaria, która pozostaje niewykryta przez wiele miesięcy, powoduje znacznie dłuższy okres narażenia niż usterka wykryta i naprawiona natychmiast.

Oprogramowanie FTA może uszeregować zbiory odcinające według obliczonego udziału. Inżynierowie powinni jednak nadal analizować fizyczne znaczenie tych wartości. Matematycznie małe prawdopodobieństwo może opierać się na słabych założeniach lub ogólnych danych, które nie odzwierciedlają rzeczywistej instalacji. Osąd inżynierski pozostaje niezbędny na każdym etapie analizy.

Przykład: redundancja pomp wody zasilającej kocioł, która nie jest rzeczywiście niezależna

Rozważmy elektrownię, w której pracują dwie pompy wody zasilającej kocioł. Każda z pomp może utrzymać minimalny wymagany przepływ, więc system wydaje się zdolny do tolerowania awarii jednej pompy. Proste zliczenie urządzeń sugeruje pełną redundancję. Drzewo uszkodzeń może jednak ujawnić inną rzeczywistość po uwzględnieniu współdzielonych zależności.

Oba silniki pomp mogą być zasilane z tej samej magistrali elektrycznej. Obie pompy mogą czerpać medium ze wspólnego kolektora ssawnego, zależeć od tego samego systemu sterowania lub otrzymywać polecenia na podstawie jednego pomiaru poziomu. Pojedyncza awaria magistrali, zablokowany kolektor ssawny lub nieprawidłowy wspólny sygnał może zatem unieruchomić obie pompy jednocześnie. Pozorna redundancja dwóch pomp nie chroniłaby przed tymi wspólnymi awariami.

Analiza może prowadzić do kilku praktycznych usprawnień. Oddzielne źródła zasilania elektrycznego mogą ograniczyć ryzyko wspólnej utraty zasilania. Zróżnicowane pomiary poziomu mogą zmniejszyć zależność od jednej technologii przetworników. Niezależne ścieżki sterowania, usprawniona obsługa ręczna i lepsze monitorowanie ssania mogą wzmocnić architekturę bez konieczności dodawania kolejnej kompletnej pompy.

Ten przykład pokazuje, dlaczego analiza drzewa błędów jest bardziej użyteczna niż samo liczenie redundantnych urządzeń. Ocenia ona, czy urządzenia pozostają niezależne w rzeczywistych warunkach pracy. Wskazuje również, gdzie dodatkowa złożoność zapewnia rzeczywistą ochronę, a gdzie jedynie stwarza pozory ochrony.

Gdzie analiza drzewa błędów sprawdza się dobrze — a gdzie nie

Analiza drzewa błędów jest szczególnie skuteczna w przypadku funkcji bezpieczeństwa, systemów ochrony, dystrybucji energii elektrycznej, sieci komunikacyjnych i innych zastosowań, w których niepożądane zdarzenie jest jasno zdefiniowane. Jej struktura graficzna ułatwia przeglądy projektu i dyskusje z organami regulacyjnymi. Można ją stosować jakościowo do ujawniania słabych punktów lub ilościowo do szacowania prawdopodobieństwa wystąpienia zdarzenia szczytowego.

Metoda staje się mniej skuteczna, gdy zdarzenie szczytowe jest nieprawidłowo zdefiniowane. Jej utrzymanie może również stać się trudne, gdy drzewo rozrasta się do tysięcy zdarzeń. Sekwencje dynamiczne, działania konserwacyjne i zmieniające się stany pracy mogą wymagać specjalistycznych bramek lub dodatkowych technik modelowania. Statyczne drzewo błędów nie opisuje w naturalny sposób każdej zależności czasowej.

Działania człowieka również wymagają starannego uwzględnienia. Prawdopodobieństwo reakcji operatora zależy od jakości alarmu, konstrukcji procedury, wyszkolenia, obciążenia pracą, dostępnego czasu i warunków korzystania z interfejsu. Przypisanie jednej ogólnej wartości prawdopodobieństwa błędu człowieka może ukryć te różnice. W poważnych analizach należy zaangażować specjalistów ds. czynników ludzkich, gdy działanie operatora ma kluczowe znaczenie dla wyniku.

Analiza drzewa błędów (FTA) jest zatem najbardziej skuteczna jako część szerszego programu niezawodności. FMEA może dostarczyć szczegółowych informacji o rodzajach uszkodzeń komponentów, natomiast metody Markowa lub Monte Carlo mogą uwzględniać naprawy, sekwencje zdarzeń i niepewność. Żadnego pojedynczego drzewa nie należy traktować jako kompletnego odwzorowania wszystkich zachowań systemu.

Analiza rodzajów i skutków uszkodzeń zaczyna się od komponentu

Analiza rodzajów i skutków uszkodzeń (FMEA) wykorzystuje podejście indukcyjne. Zamiast rozpoczynać od zdarzenia szczytowego, zespół zaczyna od elementu, funkcji lub etapu procesu. Następnie analizuje, w jaki sposób dany element może ulec awarii oraz jaki wpływ każda awaria miałaby lokalnie i w całym systemie. Dzięki temu podejściu FMEA jest szczególnie przydatna podczas projektowania i przeglądu urządzeń.

Przetwornik ciśnienia może ulec awarii na kilka różnych sposobów. Jego sygnał wyjściowy może dryfować w górę, dryfować w dół, zatrzymać się na jednej wartości, stać się niestabilny lub całkowicie zaniknąć. Każdy tryb awarii powoduje inne skutki operacyjne. Zawyżony odczyt może wywołać niepotrzebne wyłączenie, natomiast zaniżony odczyt może ukryć niebezpieczny stan ciśnienia.

FMEA zmusza zespół do opisania tych różnic, zamiast rejestrowania jedynie „uszkodzenia przetwornika”. Analizuje również istniejące środki zapobiegania i wykrywania. Analiza może wskazać diagnostykę, logikę porównawczą, testy funkcjonalne, alarmy, obejścia lub kontrole operatorskie, które ograniczają skutek. Słaba wykrywalność często staje się równie istotna jak pierwotny tryb uszkodzenia.

Arkusz analizy trybów uszkodzeń i ich skutków (FMEA) do przeglądu niezawodności przemysłowej

Rysunek 3. FMEA ocenia poszczególne tryby uszkodzeń, ich skutki, dotkliwość oraz dostępne środki zapobiegania im lub ich wykrywania.

Co powinien zawierać skuteczny arkusz FMEA

Przydatny arkusz FMEA zaczyna się od określenia elementu i wymaganej od niego funkcji. Tryb uszkodzenia opisuje, w jaki sposób funkcja może zostać utracona, ograniczona lub wykonana nieprawidłowo. Skutek lokalny opisuje, co dzieje się na poziomie komponentu, natomiast skutek systemowy opisuje szersze konsekwencje operacyjne lub związane z bezpieczeństwem. Przyczyny i mechanizmy zapisuje się oddzielnie od skutków.

Arkusz dokumentuje również istniejące środki kontroli. Środki zapobiegawcze zmniejszają prawdopodobieństwo wystąpienia uszkodzenia. Środki wykrywania ujawniają uszkodzenie, zanim spowoduje ono niedopuszczalny skutek. Przykłady obejmują autotesty diagnostyczne, porównywanie redundantnych sygnałów, wartości graniczne alarmów, testy funkcjonalne, inspekcje oraz konserwację predykcyjną.

Wiele organizacji przypisuje oceny dotkliwości, częstości występowania i wykrywalności. Wartości te są czasem mnożone w celu obliczenia liczby priorytetu ryzyka. Liczba ta może pomóc w ustalaniu priorytetów, ale nigdy nie powinna zastępować oceny technicznej. Różne kombinacje mogą dawać ten sam wynik, nawet gdy ich skutki zasadniczo się różnią.

Rzadkie uszkodzenie katastroficzne może wymagać większej uwagi niż częsta drobna niedogodność, nawet gdy ich obliczone wyniki wydają się podobne. Dlatego poziom dotkliwości należy oceniać niezależnie. Zespoły powinny również nadawać priorytet działaniom, które usuwają mechanizm uszkodzenia lub ograniczają jego skutek, zamiast polegać wyłącznie na dodatkowych inspekcjach.

Przykład: redundantne wejścia PLC ze wspólnym słabym punktem

Rozważmy dwa kanały wejść cyfrowych monitorujące jeden obiektowy wyłącznik awaryjny. Architektura wydaje się redundantna, ponieważ sygnał jest odbierany przez dwa wejścia sterownika PLC. Analiza FMEA sprawdza, czy cała ścieżka sygnału jest rzeczywiście niezależna. Uwzględnia styk obiektowy, okablowanie, zasilanie wejść, zespoły zacisków, moduły, logikę oraz działanie diagnostyki.

Możliwe tryby uszkodzeń obejmują przerwę w obwodzie, zwarcie, zespawany styk, kanał zablokowany w stanie wysokim, kanał zablokowany w stanie niskim lub utratę wspólnego zasilania wejściowego. Analiza sprawdza również, czy wykrywana jest niezgodność między kanałami. Jeśli oba kanały współdzielą jeden styk obiektowy i jeden przewód, wiele wiarygodnych uszkodzeń wpływa jednocześnie na oba kanały.

Przegląd może wykazać, że zdublowane moduły wejściowe zapewniają niewielką dodatkową ochronę. Może być konieczne zastosowanie oddzielnych styków, monitorowanych obwodów obiektowych, niezależnych torów zasilania lub zróżnicowanych zasad pomiaru. Procedura testu okresowego musi również weryfikować cały tor sygnałowy, a nie tylko moduł PLC.

W przypadku architektur ochronnych inżynierowie mogą również przeanalizować odpowiednie przemysłowe moduły bezpieczeństwa zaprojektowane z myślą o pokryciu diagnostycznym, redundancji i kontrolowanym sposobie uszkodzenia. Dobór sprzętu nadal musi być zgodny z pełnym cyklem życia bezpieczeństwa i nie może zastąpić analizy przeprowadzonej dla konkretnego zastosowania.

FMEA projektu i FMEA procesu dotyczą różnych rodzajów ryzyka

FMEA projektu dotyczy zaprojektowanego produktu lub systemu. Analizuje, czy wybrana architektura, komponenty, materiały i funkcje sterowania mogą działać zgodnie z założeniami. Metodę tę powszechnie stosuje się podczas opracowywania koncepcji, projektowania szczegółowego i wprowadzania zmian projektowych. Jest najbardziej wartościowa, zanim modyfikacja projektu stanie się kosztowna.

FMEA procesu obejmuje produkcję, montaż, instalację, uruchomienie lub czynności konserwacyjne. Szafa może mieć prawidłowy projekt elektryczny, ale proces instalacji nadal może doprowadzić do powstania luźnych zacisków, odwróconej polaryzacji, zastosowania bezpieczników o niewłaściwych wartościach znamionowych lub błędnego oznaczenia przewodów. Czynności konserwacyjne mogą skutkować wgraniem nieprawidłowego oprogramowania układowego, zastosowaniem nieodpowiednich części zamiennych, wyłączeniem alarmów lub pozostawieniem aktywnych obejść.

Te dwa rodzaje FMEA powinny wzajemnie się uzupełniać. Środki projektowe mogą zmniejszać wrażliwość instalacji, natomiast środki procesowe mogą zapobiegać błędom wykonawczym, których nie da się wyeliminować na etapie projektowania. Przegląd wyłącznie projektu urządzenia pozostawia wiele zagrożeń związanych z całym cyklem życia bez rozpoznania. Przegląd wyłącznie procesu pracy może ukryć słabości wbudowane w pierwotną architekturę.

W przypadku krytycznych systemów automatyki obie analizy należy aktualizować po wprowadzeniu istotnych modyfikacji. Wymiana sterownika, migracja sieci, aktualizacja oprogramowania lub zmiana procedury testu okresowego mogą wprowadzić nowe rodzaje uszkodzeń. Historyczne arkusze nie powinny pozostawać niezmienione, gdy zakład wokół nich ewoluuje.

FMECA zapewnia bardziej formalną ocenę krytyczności

Analiza rodzajów i skutków uszkodzeń oraz krytyczności (FMECA) rozszerza strukturę FMEA o formalne obliczenia krytyczności. Metoda może wykorzystywać częstości uszkodzeń komponentów, czas narażenia podczas eksploatacji, fazy misji, kategorie dotkliwości i prawdopodobieństwa warunkowe. Jest przydatna, gdy duży system obejmuje wiele rodzajów uszkodzeń, a zasoby inżynierskie należy skierować na najistotniejsze czynniki.

Obliczenia krytyczności w dużym stopniu zależą od jakości danych. Ogólne bazy danych dotyczące częstości uszkodzeń stanowią punkt wyjścia, ale mogą nie odzwierciedlać rzeczywistej instalacji. Temperatura, drgania, zanieczyszczenia, naprężenia elektryczne, jakość konserwacji i cykl pracy wpływają na rzeczywistą wydajność. Gdy dostępna jest wystarczająca historia eksploatacji, założenia ogólne powinny zostać zastąpione dowodami dotyczącymi konkretnego zakładu.

Analiza powinna również rozróżniać awarie wykrywane natychmiast od awarii, które pozostają ukryte. Ukryta awaria elementu rezerwowego może nie wpływać na produkcję do momentu awarii innego komponentu lub wystąpienia zapotrzebowania. Długi okres pozostawania w ukryciu może sprawić, że stosunkowo rzadka awaria nabierze dużego znaczenia. Dlatego należy uwzględnić odstępy między wykrywaniem a także skuteczność testów sprawdzających.

FMECA jest najbardziej użyteczna, gdy jej wyniki prowadzą do działań projektowych lub związanych z utrzymaniem ruchu. Złożona tabela rankingowa ma niewielką wartość, jeśli nie wpływa na architekturę, zapasy części zamiennych, diagnostykę, testy ani procedury operacyjne. Celem pozostaje praktyczne ograniczanie ryzyka, a nie wykonywanie obliczeń dla nich samych.

Gdzie FMEA sprawdza się dobrze — i gdzie może wprowadzać w błąd

FMEA zapewnia zdyscyplinowany przegląd komponentów jeden po drugim. Jest stosunkowo łatwa do wyjaśnienia i sprzyja udziałowi pracowników z obszarów inżynierii, eksploatacji, utrzymania ruchu, jakości i bezpieczeństwa. Powstały rejestr działań można bezpośrednio powiązać ze zmianami projektowymi, inspekcjami, diagnostyką i usprawnieniami utrzymania ruchu.

Metoda może stać się powtarzalna przy stosowaniu do bardzo dużych systemów. Zespoły mogą poświęcać nadmiernie dużo czasu na dokumentowanie mało istotnych trybów awarii, jednocześnie przeoczając wzajemne oddziaływania w systemie. Tradycyjna FMEA również zazwyczaj analizuje jedną awarię naraz. Wiele jednoczesnych awarii i zdarzenia zależne od sekwencji mogą nie być wyraźnie widoczne.

Systemy ocen stwarzają kolejne ryzyko. Zespoły mogą dostosowywać oceny, aby uzyskać preferowany priorytet, lub traktować wynik końcowy jako bardziej obiektywny niż leżący u jego podstaw osąd. Niska ocena nie dowodzi, że awaria jest akceptowalna. Zdarzenia o dużej dotkliwości, awarie o wspólnej przyczynie oraz wymagania prawne powinny być poddawane odrębnemu przeglądowi.

Jakość FMEA zależy od osób, które ją przeprowadzają. Arkusz przygotowany przez jednego projektanta może pomijać realia eksploatacji znane operatorom i technikom. Rzetelne analizy łączą wiedzę projektową z rzeczywistą historią utrzymania ruchu i doświadczeniem eksploatacyjnym.

Symulacja Monte Carlo przekształca niepewność w rozkład

Obliczenia niezawodności przemysłowej często obejmują dane wejściowe obarczone niepewnością. Okres eksploatacji komponentów jest zmienny, czas naprawy się zmienia, dostawy części zamiennych są nieprzewidywalne, a obciążenia środowiskowe wpływają na charakterystykę awarii. Pojedyncza wartość średnia nie zawsze może odzwierciedlać te różnice. Symulacja Monte Carlo rozwiązuje ten problem poprzez wielokrotne losowanie.

Inżynier najpierw tworzy model systemu i przypisuje rozkłady prawdopodobieństwa zmiennym obarczonym niepewnością. Następnie symulacja generuje wiele możliwych kombinacji. W jednym przebiegu można założyć, że pompa ulegnie awarii po 8000 godzin i zostanie naprawiona w ciągu czterech godzin. Inny przebieg może wskazywać na późniejszą awarię, ale znacznie dłuższą naprawę, ponieważ wymagana część zamienna jest niedostępna.

Po wykonaniu tysięcy lub milionów realizacji wyniki tworzą rozkład. Model może oszacować oczekiwany czas przestoju, straty produkcyjne, dostępność systemu, prawdopodobieństwo pomyślnego wykonania zadania, zapotrzebowanie na części zamienne lub koszty utrzymania. Może także pokazać prawdopodobieństwo wystąpienia skrajnych wyników, które zniknęłoby przy przedstawieniu tylko jednej wartości średniej.

Rozkład symulacji Monte Carlo na potrzeby analizy niezawodności przemysłowej i przestojów

Rysunek 4. Symulacja Monte Carlo ocenia wiele losowo wygenerowanych scenariuszy uszkodzeń i napraw, aby oszacować zakres możliwych wyników.

Budowa wiarygodnego modelu niezawodności Monte Carlo

Jakość symulacji zależy od modelu systemu. Model musi uwzględniać podzespoły, zasady działania, rozkłady uszkodzeń, sposób prowadzenia napraw, zależności, logikę rezerwy oraz zasoby utrzymania. Może także obejmować pogodę, zapotrzebowanie produkcyjne, opóźnienia logistyczne i reakcję personelu, jeśli czynniki te wpływają na wydajność systemu.

Każda symulowana realizacja odwzorowuje działanie systemu w czasie. Podzespoły ulegają awariom zgodnie z wylosowanymi rozkładami, naprawy rozpoczynają się, gdy zasoby stają się dostępne, a model rejestruje, czy system pozostaje sprawny, działa w stanie ograniczonym czy jest niedostępny. Powtarzanie tego procesu pozwala oszacować różne miary wydajności.

Walidacja ma kluczowe znaczenie. Zespół powinien porównać model z uproszczonymi obliczeniami, znanymi przypadkami eksploatacyjnymi i historycznymi wynikami zakładu. Nieoczekiwane wyniki należy zbadać, a nie akceptować tylko dlatego, że pochodzą z oprogramowania. Imponująca wizualnie symulacja może być błędna, jeśli jej podstawowa logika jest niekompletna.

Analiza wrażliwości pomaga określić, które założenia mają największy wpływ na wynik. Jeśli czas naprawy ma znacznie większy wpływ niż intensywność uszkodzeń, zarządzanie może uzyskać większe korzyści dzięki poprawie dostępności części zamiennych i szybkości diagnostyki. Jeśli dominuje prawdopodobieństwo przyczyny wspólnej, dodanie większej liczby identycznych podzespołów może przynieść niewielkie korzyści.

Wybór rozkładów prawdopodobieństwa odpowiadających mechanizmowi uszkodzeń

Rozkład wykładniczy zakłada stałą intensywność uszkodzeń. Może być odpowiedni dla niektórych podzespołów elektronicznych w okresie ich użytecznej eksploatacji. Rozkład Weibulla jest bardziej elastyczny i może opisywać awarie wczesnego okresu eksploatacji, awarie losowe lub zużycie. Rozkłady lognormalne są często przydatne do modelowania czasów napraw i procesów, na które wpływa kilka czynników multiplikatywnych.

Wybór powinien odzwierciedlać mechanizm fizyczny, a nie wygodę oprogramowania. Awaria łożyska spowodowana zużyciem nie przebiega w sposób naturalny tak samo jak losowy błąd komunikacji. Zastosowanie stałej intensywności uszkodzeń w obu przypadkach może zniekształcić prognozy długoterminowe. Inżynierowie niezawodności powinni przeanalizować historię eksploatacji i mechanizmy uszkodzeń przed wyborem rozkładu.

Dane historyczne często wymagają oczyszczenia. Systemy utrzymania ruchu mogą mylić planowaną wymianę z awarią funkcjonalną. Daty awarii mogą być wprowadzane jako daty otwarcia zlecenia roboczego, a nie jako daty wystąpienia usterki. Nazwy urządzeń, liczba godzin pracy i kody awarii również mogą być niespójne w poszczególnych zakładach.

Ograniczona ilość danych nie uniemożliwia analizy, ale niepewność powinna pozostać widoczna. Wstępne szacunki mogą opierać się na ocenach ekspertów, informacjach od dostawców i branżowych bazach danych. Model powinien testować realistyczny zakres zamiast przedstawiać jedno niepewne założenie jako precyzyjny fakt.

Przykład: dostępność stacji z trzema kompresorami

Rozważmy stację z trzema kompresorami gazu. Dwa urządzenia są wymagane do pełnej produkcji, a trzecie zapewnia rezerwową zdolność produkcyjną. Każda maszyna ma inną liczbę godzin pracy, historię konserwacji i charakterystykę działania układu chłodzenia. Jednocześnie można przeprowadzać tylko jedną poważną naprawę, ponieważ stacja dysponuje jednym wyspecjalizowanym zespołem utrzymania ruchu.

Dostawa zapasowych łożysk trwa kilka dni, a awarie układu chłodzenia zdarzają się częściej przy wysokich temperaturach otoczenia. Te wzajemne oddziaływania trudno odwzorować za pomocą jednego prostego równania dostępności. Model Monte Carlo może losować awarie kompresorów, czasy napraw, okresy występowania określonych warunków pogodowych, dostępność techników i opóźnienia logistyczne.

Wyniki mogą przedstawiać dostępność przy pełnej wydajności, pracę ze zmniejszoną wydajnością oraz całkowity przestój stacji. Kierownictwo może porównywać alternatywne inwestycje. Utrzymywanie dodatkowych łożysk w magazynie może skuteczniej ograniczyć skrajnie długie przestoje niż zatrudnienie kolejnego technika do ogólnych prac konserwacyjnych. Poprawa niezawodności układu chłodzenia może przynieść większą wartość niż wymiana sprawnego skądinąd kompresora.

Model może również testować odstępy między przeglądami. Krótsze odstępy między konserwacją zapobiegawczą mogą ograniczyć liczbę awarii, ale zwiększyć zaplanowany czas przestojów i liczbę błędów wywołanych konserwacją. Symulacja umożliwia ocenę obu tych skutków w ramach tego samego modelu operacyjnego.

Gdzie symulacja Monte Carlo sprawdza się dobrze — a gdzie zawodzi

Metody Monte Carlo są potężnym narzędziem, gdy współdziała ze sobą wiele niepewnych zmiennych. Mogą odwzorowywać złożoną logistykę, kolejki napraw, wpływ pogody, popyt produkcyjny i decyzje dotyczące konserwacji. Uzyskany rozkład dostarcza więcej informacji niż pojedyncza średnia. Umożliwia także podejmowanie decyzji opartych na ryzyku, pokazując prawdopodobieństwo wystąpienia poważnych, lecz rzadkich zdarzeń.

Główną słabością jest wiarygodność modelu. Skomplikowana symulacja może tworzyć fałszywe poczucie pewności, ponieważ jej wyniki sprawiają wrażenie precyzyjnych numerycznie. Program oblicza jedynie konsekwencje założeń wprowadzonych przez analityka. Pominięte zależności lub nierealistyczne rozkłady mogą prowadzić do mylących wyników.

Symulacja wymaga także wystarczającej liczby uruchomień, aby uzyskać stabilne oszacowania. Prawdopodobieństwa zdarzeń rzadkich mogą wymagać specjalistycznych technik próbkowania, ponieważ zwykła symulacja losowa wymagałaby niepraktycznie dużej liczby uruchomień. Należy podawać przedziały ufności, aby użytkownicy rozumieli niepewność statystyczną.

Metoda ta jest zatem najbardziej wartościowa, gdy logika modelu, źródła danych i ograniczenia pozostają przejrzyste. Decyzje dotyczące niezawodności nie powinny opierać się na wykresie, którego założeń nie można wyjaśnić pracownikom działów eksploatacji i inżynierii.

Analiza przyczyn źródłowych rozpoczyna się po zdarzeniu

Analiza przyczyn źródłowych bada, dlaczego doszło do rzeczywistej awarii, problemu z jakością lub zdarzenia związanego z bezpieczeństwem. Wykracza poza identyfikację uszkodzonego komponentu. Silnik może zatrzymać się, ponieważ zatarło się łożysko, ale wymiana łożyska jedynie przywraca działanie. Dochodzenie musi ustalić, dlaczego łożysko znalazło się w takim stanie.

Głębsze przyczyny mogą obejmować zanieczyszczenie, nieprawidłowe smarowanie, niewłaściwe przechowywanie, uszkodzenia podczas instalacji, nadmierne obciążenie procesu lub pominięcie inspekcji. Warunki organizacyjne również mogą mieć znaczenie. Zadania utrzymania ruchu mogły zostać usunięte, części zamienne mogły być nieodpowiednie, a presja produkcyjna mogła opóźnić działania korygujące.

Dlatego RCA rozdziela objawy, bezpośrednie przyczyny fizyczne, warunki sprzyjające oraz podstawowe słabości systemu. To rozróżnienie zapobiega traktowaniu każdej naprawy jako trwałego rozwiązania. Dostarcza także dowodów, które mogą usprawnić przyszłe analizy FMEA, FTA, planowanie utrzymania ruchu i procedury eksploatacyjne.

Analiza przyczyn źródłowych śledząca awarię przemysłową od objawów do przyczyn leżących u jej podstaw

Rysunek 5. RCA śledzi awarię poza widocznym objawem i identyfikuje warunki techniczne oraz organizacyjne, które umożliwiły jej wystąpienie.

Dowody należy zabezpieczyć, zanim zakład powróci do normalnej pracy

Dowody przemysłowe mogą szybko zniknąć. Operatorzy mogą zresetować alarmy, technicy mogą wymienić moduły, a warunki procesu mogą się zmienić. Dzienniki sterowników mogą nadpisać wcześniejsze zdarzenia, a uszkodzone komponenty mogą zostać wyrzucone przed przeprowadzeniem badania. Dlatego zdyscyplinowany proces RCA rozpoczyna się od zabezpieczenia dowodów.

Zespół powinien zebrać trendy z systemu archiwizacji danych, listy alarmów, dzienniki zdarzeń sterowników, rejestry przekaźników, zlecenia pracy, zdjęcia, uszkodzone części, wersje oprogramowania, pliki konfiguracyjne oraz obserwacje operatorów. Każdy element należy zidentyfikować według źródła i czasu. Dowody fizyczne powinny pozostać zabezpieczone do czasu, aż dochodzenie ustali, czy wymagane jest dalsze badanie.

Synchronizacja czasu wymaga szczególnej uwagi. Sterownik, system archiwizacji danych, przekaźnik zabezpieczeniowy, serwer i system utrzymania ruchu mogą rejestrować różne znaczniki czasu. Przed utworzeniem sekwencji zdarzeń analitycy muszą skorygować te różnice. W przeciwnym razie późniejszy alarm może błędnie wyglądać na zdarzenie inicjujące.

Wywiady z operatorami należy przeprowadzić szybko, ale starannie. Ludzie mogą pamiętać kolejność zdarzeń i kontekst, których nie zarejestrowały systemy automatyczne. Ich wypowiedzi należy traktować jako dowody, a nie jako podstawę do obwiniania. Celem jest zrozumienie środowiska operacyjnego, w którym podejmowano decyzje.

Tworzenie osi czasu zdarzeń przed zadaniem pytania „dlaczego?”

Dobra oś czasu oddziela zweryfikowane fakty od interpretacji. Rejestruje to, co wydarzyło się przed awarią, w jej trakcie i po niej. Każde zdarzenie powinno być powiązane ze źródłem, takim jak wartość z systemu rejestracji danych, zapis alarmu, działanie konserwacyjne, fotografia lub zeznanie świadka. Luki i niespójności powinny pozostać widoczne.

Pierwszy alarm wyświetlony operatorowi nie zawsze jest pierwszym zdarzeniem fizycznym. Lawiny alarmów mogą ukryć warunek inicjujący pod setkami komunikatów wtórnych. Dane o sekwencji zdarzeń o wysokiej rozdzielczości mogą wykazać, że niestabilność ciśnienia, zakłócenie zasilania lub utrata komunikacji rozpoczęły się wcześniej. Oś czasu pomaga odróżnić przyczynę od skutku.

Po zrozumieniu sekwencji zdarzeń zespół może zastosować takie narzędzia jak metoda pięciu pytań „dlaczego?”, diagramy rybiej ości, analiza barier, analiza zmian lub wykresy czynników przyczynowych. Proste zdarzenia można wyjaśnić za pomocą krótkiego łańcucha przyczynowego. Złożone incydenty zwykle obejmują kilka wzajemnie oddziałujących warunków technicznych i organizacyjnych.

Dochodzenie nie powinno kończyć się na znalezieniu jednego prawdopodobnego wyjaśnienia. Alternatywne hipotezy należy sprawdzić w kontekście dowodów. Niepotwierdzone założenia powinny pozostać oznaczone jako założenia, a nie być przedstawiane jako potwierdzone przyczyny.

Przykład: Powtarzające się awarie napędu o zmiennej prędkości

W zakładzie wielokrotnie dochodzi do awarii napędu o zmiennej prędkości sterującego jednym przenośnikiem. Po każdym zdarzeniu służby utrzymania ruchu wymieniają napęd, a produkcja wraca do normy. Kilka miesięcy później kolejny napęd ulega awarii. Powtarzające się wymiany sugerują, że sam napęd może nie być całym problemem.

Zespół RCA porównuje daty awarii z zapisami dotyczącymi warunków środowiskowych i konserwacji. Większość awarii wystąpiła w gorących okresach letnich. Trendy temperatury w szafie pokazują długotrwałą pracę powyżej preferowanego zakresu. Inspekcja ujawnia zatkane filtry, ograniczony przepływ powietrza i duże nagromadzenie pyłu wokół toru chłodzenia.

Historia konserwacji pokazuje, że po zmianie poziomu zatrudnienia regularne czyszczenie filtrów usunięto z harmonogramu konserwacji zapobiegawczej. Napęd jest uszkodzonym komponentem, ale nadmierna temperatura w szafie stanowi bezpośrednią przyczynę fizyczną. Ograniczona wentylacja i brak zadania konserwacyjnego to przyczyny współtowarzyszące oraz organizacyjne.

Działanie korygujące powinno zatem wykraczać poza kolejną wymianę napędu. Zakład może przywrócić konserwację filtrów, zainstalować alarmy temperatury, poprawić chłodzenie szafy oraz przeanalizować konstrukcję obudowy. Skuteczność należy zweryfikować podczas kolejnego okresu wysokich temperatur.

Działania korygujące muszą być powiązane ze zweryfikowanymi przyczynami

Wiele raportów RCA traci na jakości podczas planowania działań korygujących. Zespoły mogą zalecać dodatkowe szkolenia bez udowodnienia, że wiedza była niewystarczająca. Mogą zmieniać procedury, gdy rzeczywistym problemem jest zła konstrukcja urządzeń. Mogą dodawać inspekcje, które nie są w stanie wykryć rzeczywistego mechanizmu awarii.

Każde działanie powinno dotyczyć zweryfikowanej przyczyny lub warunku sprzyjającego. Powinno mieć właściciela, termin realizacji i określoną metodę weryfikacji. Organizacja powinna rozróżniać tymczasowe ograniczenie skutków, działanie korygujące i długoterminowe działanie zapobiegawcze. Przywrócenie produkcji nie jest tym samym co zapobieganie ponownemu wystąpieniu zdarzenia.

Skuteczność należy ocenić po wdrożeniu. Zakończone działanie nie jest automatycznie skuteczne. Zakład powinien sprawdzić, czy prawdopodobieństwo awarii się zmniejszyło, czy nowe zabezpieczenie jest stosowane oraz czy nie wprowadziło innego ryzyka. Ta informacja zwrotna zamyka pętlę doskonalenia niezawodności.

Poważne dochodzenia mogą wymagać niezależnego przeglądu. Zespoły ściśle zaangażowane w zdarzenie mogą pozostawać pod wpływem wcześniejszych założeń lub presji organizacyjnej. Przegląd zewnętrzny lub międzyfunkcyjny może podważyć analizę, zanim ostateczne wnioski zostaną zaakceptowane.

Błąd ludzki rzadko jest pełną przyczyną źródłową

„Błąd operatora” i „błąd utrzymania” często pojawiają się w słabych dochodzeniach. Etykiety te opisują, kto wykonał końcową czynność, ale nie wyjaśniają, dlaczego jej wykonanie stało się prawdopodobne. Ludzie pracują w ramach interfejsów, procedur, poziomów obsady, wymagań produkcyjnych, systemów szkoleniowych i konstrukcji urządzeń. Dochodzenie powinno zbadać wszystkie te warunki.

Operator może wybrać niewłaściwe element sterujący, ponieważ dwa obiekty na ekranie wyglądają niemal identycznie. Technik może zamontować niewłaściwą część, ponieważ oznaczenia są niespójne. Przełożony może odroczyć konserwację, ponieważ organizacja nagradza nieprzerwaną produkcję, nie zapewniając jednocześnie realistycznego okna na wyłączenie.

Zrozumienie tych warunków nie znosi indywidualnej odpowiedzialności. Zapobiega temu, by ten sam system skłonił inną osobę do popełnienia tego samego błędu. Dochodzenie skupione na przypisywaniu winy może zaspokoić doraźne zapotrzebowanie na wskazanie odpowiedzialności, ale pozostawić źródłową słabość bez zmian.

Skuteczna analiza przyczyn źródłowych bada, w jaki sposób system wpłynął na podjętą decyzję. Sprawdza, czy alarmy były zrozumiałe, procedury praktyczne, obciążenie pracą rozsądne, a wymagane narzędzia dostępne. Takie pytania prowadzą do skuteczniejszych działań korygujących niż samo instruowanie ludzi, aby zachowali większą ostrożność.

Gdzie analiza przyczyn źródłowych sprawdza się dobrze — a gdzie nie

RCA przekształca rzeczywiste doświadczenia eksploatacyjne w wiedzę zapobiegawczą. Może ujawnić słabe punkty konstrukcji, braki w utrzymaniu, problemy proceduralne i presję organizacyjną, które umknęły analizom predykcyjnym. Jej ustalenia mogą usprawnić modele niezawodności i standardy dla przyszłych projektów.

Metoda ta jest reaktywna, ponieważ rozpoczyna się po wystąpieniu zdarzenia. Branże, w których awarie mogą mieć poważne konsekwencje, nie mogą polegać wyłącznie na wyciąganiu wniosków z awarii. Nadal niezbędne są metody proaktywne, takie jak FMEA i FTA. RCA powinno je uzupełniać, aktualizując założenia na podstawie dowodów z rzeczywistej eksploatacji.

Dochodzenia mogą również stać się subiektywne. Tendencja do potwierdzania może skłaniać zespoły do faworyzowania pierwszego wyjaśnienia, które pasuje do faktów. Brakujące dowody mogą sprawić, że wnioski pozostaną niepewne. Dobre raporty wyraźnie oddzielają potwierdzone przyczyny, czynniki współuczestniczące, hipotezy i nierozstrzygnięte kwestie.

Wartość RCA zależy od dalszej realizacji ustaleń. Technicznie solidne dochodzenie przynosi niewielkie korzyści, gdy działania są opóźniane, ograniczane lub nigdy nie zostają zweryfikowane. Zaangażowanie kierownictwa jest zatem równie ważne jak umiejętności analityczne.

Modele Markowa śledzą zmiany stanów systemu

Modelowanie Markowa przedstawia system za pomocą zdefiniowanych stanów pracy. Prosty system może obejmować tylko stan pracy i stan awarii. System odporny na uszkodzenia zwykle wymaga dodatkowych stanów, takich jak pełna redundancja, obniżona sprawność, awaria, naprawa lub oczekiwanie na część zamienną. Przejścia łączą te stany.

Współczynnik awaryjności może przenieść system ze stanu pełnej sprawności do stanu obniżonej sprawności. Kolejna awaria może spowodować przejście ze stanu obniżonej sprawności do stanu niedostępności. Współczynnik napraw może przywrócić pełną sprawność systemu. Model oblicza prawdopodobieństwo, że system będzie znajdować się w każdym ze stanów w czasie.

Ta struktura jest szczególnie przydatna w przypadku systemów naprawialnych. Może uwzględniać redundancję, urządzenia rezerwowe, pokrycie diagnostyczne, reakcję służb utrzymania ruchu i częściową zdolność produkcyjną. W przeciwieństwie do prostego wzoru na niezawodność pokazuje, jak długo system może pozostawać podatny na zagrożenia po pierwszej awarii.

Model niezawodności Markowa pokazujący przejścia między stanami pracy i awarii

Rysunek 6. Modele Markowa opisują, jak systemy przechodzą między stanami sprawności, obniżonej sprawności, awarii i naprawy.

Model dwustanowy przedstawia podstawową zasadę

Najprostszy model Markowa zawiera jeden stan pracy i jeden stan awarii. Współczynnik awaryjności steruje przejściem ze stanu pracy do stanu awarii. Współczynnik napraw steruje przejściem z powrotem do stanu pracy. Na podstawie tych przejść model może oszacować dostępność w określonym okresie lub w warunkach stanu ustalonego.

Ten model jest przydatny w przypadku prostych urządzeń naprawialnych, ale nie opisuje w pełni większości redundantnych systemów automatyki. Sterownik dwukanałowy może nadal działać po awarii jednego kanału. System pozostaje funkcjonalny, ale traci redundancję. Przechodzi w stan obniżonej sprawności i jest bardziej narażony na drugą awarię.

Dodanie stanu obniżonej sprawności pozwala modelowi obliczyć, jak często i jak długo system działa bez pełnej ochrony. Szybkość naprawy nabiera kluczowego znaczenia. System z niezawodnymi komponentami może mimo to spędzać zbyt dużo czasu w stanie obniżonej sprawności, jeśli diagnozowanie usterek, dostawa części zamiennych lub zatwierdzanie konserwacji przebiega wolno.

Model może również rozróżniać awarie wykryte i niewykryte. Wykryta awaria kanału może uruchomić natychmiastową naprawę. Niewykryta awaria może pozostać ukryta do chwili wystąpienia żądania lub innej awarii. Pokrycie diagnostyczne zmienia strukturę przejść, a tym samym wpływa na obliczoną dostępność i ryzyko.

Przykład: para dwóch redundantnych sterowników

Rozważmy dwa sterowniki połączone w parę redundantną. Stan pierwszy oznacza, że oba sterowniki są sprawne. Stan drugi oznacza, że jeden sterownik uległ awarii, podczas gdy drugi nadal sprawuje kontrolę. Stan trzeci oznacza utratę obu sterowników i całkowity brak możliwości sterowania.

Model uwzględnia częstość awarii każdego sterownika oraz częstość napraw po wykryciu awarii. Może również obejmować awarię przełączenia, wspólną utratę zasilania i wspólną wadę oprogramowania. Te dodatkowe przejścia zapobiegają przyjmowaniu w analizie założenia o doskonałej niezależności.

Wyniki mogą rozróżniać dostępność przy pełnej redundancji od dostępności funkcjonalnej. System może być zdolny do sterowania procesem przez większą część roku, a jednocześnie przez znaczną liczbę godzin mieć tylko jeden sprawny sterownik. Taki okres działania w stanie obniżonej sprawności może być nieakceptowalny w zastosowaniu krytycznym.

Model może porównywać strategie poprawy. Szybsza wymiana części zapasowej może skuteczniej ograniczyć okres narażenia w stanie obniżonej sprawności niż dodanie trzeciego sterownika. Lepsza diagnostyka może przynieść większe korzyści niż niewielkie zmniejszenie częstości awarii sprzętu. Analiza Markowa pozwala mierzyć te kompromisy.

Urządzenia rezerwowe wymagają czegoś więcej niż stanu awarii jednostki aktywnej

Redundancja rezerwowa wprowadza dodatkowe zachowania. Pompa rezerwowa może pozostawać wyłączona do chwili awarii pompy pracującej. W jednostce rezerwowej może występować ukryte uszkodzenie, może ona nie uruchomić się albo może wystąpić problem z układem logicznym przełączenia. Zawory odcinające również mogą nie przestawić się do wymaganej pozycji.

Model Markowa może uwzględniać stany, w których urządzenie aktywne jest sprawne, urządzenie rezerwowe jest niedostępne, nastąpiła awaria przełączenia, wydajność jest zmniejszona, a system całkowicie utracił sprawność. Testy okresowe przesuwają system z nieznanego stanu ukrytego uszkodzenia w kierunku stanu znanego. Odstęp między testami wpływa na to, jak długo mogą występować ukryte awarie.

Zasady utrzymania można oceniać w ramach tej samej struktury. Krótsze odstępy między testami poprawiają wykrywanie ukrytych uszkodzeń, ale zwiększają nakład pracy związany z utrzymaniem i mogą wprowadzać dodatkowe błędy. Model może porównywać te przeciwstawne skutki, zamiast zakładać, że częstsze testowanie zawsze jest lepsze.

Analiza rezerwowego urządzenia powinna obejmować również logistykę napraw. Awaria elementu rezerwowego może nie przerwać produkcji natychmiast, więc naprawę można odłożyć. Takie opóźnienie pozostawia system bez ochrony, gdy później ulegnie awarii jednostka aktywna. Dlatego priorytety operacyjne wpływają na niezawodność w takim samym stopniu jak charakterystyka sprzętu.

Założenie Markowa zapewnia zarówno prostotę, jak i ograniczenia

Podstawowy model Markowa zakłada, że przyszłe zachowanie związane z przejściami zależy od bieżącego stanu, a nie od pełnej historii. Założenie to upraszcza matematykę i często wymaga stałych intensywności przejść. Niektóre urządzenia przemysłowe dość dobrze spełniają to przybliżenie w ograniczonym okresie.

Starzenie i nagromadzone uszkodzenia mogą naruszać to założenie. Mocno zużyte łożysko nie ma takiego samego przyszłego zachowania w zakresie uszkodzeń jak nowe łożysko, nawet jeśli oba obecnie działają. Dodatkowe stany degradacji mogą przybliżać starzenie, natomiast do dokładniejszego odwzorowania mogą być potrzebne modele semi-Markowa lub inne modele.

Eksplozja liczby stanów to kolejne wyzwanie. Każdy stan komponentu może zwielokrotniać liczbę możliwych stanów systemu. Złożony zakład z redundancją może szybko wygenerować tysiące lub miliony kombinacji. Aby utrzymać analizę na możliwym do opanowania poziomie, może być konieczna redukcja modelu, grupowanie lub symulacja.

Model powinien zawierać wystarczająco dużo szczegółów, aby wspierać podejmowanie decyzji, ale nie musi przedstawiać każdej fizycznej zmienności. Nadmierna złożoność powoduje problemy z utrzymaniem i walidacją. Zbyt prosty model ukrywa istotne zachowania, natomiast zbyt szczegółowy staje się niemożliwy do wyjaśnienia.

Gdzie modelowanie Markowa sprawdza się dobrze — a gdzie nie

Modelowanie Markowa dobrze sprawdza się w przypadku naprawialnych systemów redundantnych, urządzeń rezerwowych, trybów pracy zdegradowanej oraz pokrycia diagnostycznego. Umożliwia analizę dostępności i pokazuje, jak reakcja utrzymania ruchu zmienia ekspozycję systemu na zagrożenia. Jest szczególnie przydatne, gdy znaczenie ma sekwencja stanów uszkodzeń i napraw.

Metoda zależy od prawidłowego zdefiniowania stanów i intensywności przejść. Założenia o stałych intensywnościach mogą nie odzwierciedlać starzenia, zmienności warunków środowiskowych ani jakości konserwacji. Uszkodzenia wspólnej przyczyny należy reprezentować jawnie, a nie ukrywać ich w niezależnych intensywnościach uszkodzeń komponentów.

Wyniki należy poprzeć analizą wrażliwości. Zespół powinien sprawdzić, jak zmieniają się wnioski przy zmianie intensywności uszkodzeń, czasów napraw, pokrycia diagnostycznego i założeń dotyczących uszkodzeń wspólnej przyczyny. Projekt, który wydaje się akceptowalny tylko przy jednym optymistycznym założeniu, nie jest odporny.

Modele Markowa są narzędziami analitycznymi, a nie fizycznym dowodem. Testy, dane eksploatacyjne, FMEA i FTA pozostają niezbędne. Model pomaga porównywać strategie, ale nie może zastąpić weryfikacji rzeczywistej architektury.

Wykorzystanie pięciu metod jako jednego systemu niezawodności

Pięć technik zapewnia największą wartość, gdy są ze sobą powiązane. FMEA może zidentyfikować szczegółowe tryby uszkodzeń komponentów na etapie projektowania. Następnie FTA może określić, które kombinacje przyczyniają się do wystąpienia krytycznego zdarzenia w systemie. Modelowanie Markowa może opisać zachowanie systemu po pierwszym uszkodzeniu i podczas naprawy.

Symulacja Monte Carlo może testować niepewne dane wejściowe, takie jak czas naprawy, dostawa części zamiennych, pogoda i obciążenie pracami konserwacyjnymi. RCA dostarcza dowodów po rzeczywistych awariach i może ujawnić założenia pominięte w pierwotnych modelach. Modele należy następnie aktualizować, zamiast zachowywać je jako dokumenty historyczne.

Załóżmy, że analiza FTA traktuje awarie dwóch sterowników jako niezależne. Późniejsze RCA wykazuje, że oba sterowniki uległy awarii po załadowaniu przez jednego technika konserwacji tej samej nieprawidłowej konfiguracji. Drzewo uszkodzeń musi uwzględniać wspólne zdarzenie związane z konserwacją. Modele Markowa i Monte Carlo również powinny uwzględniać nową zależność.

Ten proces sprzężenia zwrotnego tworzy żywy program niezawodności. Analiza predykcyjna wyznacza kierunek projektowania, dane z eksploatacji weryfikują założenia, a wyniki dochodzeń ulepszają kolejne generacje modeli. Prace nad niezawodnością stają się częścią cyklu życia systemu, a nie jednorazowym wymaganiem projektowym.

Awarie o wspólnej przyczynie mogą zniweczyć całą architekturę redundantną

Awarie o wspólnej przyczynie wpływają na wiele kanałów za pośrednictwem jednego podstawowego czynnika. Częstymi przykładami są wspólne zasilanie, chłodzenie, infrastruktura sieciowa, oprogramowanie, narażenie środowiskowe i praktyki konserwacyjne. Awarie te są szczególnie niebezpieczne, ponieważ mogą zniweczyć redundancję, która na papierze wygląda solidnie.

Fizyczne rozdzielenie ogranicza niektóre przyczyny wspólne. Zróżnicowane urządzenia lub oprogramowanie mogą ograniczyć inne. Niezależna weryfikacja może zmniejszyć liczbę błędów konserwacyjnych i konfiguracyjnych. Dywersyfikacja zwiększa jednak również złożoność szkoleń, zarządzania częściami zamiennymi, testowania i integracji.

Właściwe rozwiązanie zależy od ryzyka. Zastosowanie różnych technologii sterowników może ograniczyć ryzyko wspólnej awarii oprogramowania, ale stwarzać nowe problemy komunikacyjne i związane z konserwacją. Oddzielne zasilacze mogą przynieść niewielką korzyść, jeśli oba znajdują się w tej samej szafie narażonej na zalanie. Metody oceny niezawodności pomagają ustalić, które środki dywersyfikacji odpowiadają wiarygodnym mechanizmom awarii.

Założenia dotyczące przyczyn wspólnych powinny być jawne w każdym modelu ilościowym. Traktowanie kanałów redundantnych jako całkowicie niezależnych niemal zawsze prowadzi do optymistycznego wyniku. Doświadczenia z eksploatacji zakładu oraz ustalenia RCA dostarczają cennych danych do szacowania tych zależności.

Pokrycie diagnostyczne określa, jak długo system pozostaje podatny na awarie

Systemem redundantnym nie można skutecznie zarządzać, gdy awarie pozostają niewykryte. Pokrycie diagnostyczne opisuje odsetek istotnych usterek wykrywanych przez układy automatyczne lub kontrole ręczne. Wysokie pokrycie skraca czas pracy w stanie nieświadomej degradacji. Umożliwia także przywrócenie redundancji podczas konserwacji, zanim wystąpi kolejna awaria.

Twierdzenia dotyczące diagnostyki należy dokładnie analizować. Sterownik może wykrywać wewnętrzne usterki procesora, ale nie każdą awarię okablowania obiektowego. Moduł komunikacyjny może wykryć całkowitą utratę łącza, ale nie rozpoznać nieprawidłowego mapowania danych. Zasilacz może zgłosić alarm po całkowitej utracie wyjścia, ale nie ostrzec o stopniowej degradacji.

Testy sprawdzające obejmują uszkodzenia, których nie wykrywa ciągła diagnostyka. Odstęp między testami wpływa na czas narażenia. Dłuższe odstępy pozwalają, aby ukryte uszkodzenia pozostawały niewykryte przez dłuższy czas, natomiast bardzo krótkie odstępy zwiększają obciążenie utrzymania ruchu i ryzyko wywołane testami. Analiza FMEA, analiza Markowa i dane eksploatacyjne mogą pomóc w określeniu optymalnego odstępu.

Testy muszą obejmować pełne działanie funkcji. Aktywacja wejścia PLC nie dowodzi, że przełącznik obiektowy, okablowanie, logika, wyjście i element wykonawczy działają prawidłowo. Analiza niezawodności powinna dokładnie określać, które uszkodzenia może wykryć każda funkcja diagnostyczna lub test sprawdzający.

Czas naprawy często ma takie samo znaczenie jak wskaźnik uszkodzeń

Programy niezawodności często koncentrują się na zmniejszeniu częstotliwości uszkodzeń komponentów. Czas naprawy może być równie istotny w systemach odpornych na uszkodzenia. Po awarii pierwszego kanału system może nadal działać, ale pozostaje podatny na zagrożenia. Długie opóźnienia w naprawie zwiększają prawdopodobieństwo, że druga awaria spowoduje całkowitą utratę działania.

Diagnostyka, uzyskanie zgód, dostępność techników, części zamienne, przepustki dostępu i warunki produkcji wpływają na czas przywrócenia działania. Wymiana komponentu może zająć piętnaście minut po dostarczeniu właściwej części zamiennej do szafy. Rzeczywisty przestój może jednak trwać kilka dni, gdy część zamienna musi zostać sprowadzona z zagranicy.

Udoskonalona diagnostyka może skrócić czas lokalizacji usterki. Standaryzowane moduły i wstępnie skonfigurowane części zamienne mogą skrócić czas wymiany. Lokalne zapasy, jasne procedury eskalacji i zdalne wsparcie inżynierskie mogą ograniczyć opóźnienia logistyczne. Modele Markowa i Monte Carlo mogą określić ilościowo wartość tych usprawnień.

Najlepszą inwestycją w niezawodność nie zawsze jest zastosowanie mocniejszego sprzętu. W niektórych systemach skrócenie czasu naprawy zapewnia większe ograniczenie ryzyka niż niewielka poprawa wskaźnika uszkodzeń komponentów. Analiza powinna porównać obie opcje.

Zastosowanie analizy niezawodności do architektur DCS i PLC

Niezawodność systemu sterowania zależy nie tylko od procesora centralnego. Inżynierowie powinni przeanalizować sterowniki, moduły I/O, sieci komunikacyjne, zasilacze, serwery, stacje operatorskie, synchronizację czasu, interfejsy obiektowe i media pomocnicze. Każdy współdzielony element może stać się wspólną zależnością.

Redundantne sterowniki mogą współdzielić jeden stojak I/O. Redundantne serwery mogą zależeć od jednego przełącznika sieciowego lub jednego systemu pamięci masowej. Sieci zdalnych modułów I/O mogą korzystać z oddzielnych kanałów komunikacyjnych przebiegających tą samą trasą fizyczną. Kompletna analiza musi prześledzić działanie od urządzenia obiektowego do końcowego działania sterującego.

Wymagane zachowanie po awarii powinno być jasno określone. Proces może być kontynuowany przez pozostały sterownik, przekazany do obsługi ręcznej lub przejść w kontrolowane wyłączenie. Personel utrzymania ruchu musi wiedzieć, jak zidentyfikować uszkodzony kanał i przywrócić system bez zakłócania działania sprawnego kanału.

Organizacje planujące modernizację systemów sterowania mogą również zapoznać się z typowymi komponentami systemów sterowania DCS stosowanymi w architekturach automatyki procesowej. Dobór komponentów powinien zawsze wynikać z wymagań dotyczących niezawodności całej aplikacji, a nie z odosobnionych cech produktów.

Wiarygodne modele zależą od wiarygodnych danych utrzymania

Ilościowa analiza niezawodności jest tylko tak dobra, jak dane, na których się opiera. Rejestry utrzymania powinny rozróżniać uszkodzenie funkcjonalne, planową wymianę, inspekcję i modyfikację. Data uszkodzenia powinna oznaczać moment utraty funkcji, natomiast data przywrócenia powinna oznaczać moment, w którym działanie było ponownie rzeczywiście dostępne.

Tożsamość zasobów musi być spójna w systemie archiwizacji danych, systemie utrzymania, na rysunkach oraz w bazie części zamiennych. Kody uszkodzeń powinny opisywać mechanizmy, a nie nieprecyzyjne objawy. „Zatrzymanie” ma niewielką wartość analityczną, natomiast „zatarcie łożyska wskutek zanieczyszczenia środka smarnego” stanowi podstawę do przyszłego modelowania i zapobiegania.

Należy również uwzględniać ekspozycję eksploatacyjną. Pompy pracującej w trybie ciągłym nie można bezpośrednio porównywać z pompą rezerwową uruchamianą wyłącznie podczas testów. Temperatura, wilgotność, zanieczyszczenia, drgania, obciążenia elektryczne i obciążenie procesu mogą wyjaśniać różnice między pozostałymi identycznymi komponentami.

Czyszczenie danych należy traktować jako pracę inżynierską, a nie przygotowanie administracyjne. Nieprawidłowe klasyfikacje mogą zniekształcać wskaźniki uszkodzeń, rozkłady czasów napraw i wnioski z modeli. Analitycy powinni omówić nietypowe wyniki z personelem utrzymania i eksploatacji, zanim je zaakceptują.

Praktyczny proces poprawy niezawodności

Projekt dotyczący niezawodności powinien rozpocząć się od określenia wymaganej funkcji i granic systemu. Zespół musi określić, jakie parametry pracy są wymagane podczas normalnej eksploatacji oraz po każdym wiarygodnym uszkodzeniu. Należy zgromadzić rysunki, instrukcje, historię utrzymania, procedury operacyjne, rejestry alarmów i wcześniejsze raporty z incydentów.

FMEA może następnie identyfikować tryby uszkodzeń na poziomie komponentów oraz słabe mechanizmy wykrywania. FTA może analizować krytyczne zdarzenia szczytowe i współdzielone zależności. Modelowanie Markowa umożliwia ocenę stanów obniżonej sprawności i reakcji na naprawy, a symulacja Monte Carlo pozwala odwzorować niepewność dotyczącą uszkodzeń, utrzymania i logistyki.

Historyczne incydenty należy analizować za pomocą RCA. Wnioski powinny służyć do aktualizacji analiz projektowych i założeń ilościowych. Działania należy ustalać według priorytetów uwzględniających skutki, prawdopodobieństwo, wykrywalność, ekspozycję, czas naprawy i koszty.

Każde działanie musi mieć przypisaną osobę odpowiedzialną, termin realizacji oraz kontrolę skuteczności. Analizy należy aktualizować po większych zmianach wyposażenia, aktualizacjach oprogramowania, modyfikacjach procesu lub zmianach strategii utrzymania. Niezawodność to ciągła dziedzina inżynierii, a nie raport sporządzany raz i odkładany do archiwum.

Pytania ujawniające słabe twierdzenia dotyczące odporności na awarie

Rzetelna analiza sprawdza, jaka funkcja musi pozostać dostępna i jakie awarie system może tolerować. Sprawdza, czy redundantne kanały są niezależne fizycznie, elektrycznie i logicznie. Bada również, jak wykrywane są ukryte awarie i jak długo system może pozostawać w stanie obniżonej sprawności przed naprawą.

Zespół powinien zidentyfikować komponenty o długim czasie realizacji dostawy i ustalić, czy jeden błąd podczas prac utrzymaniowych może wpłynąć na kilka kanałów. Zależności programowe i konfiguracyjne powinny być traktowane z taką samą uwagą jak sprzęt. Operatorzy muszą rozumieć, jak system zachowuje się po awarii i jakie działania ręczne pozostają dostępne.

Założenia dotyczące awarii i napraw powinny być w miarę możliwości poparte danymi z zakładu. Po zakończeniu należy zweryfikować działania korygujące. Testy sprawdzające powinny wykazywać działanie całej funkcji ochronnej, a nie tylko reakcję odizolowanego urządzenia.

Te pytania są bardziej wartościowe niż ogólne stwierdzenie, że system jest redundantny. Łączą odporność na awarie z rzeczywistą architekturą, środowiskiem eksploatacji i możliwościami utrzymania ruchu.

Końcowe spostrzeżenia

Odporność na awarie jest niezbędna, gdy przestoje, niebezpieczne zachowanie lub utrata kontroli są niedopuszczalne. Sama redundancja nie tworzy jednak niezawodnego systemu. Inżynierowie muszą rozumieć tryby uszkodzeń, wspólne zależności, pokrycie diagnostyczne, działanie w stanie obniżonej sprawności, sposób naprawy i skutki eksploatacyjne.

Analiza drzewa błędów pokazuje, jak kombinacje awarii mogą doprowadzić do zdarzenia krytycznego. FMEA zapewnia systematyczny przegląd pojedynczych trybów uszkodzeń i ich skutków. Symulacja Monte Carlo służy do oceny niepewnych scenariuszy, natomiast RCA przekształca rzeczywiste awarie w wiedzę zapobiegawczą. Modelowanie Markowa wyjaśnia, jak systemy naprawialne przechodzą między stanami sprawności, obniżonej sprawności, awarii i przywrócenia działania.

Każda metoda ma ograniczenia, ale razem zapewniają solidne ramy niezawodności. Analizy projektowe należy aktualizować na podstawie danych eksploatacyjnych, a wnioski z incydentów powinny usprawniać przyszłe modele. Wyniki muszą wpływać na architekturę, utrzymanie ruchu, części zamienne, testowanie, szkolenia i procedury.

Celem nie jest stworzenie systemu, w którym nigdy nie występują awarie. Celem jest wczesne wykrywanie awarii, ograniczanie ich skutków, zachowanie wymaganej funkcji i przewidywalne przywracanie pełnej sprawności. To właśnie oznacza praktyczna odporność systemu przemysłowego na awarie.

O autorze

Marcus Ellwood | Reporter ds. niezawodności przemysłowej i systemów

Marcus Ellwood to profil redakcyjnego autora reprezentujący zespół PLCProTech ds. treści technicznych. Ten artykuł odzwierciedla łącznie 12 lat doświadczenia w analizie niezawodności, integracji systemów automatyki i inżynierii terenowej w środowiskach sterowania ABB, Rockwell Automation, Honeywell, HIMA i Siemens.

Zostaw komentarz

Pamiętaj, że komentarze muszą zostać zatwierdzone przed ich opublikowaniem.