Artykuł z serii: Układy bezpieczeństwa
Często projektując układy sterowania wkraczamy w dziedzinę dosyć specyficzną w swej istocie, a mianowicie – bezpieczeństwo. Temat przez wielu znany, przez wielu niedoceniany, wreszcie – przez wielu źle rozumiany. Nie chodzi o to, że nikt nie rozumie czym jest bezpieczeństwo. Każdy projektując coś, jest odpowiedzialny (a przynajmniej powinien tak się czuć) za to, aby oddać klientowi sprawne, realizujące swoją funkcję urządzenie, ale jednocześnie bezpieczne – zabezpieczone przed możliwymi usterkami układu sterowania oraz błędami obsługi na odpowiednio wysokim poziomie, adekwatnym do poziomu zagrożeń jakie czyhać będą w czasie eksploatacji.
Ocena poziomu bezpieczeństwa
Często jednak nie jesteśmy pewni czy zastosowane przez nas zabezpieczenie sprawdzi się w praktyce oraz czy jest zgodne z zasadami sztuki. Czy da się to jednak miarodajnie ocenić? Czy są jakieś metody pozwalające sprawdzić stopień ochrony, który zaproponowaliśmy w swoim układzie i czy ten poziom jest adekwatny do niebezpieczeństwa? Z grubsza odpowiedź brzmi – tak, jest to możliwe. Dzisiejsze normy bezpieczeństwa pozwalają ocenić ów poziom bezpieczeństwa nie tylko w sposób jakościowy (odpowiednie połączenie urządzeń np. redundancja), ale również ilościowy (zastosowanie odpowiednich urządzeń o odpowiednich parametrach). Nie znaczy to, że wystarczy wziąć pierwsze z brzegu urządzenie charakteryzujące się super parametrami – trzeba je również dopasować choćby ze względu na warunki środowiskowe w jakim to urządzenie ma pracować. Dodatkowo powinno się brać pod uwagę ograniczenia funkcjonalne tychże urządzeń, które mogą objawiać się tylko w ściśle określonych momentach. Cała ta gama różnorodności sprawia, że tematyka safety nie jest tematyką łatwą. I chociaż każdy większy producent układów safety oferuje różnorodne poradniki w których znaleźć możemy sprawdzone układy bezpieczeństwa, to nie wnikając nieco głębiej w istotę sprawy możemy poruszać się w tym temacie nieco po omacku – szczególnie jeśli schemat musimy lekko dopasować pod swoją funkcję bezpieczeństwa. Skąd możemy mieć pewność, że pozornie mała zmiana nie wniesie istotnego czynnika w funkcję bezpieczeństwa? Bez dogłębnego zrozumienia, możemy się jedynie domyślać.,
Seria artykułów o bezpieczeństwie?
Tym artykułem chciałbym rozpocząć krótszą (lub dłuższą – wszystko zależy od Waszego odbioru) serię artykułów dotyczącą projektowania układów bezpieczeństwa zgodnie z zasadami sztuki. Nie chciałbym być jednak brany za alfę i omegę w tym temacie – nie zamierzam odkrywać tutaj jakichś własnych, niesamowitych układów bezpieczeństwa. Sam kilka lat temu, będąc totalnie początkującym w tym temacie, rozpocząłem poszukiwania rzetelnych informacji na ten temat. I udało się je znaleźć – prawdopodobnie w poradnikach instytucji, która ma największy wpływ na treść norm związanych z bezpieczeństwem maszynowym, a mianowicie IFA (taka nazwa jest obecna – wcześniej była znana jako BIA, BGIA itd.). O IFA możecie poczytać np. tutaj:
Obeznani w temacie czytelnicy prawdopodobnie znają poradniki opublikowane przez ów Instytut. I z pewnością można stwierdzić, że bardzo obszernie przedstawiają one problem bezpieczeństwa zgodnie z obowiązującymi, powszechnie stosowanymi normami bezpieczeństwa m.in. PN-EN 13 849-1. Instytut ten stale rozwija również powszechnie dostępne oprogramowanie o nazwie SISTEMA, które ułatwia projektowanie funkcji bezpieczeństwa bez wchodzenia w zawiłe wzory matematyczne powiązane z parametrami urządzeń bezpieczeństwa. Program można darmowo pobrać po uprzedniej rejestracji ze strony:
I właśnie bazując na takiej solidnej podstawie – ciekawych przykładach przytoczonych przez IFA w swoich poradnikach oraz wykorzystaniu programu SISTEMA – chciałbym chociaż częściowo pokazać Wam, że prawidłowe, jasne co do spełnianych funkcji bezpieczeństwa, projektowanie układów safety jest możliwe (chociaż często nie łatwe – szczególnie na początku naszej nauki).
Chciałbym zwrócić uwagę, że cykl poradników nie ma za zadanie omawiać szczegółowo Dyrektywy Maszynowej, obowiązujących rozporządzeń krajowych, metod analizy ryzyka itd. Mimo to podstawowa wiedza z tego zakresu jest co najmniej pożądana, dlatego w linkach poniżej przytaczam najważniejsze materiały, obowiązkowe co do znajomości dla każdego kto chce prawidłowo zajmować się tematyką safety. Nie trzeba uczyć się na pamięć wszystkich szczegółów – one i tak same wejdą do głowy po którymś tam zastosowaniu ich w praktyce 😉
Cykl artykułów będzie służył jako pomoc w objaśnieniu (dla tych, którzy mają problemy ze zrozumieniem) procedury technicznej doboru prawidłowych środków ochronnych dla konkretnych funkcji bezpieczeństwa. Wyraźnie zaznaczam, że jest to jedynie jeden z kilkunastu etapów prawidłowego projektowania bezpiecznych maszyn, lecz nie jedyny. Dla projektantów układów sterowania jest on jednak niezbędny, nie trzeba chyba nikogo uświadamiać, że na nas (projektantach, ale i również np. UR) również ciąży pewna odpowiedzialność za bezpieczne funkcjonowanie całej maszyny.
Tyle tytułem wstępu. Zachęcam do zapoznania się z poniższymi poradnikami (przynajmniej pobieżnie) dla tych, którzy zupełnie nie są w temacie. Na bazie pewnych informacji z nich tłumaczone będą bowiem pewne czynności projektowe, a w ramach stosunkowo krótkich artykułów nie można pisać o wszystkim, gdyż łatwo będzie się w tym wszystkim pogubić i nic nie wyjdzie z naszej nauki. Postaram się również przypominać (prezentować) pewne kluczowe informacje istotne dla konkretnego przykładu, tak, aby w jakimś stopniu systematyzować poznawaną wiedzę.
Zatem odsyłam do kilku wartościowych publikacji i stron przed dalszą lekturą:
Od czego zacząć, wdrażając się w układy bezpieczeństwa?
Jeżeli zapoznałeś się z powyższymi materiałami i nie czujesz się już całkiem obco, zapraszam do ułożenia być może swojej pierwszej funkcji bezpieczeństwa (SF – Safety Function, tym skrótem będziemy się posługiwać w dalszych analizach).
Jako pierwsza i najprostsza funkcja bezpieczeństwa, na podstawie której zaznajomimy się również z oprogramowaniem SISTEMA, niech będzie funkcja STO (Safe Torque OFF – Bezpieczne odłączenie momentu) dla klasycznego układu stycznikowego sterującego pracą silnika elektrycznego.
Na początek uściślijmy czym charakteryzuje się funkcja STO. Oto wykres (pochodzący z dokumentu IFA Report 7/2013e – link powyżej) wraz z objaśnieniem :
Jak widać normalnie, aby napęd działał element/podsystem STO musi być aktywny (może to być stycznik napędu, odblokowanie impulsów w przemienniku częstotliwości itd.). Ściągnięcie tego sygnału powoduje niekontrolowany stop napędu, bez żadnych ramp hamowania (wolny wybieg). Oczywiście nie w każdej aplikacji jest to stosowny rodzaj stopu.
Bez żadnych powiązań z producentem ani jakimkolwiek dystrybutorem posłużę się na przykładzie elementów firmy EATON w jaki sposób można szybko stworzyć (bez nadmiernego wchodzenia w szczegóły) i ocenić taką funkcję bezpieczeństwa.
Schemat pochodzi tym razem z publikacji BGIA Report 2/2008, do której link również macie powyżej:
Projektowanie funkcji bezpieczeństwa
Zakładam, że mamy już zainstalowane oprogramowanie SISTEMA w najnowszej dostępnej wersji. Kolejnym krokiem, który ułatwi nam mocno robotę, będzie ściągnięcie bibliotek elementów, które mają już w sobie przypisane wartości parametrów związanych z bezpieczeństwem (w tym przypadku chodzi nam głównie o MTTFd oraz B10d – znaczenie tych parametrów znajduje się w wyżej wspomnianych publikacjach). Na hasło „EATON SISTEMA LIBRARY” w Google, zgłasza się taki link:
Po wejściu w niego widzimy możliwość do ściągnięcia bibliotek do stosownej wersji naszej SISTEM’y:
Jako, że najnowsza dostępna wersja (i do takiej odnosi się artykuł) to wersja 2.x, ściągamy i zapisujemy w dowolnym miejscu na dysku biblioteki dla każdego z podsystemów – wejścia, logika, wyjścia. Po ściągnięciu rozpakujmy te biblioteki do dowolnego folderu.
Kolejnym krokiem jest uruchomienie programu SISTEMA. Przy pierwszym uruchomieniu zgłasza się ekran startowy w którym możemy skonfigurować sobie foldery, język itd. Jedyne co zmieniałem to język na English, pozostałe ustawienia pozostały bez zmian. Ustawienia te zawsze można jeszcze zmienić w menu Edit/Sistema Configurator.
Po uruchomieniu tworzymy nowy projekt, w którym zawarte będą poszczególne funkcje bezpieczeństwa (w naszym przypadku jedna – STO). Klikając w pasku narzędzi New… tworzymy właśnie nowy projekt, który możemy nazwać, skomentować, dodać stosowne dokumenty jeśli jakieś są. Widzimy również zakładkę Safety functions, w której będziemy deklarować naszą funkcję bezpieczeństwa.
Wchodzimy w tą zakładkę, wybieramy New… i dwukrotnie klikamy naszą utworzoną SF (Safety Function).
W nowo otwartym oknie deklarujemy nazwę tej funkcji, możemy ją dokładnie skomentować jak ma działać, dodać kolejne dokumenty związane z tą funkcją (np. fragment schematu). Ja nazwałem tą funkcję krótko – STO.
Kolejny etap (i kolejna zakładka) to określenie wymaganego poziomu bezpieczeństwa (PLr – required). Możemy określić ten stopień bezpośrednio w programie posługując się grafem lub mając obliczony już wcześniej – po prostu go wpisać.
Załóżmy, że znamy już pożądany PL i wynosi on PLc…
W zakładce Subsystems definiujemy podsystemy wchodzące w skład naszej SF. Klikamy w tej zakładce New…, definiujemy nazwę oraz kilka istotnych rzeczy.
W zakładce PL:
konieczne jest „zaptaszkowanie” wszystkich opcji (pozostawiamy domyślne determinowanie poziomu PL/PHFd na podstawie Kategorii, MTTFD oraz DCavg (ten ostatni w sumie nas tu nie będzie obchodził). Co oznaczają te pola do „zaptaszkowania”? Już sama treść coś nam podpowiada – że zastosowane oprogramowanie spełnia warunki safety (lub nie ma wogóle oprogramowania), podsystem jest odporny na błędy systematyczne itd. Odpowiedzi na te pytania można znaleźć we wspomnianej publikacji BGIA Report 2/2008, być może w kolejnych artykułach będzie konieczne ten temat bardziej rozwinąć.
Na kolejnej zakładce Category określamy Kategorię w jakiej będzie pracował nasz podsystem. Do naszej prostej SF (patrząc na możliwe warianty do wyboru) pasuje kategoria B lub 1. Im wyższa Kategoria, tym nasza SF jest bardziej bezpieczna. Główna różnica między tymi kategoriami to zastosowanie sprawdzonych elementów bezpieczeństwa oraz zasad bezpieczeństwa. W naszym przypadku przycisk E-stop oraz stycznik to sprawdzone elementy bezpieczeństwa, możemy więc spokojnie wybrać Kategorię 1. Sprawdzone zasady bezpieczeństwa to np. przewymiarowanie styczników, uziemianie jednego bieguna obwodu sterowniczego, zastosowanie elementów zabezpieczeń (bezpieczników) w obwodzie sterowania, zasada „closed-circuit current” tzn. w przypadku zaniku napięcia układ przejdzie w stan bezpieczny (w naszym przypadku zatrzymany zostanie niebezpieczny ruch silnika). Więcej szczegółowych informacji w literaturze podanej powyżej.
Po wybraniu stosowanej kategorii „ptaszkujemy” opcje pojawiające się w oknie.
W zakładce MTTFd możemy określić tzw. Mission Time dla którego projektowany jest cały układ (standardowo ten czas wynosi 20 lat – 20 a).
Wreszcie ostatnia zakładka to Blocks, w której będziemy już dodawać poszczególne bloki.
Standardowo wybieramy w niej opcję New..., nadajemy nazwę nowemu blokowi np. E-stop, możemy np. dodać kartę katalogową dotyczącą urządzenia. Na zakładce MTTFd z kolei możemy określić wspomniany parametr przy zastosowaniu różnych opcji. My celowo skorzystamy ze ściągniętych bibliotek dla EATON, dlatego wybierzemy opcję:
i pojawi nam się nowa zakładka Elements.
W tej zakładce tym razem wybierzemy zamiast New.. opcję Library. W nowym oknie musimy dodać biblioteki, które wcześniej rozpakowaliśmy (opcja Add Local Library), a następnie przechodzimy na listę elementów:
w bibliotece dotyczącej urządzeń wejściowych.
Na liście odnajdujemy nasz e-stop (M-22 e-stop PVT Types) i klikamy Load & Close. Usuwamy nieznany element, który automatycznie tworzy się przy dodaniu nowego bloku, tak, aby został tylko nasz e-stop. Teraz klikając dwukrotnie w nasz e-stop możemy go nieco skonfigurować. W zasadzie jedyną informacją jaką musimy określić (zakładamy obliczenie MTTFd na podstawie B10d) jest liczba operacji wykonanych w ciągu roku. Możemy ją albo ręcznie wpisać albo wykorzystać Calculate nop i określić stosowne parametry. My określimy jednokrotne użycie przycisku e-stop w ciągu każdego dnia w roku, czyli wpisujemy 360 i potwierdzamy ENTER’em. Obliczony zostanie na tej podstawie parametr MTTFd oraz T10d.
Jeśli wszystko do tej pory jest OK, z lewej strony w oknie projektu powinniśmy mieć podobny widok:
Najbardziej istotne są te zielone „ptaszki”, które oznaczają, że potrzebne warunki (dla określonych założeń) do tej pory zostały spełnione.
Z elementów bezpieczeństwa naszej funkcji pozostał nam jeszcze do dodania stycznik. Klikamy więc w oknie projektu w pole SB (u mnie dodatkowo oznaczone jako Test) i analogicznie jak dodawaliśmy e-stop, dodajemy teraz nasz stycznik jako osobny blok (element DILM 12 w bibliotece dotyczącej wyjść). Zakładamy np. załączenie stycznika dwa razy w ciągu dnia przez 365 dni co daje nam 730 operacji w ciągu roku.
Ekran projektu powinien przypominać coś takiego:
I w zasadzie to już koniec projektowania naszej funkcji bezpieczeństwa. Można samemu się przekonać, że przekraczając np. ilość cykli użycia stycznika powyżej pewnej wartości pojawi się alarm przekroczenia wartości parametru T10d i nasza SF nie będzie już prawidłowa.
Możemy teraz wrócić dla pewności na naszą funkcję SF (u mnie STO) i w zakładce PL przekonać się, że faktycznie nasza cała SF ma poziom PLc.
Sprawdźmy jeszcze czy stosując kategorię B zamiast 1 uda nam się utrzymać ten poziom PL. W zakładce podsystemu SB (u mnie Test) w zakładce Category wybieramy B zamiast 1. Widzimy, że SF nam się „wysypała” – nie jest możliwe uzyskanie poziomu PLc z kategorią B.
Zaglądając do publikacji BGIA widzimy, że faktycznie tak jest (dla kategorii B maksymalny poziom jaki możemy uzyskać to PLb). Główna różnica to możliwość stosowania w kategorii B elementów niesprawdzonych pod kątem bezpieczeństwa, struktura SF jest podobna jak w kategorii 1.
I to tyle jeśli chodzi o wstęp do projektowania funkcji bezpieczeństwa w programie SISTEMA. Zdaję sobie sprawę, że dużo informacji nie zostało w pełni wyjaśnionych, tym niemniej wierzę, że bogata jakościowo literatura pozwoli rozwiać dużo wątpliwości w tym zakresie. W kolejnych artykułach z tego cyklu chciałbym już skupić się na omówieniu ciekawszych SF z dziedziny sterowania napędów elektrycznych (rozwinięcie przykładów podanych w IFA Report), wykorzystanie do tego SISTEMA znacznie ułatwi obliczenie potrzebnych parametrów.
Załączam jeszcze przykładowy projekt SF, który był omawiany w tej publikacji: SISTEMA projekt SF iautomatyka.zip
Życzę samych sukcesów w układaniu własnych SF 😉
Do zobaczenia wkrótce!
Łukasz Bednarz
Artykuł zdobył nagrodę w konkursie iAutomatyka
Ilość : 1 sztuka |
Nagrodę dostarcza ASTOR – od sterownika PLC do systemu zarządzania produkcją. Od skutecznej porady technicznej do szerzenia idei Przemysłu 4.0. Od studenta do inżyniera i menedżera produkcji. I tak już od 30 lat wspieramy przyszłych i obecnych automatykom i robotykom w codziennej pracy Poznaj firmę ASTOR
🎁 Zwycięzca: Łukasz Bednarz Praca konkursowa: BEZPIECZEŃSTWO W UKŁADACH STEROWANIA – PROJEKTOWANIE |
