PL i SIL w robotyce

PL i SIL w robotyce: bezpieczeństwo, normy i dobór poziomu

11 minut czytania

PL i SIL w robotyce to dwa systemy oceny bezpieczeństwa funkcjonalnego, które określają, jak niezawodnie układ sterowania musi reagować w sytuacji zagrożenia. Oba pojęcia wywodzą się z różnych norm, lecz służą temu samemu celowi – ilościowemu opisaniu ryzyka, jakie dopuszczamy w danej funkcji bezpieczeństwa. Jeśli projektujesz lub wdrażasz stanowisko z robotem przemysłowym, wiesz, że te oznaczenia pojawiają się wszędzie – od dokumentacji sterownika po certyfikaty kurtyn świetlnych. Ten artykuł wyjaśnia mechanizmy stojące za PL i SIL, pokazuje, jak się je wyznacza i jak przełożyć je na konkretne decyzje projektowe w celi zrobotyzowanej.

  • PL (Performance Level) i SIL (Safety Integrity Level) to miary nienaruszalności funkcji bezpieczeństwa opisujące prawdopodobieństwo niebezpiecznej awarii na godzinę pracy układu.
  • PL wyznacza się według ISO 13849-1 na podstawie kategorii architektury, MTTFd, DCavg i CCF, natomiast SIL według IEC 62061 opiera się wyłącznie na ilościowym modelu PFHd.
  • W robotyce przemysłowej funkcje bezpieczeństwa związane z ruchem robota – takie jak SLS, SOS czy SS1 – wymagają typowo PL d lub SIL 2.
  • Nowe wydanie ISO 10218-2 odchodzi od reguły PL d dla wszystkiego i nakazuje przypisywać wymagany poziom bezpieczeństwa każdej funkcji osobno, na podstawie oceny ryzyka.
  • Walidacja systemu bezpieczeństwa celi zrobotyzowanej wymaga zarówno obliczeń PFHd, jak i testów funkcjonalnych oraz kompletnej dokumentacji w postaci Safety File.

Czym są PL i SIL w robotyce?

PL, czyli Performance Level, to miara zdolności elementów systemu sterowania związanych z bezpieczeństwem (SRP/CS) do wykonywania funkcji bezpieczeństwa w przewidywalnych warunkach. Definiuje go norma EN ISO 13849-1 i oznacza się go literami od a do e, gdzie PL a odpowiada najniższej, a PL e – najwyższej niezawodności. SIL, Safety Integrity Level, pochodzi z kolei z normy EN IEC 62061 (wywodzącej się z IEC 61508) i przyjmuje wartości od 1 do 3 w zastosowaniach maszynowych. Oba pojęcia opisują to samo zjawisko – prawdopodobieństwo niebezpiecznej awarii funkcji bezpieczeństwa na godzinę pracy układu, zwane PFHd (Probability of Dangerous Failure per Hour).

Wspólnym mianownikiem PL i SIL jest właśnie PFHd. Dzięki temu można je porównywać i przeliczać między sobą. Przedziały PFHd wyglądają następująco:

Przedziały PFHd dla poziomów SIL:

  • SIL 1 – od 10⁻⁶ do 10⁻⁵ niebezpiecznej awarii na godzinę.
  • SIL 2 – od 10⁻⁷ do 10⁻⁶ niebezpiecznej awarii na godzinę.
  • SIL 3 – od 10⁻⁸ do 10⁻⁷ niebezpiecznej awarii na godzinę.
  • SIL 4 – od 10⁻⁹ do 10⁻⁸ niebezpiecznej awarii na godzinę (stosowany poza maszynami, np. w przemyśle procesowym).

Dla systemu o poziomie SIL 3 dopuszczalne prawdopodobieństwo niebezpiecznej awarii nie przekracza 10⁻⁷ na godzinę, co odpowiada rzędu jednej awarii na kilkadziesiąt milionów godzin pracy funkcji bezpieczeństwa.

Mapowanie między PL a SIL na bazie PFHd wygląda następująco:

Performance Level (PL)Przedział PFHd [1/h]Odpowiadający SIL
PL a≥ 10⁻⁵ do < 10⁻⁴brak odpowiednika SIL
PL b≥ 3×10⁻⁶ do < 10⁻⁵SIL 1
PL c≥ 10⁻⁶ do < 3×10⁻⁶SIL 1
PL d≥ 10⁻⁷ do < 10⁻⁶SIL 2
PL e≥ 10⁻⁸ do < 10⁻⁷SIL 3

To mapowanie ma bezpośrednie przełożenie na projektowanie celi zrobotyzowanej. Jeśli podsystem napędowy robota jest certyfikowany przez producenta na SIL 2, a pozostałe elementy celi – osłony, blokady, kurtyny świetlne – są obliczone według ISO 13849-1 na PL d, oba podejścia można łączyć w jednym łańcuchu bezpieczeństwa, ponieważ opisują ten sam poziom redukcji ryzyka.

Wskazówka: Zanim sięgniesz po certyfikat producenta komponentu, sprawdź, czy podany poziom PL lub SIL dotyczy całej funkcji bezpieczeństwa, czy tylko jednego podsystemu – np. samego enkodera albo wyłącznie toru logicznego. Wartości podawane dla podsystemów nie są równoznaczne z poziomem osiągniętym dla całej funkcji.

Czym różni się PL od SIL i kiedy stosuje się każde z nich?

Różnica między PL a SIL nie sprowadza się wyłącznie do innej skali. PL to podejście hybrydowe – łączy jakościową kategorię architektury z ilościowymi parametrami MTTFd i DCavg. SIL jest czysto ilościowy: interesuje go wyłącznie PFHd wynikający z modelu blokowego całej funkcji, bez narzucania konkretnych architektur czy kategorii.

W ISO 13849-1 wynikowy PL uzyskuje się, przechodząc przez cztery parametry:

  • Kategoria architektury (B, 1, 2, 3, 4) – określa strukturę układu, np. czy jest jednokanałowy, dwukanałowy, czy posiada kanał diagnostyczny.
  • MTTFd – Mean Time To Dangerous Failure, czyli średni czas do niebezpiecznego uszkodzenia elementów w każdym kanale.
  • DCavg – średni poziom pokrycia diagnostycznego, wyrażony jako niski, średni lub wysoki.
  • CCF – odporność na awarie o wspólnej przyczynie, oceniana punktowo; wymóg to co najmniej 65 punktów dla architektury dwukanałowej.

Kombinacja tych czterech parametrów, zgodnie z Fig. 5 normy ISO 13849-1, daje wynikowy PL. To podejście jest naturalne przy projektowaniu klasycznych elementów celi – wyłączników krańcowych, blokad drzwi, kurtyn świetlnych, skanerów obszarowych czy przycisków awaryjnego zatrzymania.

Może Cię zainteresować:  Czy cobot potrzebuje wygrodzenia? Przepisy i ryzyko BHP

IEC 62061 wymaga natomiast pełnych danych o intensywnościach uszkodzeń (λ) dla każdego elementu, niezależności podsystemów, pokryciu diagnostycznym i wspólnych przyczynach uszkodzeń. Model blokowy funkcji bezpieczeństwa przekłada się bezpośrednio na PFHd całej funkcji, a poziom SIL wynika z tego, w jakim przedziale mieści się obliczony wynik.

Kiedy warto sięgnąć po które podejście:

  • ISO 13849-1 (PL) – gdy projektujesz klasyczne obwody bezpieczeństwa celi: osłony, blokady, przyciski zatrzymania awaryjnego, kurtyny i skanery. Podejście sprawdza się też przy integracji gotowych komponentów, dla których producent dostarcza wartości MTTFd i B10d.
  • IEC 62061 (SIL) – gdy analizujesz złożone, programowalne podsystemy: sterowniki bezpieczeństwa (safety PLC), napędy z funkcjami Safe Motion, sieci komunikacyjne takie jak Profisafe czy FSoE. Tu łatwiej włączyć komponenty certyfikowane zgodnie z IEC 61508, bo operują one bezpośrednio na λ i PFHd.

W jednej celi zrobotyzowanej możesz stosować oba podejścia równolegle, co jest powszechną praktyką. Ważne, żeby na styku podsystemów przeliczać PFHd i korzystać ze wspólnego kryterium ilościowego przy sumowaniu błędów całego łańcucha.

PL i SIL w robotyce

Jakie normy regulują PL i SIL w aplikacjach robotycznych?

Bezpieczeństwo funkcjonalne w robotyce reguluje kilka wzajemnie powiązanych norm. Ich zrozumienie jest warunkiem poprawnego projektowania układów bezpieczeństwa w celi zrobotyzowanej, dlatego warto znać rolę każdej z nich.

Dwie normy podstawowe, które definiują metodykę obliczania PL i SIL, to:

  • EN ISO 13849-1 – określa Performance Level i metodę jego wyznaczania dla SRP/CS. Zharmonizowana z dyrektywą maszynową i Rozporządzeniem Maszynowym UE.
  • EN IEC 62061 – pochodna IEC 61508, definiuje Safety Integrity Level dla złożonych, programowalnych systemów sterowania maszyn. Również zharmonizowana z Rozporządzeniem Maszynowym UE.

Normy specyficzne dla robotyki to:

  • ISO 10218-1 – wymagania bezpieczeństwa dla producentów robotów przemysłowych. Producent robota musi wykazać, że funkcje Safe Motion w kontrolerze spełniają określone poziomy PL lub SIL.
  • ISO 10218-2 – wymagania dla integratorów systemów i celi zrobotyzowanych. Integrator odpowiada za to, że cała cela – wraz z robotem, czujnikami, osłonami i logiką sterowania – spełnia wymagania wynikające z oceny ryzyka. Nowe wydanie tej normy wchłonęło wymagania ISO/TS 15066.
  • ISO/TS 15066 – specyfikacja techniczna dla robotów współpracujących. Definiuje cztery tryby kolaboracji człowiek–robot oraz zawiera tabelę biomechanicznych limitów sił i nacisków dla różnych części ciała (tabela A.2).

Do obliczeń pomocniczo stosuje się też ISO 13849-2, która precyzuje zasady walidacji, oraz ISO 12100 jako bazę dla ogólnej oceny ryzyka maszyn. Cały ten zestaw norm tworzy spójną strukturę, w której wymagany PLr lub SILr dla każdej funkcji bezpieczeństwa wynika wprost z oceny ryzyka celi, a obliczone PL lub SIL muszą być co najmniej równe wymaganemu poziomowi.

Warto podkreślić, że oba standardy – ISO 13849-1 i IEC 62061 – są zharmonizowane z europejskim Rozporządzeniem Maszynowym, co oznacza, że ich zastosowanie daje domniemanie zgodności z wymaganiami zasadniczymi dotyczącymi bezpieczeństwa. Szerzej o ramach prawnych i technicznym tle tej zgodności piszę w kontekście bezpieczeństwa funkcjonalnego w robotyce.

Jak wyznaczyć wymagany poziom bezpieczeństwa dla funkcji bezpieczeństwa robota?

Punkt wyjścia to zawsze ocena ryzyka – bez niej nie można racjonalnie wyznaczyć PLr ani SILr. Ocena ryzyka przeprowadzana zgodnie z ISO 12100 i ISO 10218-2 identyfikuje wszystkie scenariusze zagrożeń: zderzenie ramienia z operatorem, zgniecenie, wciągnięcie, kontakt z gorącą powierzchnią, uwolnienie energii potencjalnej przy zaniku zasilania i inne. Dla każdego zidentyfikowanego zagrożenia określa się, jaką funkcję bezpieczeństwa należy zaimplementować i jaki poziom niezawodności tej funkcji jest wymagany.

Szczegółowy opis procesu oceny ryzyka dla stanowisk zrobotyzowanych – wraz z metodami szacowania ciężkości i częstości zagrożeń – znajdziesz w artykule o analizie ryzyka robota przemysłowego.

W ISO 13849-1 wymagany PLr wyznacza się przez połączenie trzech parametrów:

  • S – ciężkość urazu – S1 (lekkie, odwracalne) lub S2 (poważne, nieodwracalne, w tym śmierć).
  • F – częstość i czas ekspozycji – F1 (rzadka lub krótka) lub F2 (częsta lub długa).
  • P – możliwość uniknięcia zagrożenia – P1 (możliwe do uniknięcia) lub P2 (niemożliwe lub trudne do uniknięcia).

Kombinacja S, F i P daje wymagany PLr z zakresu a–e. Dla dużego robota przemysłowego pracującego przy otwartej osłonie, z operatorem wchodzącym w strefę pracy (S2, F2, P2), wymagany PLr niemal zawsze wynosi d lub e.

To ma realne konsekwencje dla architektury. Dla PL d niezbędna jest architektura co najmniej Cat. 3 z dwoma redundantnymi kanałami, MTTFd na poziomie wysokim i DCavg co najmniej na poziomie średnim. Architektura jednokanałowa z samą diagnostyką (Cat. 2) pozwala osiągnąć PL d tylko przy bardzo wysokich wartościach MTTFd – rzędu 62 lat – i DCavg ≈ 90%, co w realiach celi zrobotyzowanej jest trudne do uzyskania bez zastosowania komponentów klasy przemysłowej z redundancją. Dlatego dla funkcji PL d dominują architektury Cat. 3 lub Cat. 4.

Wskazówka: Nie zakładaj z góry, że każda funkcja bezpieczeństwa w celi wymaga PL d. Nowe wydanie ISO 10218-2 nakazuje przypisywać PLr indywidualnie do każdej funkcji na podstawie oceny ryzyka. Funkcja kontroli zamknięcia drzwi serwisowych może wymagać PL c, podczas gdy funkcja monitorowania prędkości ramienia podczas wejścia operatora – PL d. Nadmiarowe wymagania prowadzą do niepotrzebnych kosztów i komplikacji projektowych.

Jak przebiega cały proces od oceny ryzyka do osiągniętego PL:

  1. Przeprowadź ocenę ryzyka zgodnie z ISO 12100 i ISO 10218-2 – zidentyfikuj zagrożenia i scenariusze zdarzeń.
  2. Dla każdego zagrożenia określ funkcję bezpieczeństwa, która je eliminuje lub redukuje.
  3. Wyznacz wymagany PLr (lub SILr) na podstawie parametrów S, F i P.
  4. Dobierz architekturę SRP/CS – kategorię, komponenty i ich MTTFd oraz zaplanowany DCavg.
  5. Oblicz PFHd i wynikowy PL dla zaprojektowanej architektury, np. w narzędziu SISTEMA.
  6. Sprawdź, czy osiągnięty PL ≥ PLr. Jeśli nie, zmień architekturę lub komponenty i powtórz obliczenia.
  7. Udokumentuj wyniki w Safety File i przeprowadź walidację funkcjonalną.
Może Cię zainteresować:  Przekaźnik bezpieczeństwa w aplikacji robotycznej: rola, dobór i podłączenie

Jeśli chcesz prześledzić ten proces krok po kroku dla typowej celi, artykuł o tym, jak przeprowadzić ocenę ryzyka dla robota, pokazuje go od strony praktycznej.

Podwójne zabezpieczenie robotów w zakładach przemysłowych

Jak PL i SIL wpływają na projektowanie układów bezpieczeństwa w celi zrobotyzowanej?

Wymagany PL lub SIL to nie tylko liczba do wpisania w dokumentację. Bezpośrednio kształtuje architekturę każdego elementu układu bezpieczeństwa – od czujników i kurtyn, przez logikę sterowania, po elementy wykonawcze.

Architektura bezpieczeństwa a wymagany PL

Układ bezpieczeństwa analizuje się jako łańcuch trzech bloków: wejście (czujniki, przyciski, skanery) → logika (safety PLC, moduł bezpieczeństwa) → wyjście (styczniki, zawory, układ odcięcia zasilania napędów). PFHd całej funkcji bezpieczeństwa to suma PFHd poszczególnych bloków – a to oznacza, że najsłabsze ogniwo decyduje o osiągniętym PL.

Dlatego przy projektowaniu warto rozpatrywać każdy blok osobno:

  • Blok wejściowy – kurtyny świetlne i skanery bezpieczeństwa są zazwyczaj certyfikowane przez producenta na PL d lub SIL 2. Ważne jest, żeby sprawdzić, czy certyfikat obejmuje cały układ detekcji, czy tylko sam czujnik bez interfejsu.
  • Blok logiczny – safety PLC lub moduły bezpieczeństwa certyfikowane na PL e lub SIL 3 dają duży zapas; ich PFHd dominuje rzadko. Problem pojawia się, gdy logika jest realizowana w programowalnym sterowniku ogólnego przeznaczenia bez certyfikowanego oprogramowania bezpieczeństwa.
  • Blok wyjściowy – redundantne styczniki z cross-monitoringiem, zawory pneumatyczne z potwierdzeniem stanu. Dla PL d wymagana jest architektura dwukanałowa z diagnostyką – jeden kanał to za mało.

Funkcje Safe Motion w kontrolerze robota

Nowoczesne kontrolery robotów przemysłowych implementują zestaw certyfikowanych funkcji Safe Motion, które same w sobie osiągają określony PL lub SIL. Typowy zestaw obejmuje:

  • STO (Safe Torque Off) – bezpieczne odcięcie momentu napędów bez mechanicznego hamowania.
  • SS1 / SS2 (Safe Stop 1/2) – sterowane hamowanie z monitoringiem i przejściem w STO lub SOS.
  • SOS (Safe Operating Stop) – monitorowany postój przy zachowaniu zasilania napędów.
  • SLS (Safe Limited Speed) – ograniczenie prędkości do bezpiecznej wartości z ciągłym monitorowaniem.
  • SLP (Safe Limited Position) – ograniczenie zakresu ruchu do zdefiniowanej strefy przestrzeni.
  • SZM (Safe Zone Monitoring) – monitorowanie pozycji robota w zdefiniowanych strefach.

Każda z tych funkcji jest realizowana sprzętowo i programowo w dwóch niezależnych kanałach wewnątrz kontrolera, z wzajemnym porównywaniem wyników i cyklicznymi testami diagnostycznymi. PFHd i osiągnięty PL lub SIL podaje producent w karcie certyfikacji – integrator może je bezpośrednio włączyć do obliczeń całej funkcji bezpieczeństwa celi.

W celi malarskiej z wielorobotowym układem SLS i SZM, realizowanym przez dwukanałowy safety PLC połączony z bezpiecznymi funkcjami sterowników robotów, uzyskanie PL d dla całej funkcji monitorowania strefy jest osiągalne bez nadmiernej komplikacji architektury. Dodatkową korzyścią jest skrócenie czasu restartu po zatrzymaniu awaryjnym – funkcje takie jak SOS i SS2 pozwalają na szybszy powrót do pracy w porównaniu z klasycznym E-stop przechodzącym w pełne odcięcie zasilania napędów.

Sumowanie PFHd w złożonych celi

Gdy w celi pracuje kilka robotów z logicznymi blokadami kolizji i sekwencjonowaniem ruchów, łańcuch bezpieczeństwa obejmuje wiele funkcji o własnych PFHd. Całkowity PFHd funkcji bezpieczeństwa to suma PFHd wszystkich bloków w jej łańcuchu, a w przypadku równoległych funkcji – osobne obliczenia dla każdej z nich. Błędem jest przyjmowanie jednego wspólnego PL dla całej celi zamiast indywidualnego dla każdej zidentyfikowanej funkcji bezpieczeństwa.

Dobór odpowiednich środków redukcji ryzyka – w tym architektur bezpieczeństwa i certyfikowanych komponentów – szczegółowo omawiam w artykule o środkach redukcji ryzyka w robotyce.

Jak PL i SIL wyglądają w bezpiecznym projektowaniu celi zrobotyzowanej?

Wymagania PL i SIL przenikają każdy etap projektowania stanowiska zrobotyzowanego – od rozmieszczenia elementów po dobór konkretnych komponentów. Ich właściwe uwzględnienie od samego początku pozwala unikać kosztownych przeróbek na etapie walidacji. O tym, jak całościowo podchodzić do tych kwestii, piszę szerzej w artykule o bezpiecznym projektowaniu celi zrobotyzowanej.

Praktyczne konsekwencje wymagań PL d dla projektu celi obejmują:

  • Podwójne enkodery lub enkoder z oddzielnym kanałem bezpieczeństwa – wymagane dla monitorowania pozycji i prędkości robota w funkcjach SLS i SLP certyfikowanych na PL d.
  • Cross-monitoring kanałów logicznych – safety PLC z dwoma niezależnymi rdzeniami obliczeniowymi porównującymi wyniki w każdym cyklu, z detekcją rozbieżności.
  • Redundantne wyjścia wykonawcze – dwa niezależne tory odcięcia zasilania napędów z potwierdzeniem stanu każdego z nich.
  • Cykliczne testy diagnostyczne – zarówno na poziomie hardware (testy wstrzykiwania błędów), jak i na poziomie logiki (testy porównawcze kanałów).
  • CCF ≥ 65 punktów – udokumentowane środki przeciwdziałające awariom o wspólnej przyczynie, takie jak separacja fizyczna kanałów, różnorodność technologiczna elementów, ochrona przed przepięciami.

Wskazówka: Przy doborze komponentów do celi korzystaj z bibliotek producenta dla narzędzia SISTEMA. Zawierają one gotowe bloki z wartościami MTTFd, B10d i PFHd zweryfikowanymi przez producenta, co eliminuje błędy ręcznego wprowadzania danych i przyspiesza obliczenia całego modelu PL.

Jak PL i SIL odnoszą się do bezpieczeństwa w robotyce współpracującej?

Robotyka współpracująca stawia przed systemami bezpieczeństwa wymagania, których nie można sprowadzić wyłącznie do osiągnięcia odpowiedniego PL lub SIL. ISO/TS 15066, której wymagania weszły do nowego wydania ISO 10218-2, definiuje cztery tryby pracy, w których człowiek i robot mogą współdzielić przestrzeń roboczą:

  • Safety-Rated Monitored Stop – robot zatrzymuje się i utrzymuje monitorowany postój, gdy człowiek wchodzi do strefy współpracy.
  • Hand Guiding – operator ręcznie prowadzi ramię robota przy aktywnym ograniczeniu sił i prędkości.
  • Speed and Separation Monitoring – robot redukuje prędkość proporcjonalnie do odległości od człowieka, mierzonej przez skanery lub kamery 3D.
  • Power and Force Limiting – robot ogranicza moment napędów i prędkość tak, aby przy kontakcie z człowiekiem siły i naciski nie przekraczały limitów biomechanicznych.
Może Cię zainteresować:  Skanery bezpieczeństwa do robotów: modele, dobór i ceny

Dla trybu Speed and Separation Monitoring wymagane są funkcje SLS i SZM certyfikowane na PL d lub SIL 2. Skanery bezpieczeństwa wyznaczają strefy odległości, a kontroler robota reaguje na zmniejszenie odległości przez stopniowe ograniczanie prędkości – aż do zatrzymania włącznie. Cały łańcuch musi osiągnąć wymagany PL d.

Tryb Power and Force Limiting jest pod tym względem szczególny. Wysoki PL funkcji ograniczającej moment napędów to warunek konieczny, ale niewystarczający. Norma ISO/TS 15066 w tabeli A.2 podaje graniczne wartości sił i nacisków dla każdej części ciała człowieka, wyróżniając kontakt quasi-statyczny (np. uwięzienie kończyny między robotem a nieruchomą przeszkodą) i przejściowy (krótkotrwałe uderzenie). Dla obszaru czaszki i czoła graniczna siła przy kontakcie przejściowym wynosi 65 N, a nacisk 110 N/cm² – to jedne z najostrzejszych limitów w całej tabeli.

Weryfikacja, czy zaprojektowany system spełnia te limity biomechaniczne, wymaga pomiarów siły z użyciem atestowanego urządzenia pomiarowego w rzeczywistych warunkach pracy robota – przy różnych trajektoriach, prędkościach i konfiguracjach narzędzia. Samo obliczenie PL nie wystarczy. Po każdej modyfikacji parametrów ruchu lub narzędzia wymagana jest ponowna walidacja, potwierdzająca, że zmierzone siły mieszczą się poniżej progów z tabeli A.2 ISO/TS 15066 przy zachowaniu zdefiniowanych funkcji bezpieczeństwa na wymaganym poziomie PL lub SIL.

Jak walidować i dokumentować zgodność systemu z wymaganym PL i SIL?

Walidacja funkcji bezpieczeństwa w robotyce to proces dwutorowy – obejmuje obliczenia i testy funkcjonalne. Żadna z tych ścieżek osobno nie jest wystarczająca.

Obliczenia prowadzone są najczęściej w oprogramowaniu SISTEMA, opracowanym przez IFA i bezpośrednio implementującym algorytmy ISO 13849-1. Narzędzie to pozwala na:

  • Modelowanie architektury SRP/CS jako blokowej struktury wejście–logika–wyjście.
  • Sumowanie MTTFd na poziomie kanałów (Parts-Count MTTFd).
  • Obliczenie DCavg dla całej funkcji bezpieczeństwa na podstawie zastosowanych środków diagnostycznych.
  • Automatyczne wyznaczenie PFHd i wynikowego PL z tabel normy.
  • Generowanie raportów dokumentujących założenia i wyniki obliczeń.

Testy funkcjonalne obejmują weryfikację, czy każda funkcja bezpieczeństwa rzeczywiście działa zgodnie ze specyfikacją – zarówno w normalnych warunkach, jak i przy symulowanych uszkodzeniach (np. przecięcie jednego kanału, wymuszenie rozbieżności między kanałami). Testy powinny obejmować wszystkie zdefiniowane funkcje: E-stop, blokady drzwi, kurtyny, skanery i funkcje Safe Motion kontrolera robota. Szczegółowe podejście do tego etapu opisuję w artykule o walidacji funkcji bezpieczeństwa robota.

Wyniki obliczeń i testów trafiają do Safety File – kompletnej dokumentacji bezpieczeństwa celi. Powinien on zawierać:

  • Wyniki oceny ryzyka z przypisanymi PLr lub SILr dla każdej funkcji bezpieczeństwa.
  • Modele obliczeniowe z SISTEMA z danymi komponentów, wynikami MTTFd, DCavg i PFHd.
  • Certyfikaty komponentów użytych w układach bezpieczeństwa.
  • Protokoły testów funkcjonalnych z opisem scenariuszy i wynikami.
  • Dokumentację środków CCF wraz z uzasadnieniem spełnienia wymogu 65 punktów.
  • Ewentualne protokoły pomiarów sił i nacisków dla trybów współpracy człowiek–robot.

Safety File to dokument żywy – powinien być aktualizowany przy każdej zmianie konfiguracji celi, wymianie komponentu na inny model lub modyfikacji parametrów ruchu robota. Zmiana narzędzia na cięższe, zwiększenie prędkości cyklu czy wymiana skanera bezpieczeństwa na inny model – każda z tych zmian może wpłynąć na osiągnięty PL i wymaga aktualizacji obliczeń oraz ponownych testów.

Podsumowanie

PL i SIL w robotyce to dwie metody opisu tego samego zjawiska – niezawodności funkcji bezpieczeństwa wyrażonej przez prawdopodobieństwo niebezpiecznej awarii na godzinę (PFHd). PL według ISO 13849-1 łączy kategorię architektury z parametrami MTTFd i DCavg, natomiast SIL według IEC 62061 opiera się wyłącznie na modelu ilościowym. Oba podejścia są równoważne i można je stosować równolegle w jednej celi. Typowym wymaganiem dla robotyki przemysłowej jest PL d lub SIL 2, choć nowe wydanie ISO 10218-2 nakazuje przypisywać wymagany poziom indywidualnie do każdej funkcji bezpieczeństwa. Walidacja wymaga obliczeń, testów funkcjonalnych i kompletnej dokumentacji w Safety File.

FAQ

Q: Czy robot współpracujący (cobot) automatycznie spełnia wymagania PL d bez dodatkowej analizy?

A: Nie. Certyfikat producenta cobota obejmuje sam robot, nie całą aplikację. Integrator musi przeprowadzić ocenę ryzyka dla konkretnego stanowiska i wykazać, że układ spełnia wymagany PLr dla każdej zidentyfikowanej funkcji bezpieczeństwa.

Q: Czy SISTEMA jest jedynym narzędziem do obliczania PL zgodnie z ISO 13849-1?

A: Nie. Producenci komponentów oferują własne narzędzia obliczeniowe, np. Safety Integrity Calculator (Pilz) czy SISTEMA-kompatybilne wtyczki. Warunek jest jeden – narzędzie musi implementować algorytmy zgodne z ISO 13849-1.

Q: Co się dzieje, jeśli jeden komponent w łańcuchu bezpieczeństwa nie osiąga wymaganego PL?

A: Cała funkcja bezpieczeństwa nie spełnia wymaganego PLr. Należy wymienić komponent na taki o wyższym MTTFd lub niższym PFHd albo zmienić architekturę – np. przejść z jednokanałowej na dwukanałową.

Q: Jak często trzeba powtarzać obliczenia PL dla istniejącej celi zrobotyzowanej?

A: Za każdym razem, gdy zmienia się konfiguracja celi – wymiana komponentu, modyfikacja oprogramowania sterującego, zmiana narzędzia, zwiększenie prędkości cyklu lub rozszerzenie strefy pracy robota.

Q: Czy poziom SIL 4 jest stosowany w robotyce przemysłowej?

A: Nie. SIL 4 dotyczy systemów o PFHd od 10⁻⁹ do 10⁻⁸ i stosowany jest w przemyśle procesowym oraz lotnictwie. W maszynach i robotyce przemysłowej górną granicą jest SIL 3, a większość funkcji bezpieczeństwa robotów zamyka się na poziomie SIL 2.

Weryfikacja i redakcja

Za redakcję i weryfikację artykułu odpowiadają:

Joanna Lewandowska

Joanna Lewandowska. Specjalistka ds. automatyki i integracji. Absolwentka kierunku Automatyka i Robotyka na Akademii Górniczo-Hutniczej im. Stanisława Staszica w Krakowie.

Piotr Woźniak

Piotr Woźniak. Doświadczony redaktor technologiczny. Absolwent kierunku Dziennikarstwo i Komunikacja Społeczna na Uniwersytecie Warszawskim.

Marek Zieliński

Od początku kariery zajmuje się uruchamianiem i usprawnianiem stanowisk zautomatyzowanych w środowisku produkcyjnym. Pracował przy wdrożeniach obejmujących integrację robotów, konfigurację logiki pracy oraz optymalizację przepływu procesu po uruchomieniu stanowiska. Najlepiej odnajduje się tam, gdzie potrzebne jest połączenie wiedzy technicznej z praktycznym zrozumieniem realiów hali produkcyjnej.

Opublikuj komentarz