ProblemUpdate oprogramowania jako "zwykłe" zadanie serwisowe
W wielu zakładach aktualizacja oprogramowania sterownika PLC czy panelu HMI maszyny traktowana jest identycznie jak aktualizacja systemu operacyjnego w biurowym komputerze — rutynowa czynność, którą wykonuje dział IT lub zewnętrzny integrator automatyki, bez angażowania osób odpowiedzialnych za bezpieczeństwo maszynowe czy dokumentację techniczną.
Problem w tym, że oprogramowanie sterujące maszyną często odpowiada bezpośrednio za funkcje bezpieczeństwa — strefy ochronne, prędkości bezpieczne, sekwencje zatrzymania awaryjnego. Zmiana w tym kodzie nie jest równoważna aktualizacji aplikacji biurowej, nawet jeśli z zewnątrz wygląda identycznie — jako wgranie nowego pliku na sterownik.
RyzykoCo się dzieje, gdy zmiana w kodzie zostanie potraktowana jak zwykły update
Jeśli aktualizacja oprogramowania zmienia sposób działania funkcji bezpieczeństwa, a nikt nie oceni tego pod kątem przepisów o maszynach, konsekwencje mogą być poważne:
Utrata ważności oceny ryzyka
Pierwotna ocena ryzyka i deklaracja zgodności maszyny odnosiły się do konkretnej wersji oprogramowania — jeśli zmieniło się zachowanie funkcji bezpieczeństwa, ta ocena może już nie być aktualna.
Rozmyta odpowiedzialność
Firma automatyki wykonująca update, dział IT klienta i pierwotny producent maszyny — każdy może uważać, że odpowiedzialność leży po stronie kogoś innego, co utrudnia ustalenie winnego po wypadku.
W praktyce oznacza to, że w razie wypadku związanego z nieprawidłowym działaniem funkcji bezpieczeństwa po aktualizacji, odpowiedzialność może spaść na podmiot, który tę aktualizację wykonał — niezależnie od tego, czy uważał się za "tylko wykonawcę usługi IT".
RozwiązanieKiedy update oprogramowania to istotna modyfikacja
Kluczowe pytanie brzmi: czy zmiana w oprogramowaniu wpływa na funkcje bezpieczeństwa maszyny lub na sposób, w jaki maszyna wykonuje swoje zadanie w sposób istotny dla ryzyka? Poniższe zestawienie pomaga rozróżnić typowe przypadki:
Zwykle JEST istotną modyfikacją
Zmiana logiki stref ochronnych, prędkości bezpiecznych, sekwencji zatrzymania awaryjnego, dodanie nowych trybów pracy lub integracja z systemem sterującym ruchem (np. modułem AI).
Zwykle NIE JEST istotną modyfikacją
Aktualizacja interfejsu użytkownika niezwiązana z bezpieczeństwem, poprawki błędów w raportowaniu danych produkcyjnych, aktualizacje niezmieniające parametrów pracy ani funkcji ochronnych.
Żeby uniknąć niekontrolowanego ryzyka, warto wprowadzić prostą procedurę oceny każdej planowanej aktualizacji przed jej wdrożeniem:
- 1
Klasyfikacja zmiany — sprawdzenie, czy aktualizacja dotyczy funkcji bezpieczeństwa, czy wyłącznie elementów niezwiązanych z ryzykiem.
- 2
Ocena wpływu na ryzyko — jeśli zmiana dotyczy funkcji bezpieczeństwa, przeprowadzenie ponownej analizy ryzyka dla zmodyfikowanego zakresu.
- 3
Aktualizacja dokumentacji technicznej — odzwierciedlenie zmiany w dokumentacji i, jeśli to konieczne, w deklaracji zgodności.
- 4
Rejestr wersji oprogramowania — prowadzenie ewidencji, kto, kiedy i jaką zmianę wprowadził, wraz z uzasadnieniem klasyfikacji.
Pytanie kontrolne: czy w Twojej firmie istnieje procedura klasyfikująca aktualizacje oprogramowania sterującego pod kątem wpływu na funkcje bezpieczeństwa, zanim update trafi na produkcyjną maszynę?
Szkolenie
W szkoleniu online "Maszyny 2027" pokazujemy, jak ocenić, czy planowana zmiana w oprogramowaniu sterującym maszyną wymaga nowej oceny ryzyka, i jak zbudować prostą procedurę zarządzania takimi zmianami.
Zobacz program szkolenia →