Sterownik PLC fail-safe: odzysk, oznaczenie F i granice prac

Sterownik fail-safe, zwykle zapisywany jako F-CPU, prowadzi dwa programy naraz: normalny program sterujący i oddzielny program bezpieczeństwa, który runtime producenta utrzymuje w izolacji od niego. Wyciągasz CPU, czytasz rodzinę i numer, a wszystko wygląda standardowo. Potem maszyna odmawia przyjęcia programu bezpieczeństwa. To jest pułapka fail-safe.

Powiększony schemat systemu

×

Podział jest funkcjonalny, nie fizyczny: oba programy działają na tej samej jednostce, ale strona bezpieczeństwa jest odizolowana przez runtime.

Siemens dostarcza warianty fail-safe w rodzinach S7-1200F i S7-1500F, a oznaczenie F pojawia się w numerze zamówienia i na etykiecie obudowy. Sprzęt sam nie ogłasza tej różnicy, więc oznaczenie to pierwsza rzecz do sprawdzenia i pierwsza do zapisania. Jeden dodatkowy znak w numerze zamówienia rozdziela jednostkę, która przyjmie projekt bezpieczeństwa, od takiej, która nie może.

Dwa programy pozostają oddzielone z założenia. Program bezpieczeństwa działa według własnych zasad runtime, a program standardowy nie może go modyfikować. Ta izolacja jest powodem, dla którego standardowego CPU nie da się po prostu załadować projektem bezpieczeństwa, i dlatego status F kształtuje każde kolejne pytanie odzysku.

Oznaczenie F zauważysz bez otwierania czegokolwiek. W numerach zamówień Siemensa zdolność fail-safe widnieje w samej referencji, a etykieta obudowy też niesie oznaczenie. Pokazuje je też narzędzie inżynieryjne, gdy jednostka jest w sieci. Czego nie możesz zrobić, to wywnioskować tego z zachowania maszyny, bo standardowy CPU może prowadzić ten sam proces aż do momentu, gdy ktoś spróbuje załadować projekt bezpieczeństwa. Oznaczenie to nadrukowany fakt, więc potraktuj go jako fakt i odczytaj go.

Oznaczenie zmienia to, co dopasowana referencja musi zawierać. Dwa CPU o wspólnym numerze bazowym mogą się różnić tym, czy w ogóle przyjmą program bezpieczeństwa, a ta zdolność jest związana z konkretną jednostką i jej konfiguracją. Dlatego status F należy do pierwszego wiersza twojego zapisu, przed rewizją i zdjęciami.

Powiększony schemat systemu

×

Numer bazowy otwiera drzwi, ale zapis F decyduje, co może przez nie przejść. To sprawdzenie funkcjonalne, a nie okablowania.

Program bezpieczeństwa i jego konfiguracja F, czyli ustawienia wiążące funkcję bezpieczeństwa z jednostką, należą do tożsamości w drugim sensie. Jednostka o poprawnym numerze zamówienia może nadal odmówić prowadzenia projektu bezpieczeństwa, jeśli konfiguracja nie pasuje do tego, czego oczekuje projekt. Żadna wartość z tabliczki znamionowej nie dowodzi, że zamiennik przyjmie projekt. Te dowody trzeba zapisać, nigdy założyć. Lista modułów F chroni też weryfikację przed drugą pułapką: zamiennik CPU wygląda kompletnie na papierze, podczas gdy skonfigurowany zestaw wokół niego pozostaje niezapisany.

Podłączone moduły I/O fail-safe, czyli moduły F, należą do tego samego skonfigurowanego zestawu. F-CPU i jego moduły F konfiguruje się razem w projekcie, a zmiana dowolnego członka tego zestawu może wymagać ponownej walidacji programu bezpieczeństwa. Pytanie o dopasowanie nigdy więc nie kończy się na CPU; rozciąga się na każdy moduł F wokół niego. Rozróżnienie jest niewidoczne spoza szafy, dlatego nadrukowane oznaczenie niesie tak dużą wagę.

W zapytaniu praktyczną konsekwencją jest zakres. Powiedz, że CPU pracuje w aplikacji fail-safe, nawet gdy twoje pytanie dotyczy tylko CPU, bo osoba weryfikująca nie wie, czy moduły F wokół niego należą do pytania, dopóki tego nie powiesz. Weryfikacja, która dowiaduje się o modułach F w połowie oceny, musi otworzyć przyjęcie na nowo, a referencje modułów F, które wymieniłeś wcześniej, stają się powodem, dla którego nie musiała.

Utrwal pełny numer zamówienia z oznaczeniem F, wersję firmware taką, jak nadrukowano, i generację sprzętu. Sfotografuj tabliczkę znamionową i każde oznakowanie związane z bezpieczeństwem w szafie, w tym znaki albo dokumenty, które nazywają funkcję bezpieczeństwa pełnioną przez CPU. Zdjęcia niosą brzmienie dokładnie, a sparafrazowane etykiety bezpieczeństwa tracą znaczenie w zapisie. Dwa źródła etykiet dla tej samej jednostki to norma, a każde sfotografowane to o jeden szczegół mniej odtwarzany z pamięci.

Powiększony schemat systemu

×

Cztery grupy zapisu zasilają pakiet. Każda odpowiada na pytanie, które osoba weryfikująca musiałaby inaczej zadać dwa razy.

Wypisz podłączone moduły F z ich własnymi referencjami. Nazwij każdy moduł F, jego pozycję slotu lub stacji i pełny numer zamówienia, tak samo jak zapisałeś sam CPU. Pozycja modułów ma znaczenie, bo pytanie o ponowną walidację idzie za okablowaniem.

Jeśli istnieje kopia zapasowa projektu, zapisz wersję programu bezpieczeństwa i miejsce przechowywania kopii, obok wersji programu standardowego. Wersje mogą się różnić, a osoba weryfikująca potrzebuje obu, by ocenić, co przywrócona jednostka faktycznie prowadziłaby. Jeśli kopii nie ma, wpisz ten fakt do zapisu, bo zmienia każdą kolejną ścieżkę odzysku. Lokalizacja przechowywania znaczy tyle, co wersja; kopia, której nikt nie znajdzie, zachowuje się jak brakująca.

Oznakowanie bezpieczeństwa zasługuje na osobny, świadomy przebieg. Szukaj znaków ostrzegawczych przy drzwiach szafy, kieszeni na dokumentację i każdej tabliczki, która nazywa funkcję bezpieczeństwa pełnioną przez CPU, i sfotografuj, co znajdziesz. Te nośniki niosą brzmienie, z którym pracują osoby oceniające bezpieczeństwo, a parafraza w twoich notatkach nie odda go. Jeśli nic nie jest oznakowane, zapisz ten brak jako fakt, bo mówi osobie weryfikującej, jak duża część kontekstu bezpieczeństwa pozostaje bez dokumentacji.

Opatruj datą każdy wpis i trzymaj pakiet w faktach. Opinie o tym, co prawdopodobnie spowodowało usterkę albo co dostawca może mieć u siebie, nie należą obok zmierzonych faktów. Data to to, co zamienia twierdzenie w zapis, bo fakt bez daty nie da się ponownie sprawdzić z niczym.

Powiększony schemat systemu

×

Zaufanie bierze się z trzech pól na wiersz. Podane luki są częścią dowodów, a nie porażką zapisu.

Pakiet z datami i źródłami pozwala kolejnej osobie weryfikować każdy wiersz, zamiast wyprowadzać go na nowo. Każda wartość powinna nieść swoje źródło: tabliczkę znamionową, narzędzie inżynieryjne albo plik projektu. Gdy dwa źródła się różnią, zapisz oba odczyty, zamiast je uśredniać, i pozwól weryfikacji rozstrzygnąć konflikt.

Ta sama dyscyplina dotyczy luk. Nieznany stan firmware albo brakująca kopia zapasowa to fakt o zapisie, a podanie go wprost jest mocniejszym dowodem niż zgadywanie. Luki mówią też osobie weryfikującej, które kroki identyfikacji powtórzyć najpierw.

Gdy dwa źródła się różnią, zapisz oba odczyty z ich źródłami i datami i zostaw osąd weryfikacji. Wartość firmware z narzędzia inżynieryjnego i inna z listy części to normalne odkrycie w starzejącym się zakładzie, a ciche wybranie jednej zamienia twój zapis w twierdzenie. Dwa zapisane odczyty to dowody; jeden wybrany odczyt to opinia. Osoba weryfikująca rozstrzyga konflikt raz, ze źródłami przed sobą, zamiast odkrywać go dwa razy.

Sterownik fail-safe to nie tylko pytanie o wymianę jak za jak. Prace związane z bezpieczeństwem należą do wykwalifikowanego personelu według zasad obowiązujących dla maszyny, a żaden wpis w katalogu, karta katalogowa ani twierdzenie dostawcy tego nie zmienia. Pakiet dowodów jest wejściem do tych prac, a nie ich zastępcą.

Powiększony schemat systemu

×

Pakiet kończy się tam, gdzie zaczynają się kwalifikacje bezpieczeństwa. Strzałki pokazują przekazanie pytań, a nie przekazanie pracy.

Zapisz, co wiesz, i podaj, czego nie wiesz, a pytania o program bezpieczeństwa skieruj do osób odpowiedzialnych za maszynę. Zapis, który otwarcie wylicza swoje luki, jest dla osoby weryfikującej użyteczniejszy niż ten, który je zamazuje. Tam, gdzie istnieje luka, powiedz, kto normalnie by ją zamknął i jakiego narzędzia by potrzebował.

Traktuj kompatybilność i rezultaty jako otwarte pytania w zapytaniu. Czy konkretny zamiennik przyjmie istniejący projekt bezpieczeństwa i czy naprawa może zachować konfigurację F, to decyzje dla weryfikacji z odpowiedzialnymi osobami, wsparte twoimi dowodami. Niepewność jest tu normalna, a jej podanie utrzymuje odzysk bezpieczeństwa w uczciwości.

• Utrwal numer zamówienia z oznaczeniem F, wersję firmware i generację sprzętu.
• Wypisz każdy podłączony moduł I/O fail-safe z jego własną referencją i pozycją.
• Zapisz obie wersje programów albo podaj wprost, że kopia zapasowa nie istnieje.
• Prace przy programie bezpieczeństwa należą do wykwalifikowanego personelu. Odnotuj tę granicę w zapytaniu.

• strona kategorii sterowników PLC CPU
• przewodnik po polach tabliczki znamionowej
• pakiet dowodów dla zapytania o PLC