Zmiany oprogramowania maszyn i rejestry interwencji
Sytance · Zaktualizowano
Dowody dotyczące oprogramowania, konfiguracji i ingerencji mają znaczenie, gdy są niezbędne do bezpiecznego działania lub kluczowe dla zgodności z odpowiednimi zasadniczymi wymaganiami w zakresie ochrony zdrowia i bezpieczeństwa. Rozporządzenie traktuje również niektóre późniejsze zmiany cyfrowe jako istotne modyfikacje, jeśli spełniają definicję prawną.
Odniesienia do prEN 50742 w tym artykule dotyczą projektu ankietowego z grudnia 2025 r.: punktów 3.2 i 3.10, 7.3.1–7.3.5, 8.4–8.5 oraz 9. Są to postanowienia projektu przeznaczone do planowania technicznego, a nie wymagania opublikowanej normy europejskiej.
Oprogramowanie związane z bezpieczeństwem musi być identyfikowalne
zidentyfikować zainstalowane w niej oprogramowanie niezbędne do jej bezpiecznego działania
Rozporządzenie (UE) 2023/1230, załącznik III, sekcja 1.1.9 — oryginał angielski
Wymóg ten jest węższy niż kompletny wykaz oprogramowania. Dotyczy oprogramowania zainstalowanego w maszynie lub produkcie powiązanym, które jest niezbędne do bezpiecznego działania. Informacja ta musi być zawsze dostępna w łatwo dostępnej formie.
W praktyce zbiór związany z bezpieczeństwem może obejmować oprogramowanie aplikacyjne związane z bezpieczeństwem, oprogramowanie układowe, oprogramowanie sterownika robota, logikę sterownika PLC bezpieczeństwa, parametry bezpieczeństwa napędu, oprogramowanie interfejsu HMI wykorzystywane do instrukcji bezpieczeństwa oraz pliki konfiguracyjne określające limity bezpieczeństwa.
Dowody dotyczące ingerencji i konfiguracji
Sekcja 1.1.9 załącznika III wymaga dowodów legalnej lub nielegalnej ingerencji w odpowiedni sprzęt, oprogramowanie, zmian oprogramowania lub konfigurację. W projekcie prEN 50742 termin „ingerencja” oznacza działanie lub zdarzenie, które zmienia oprogramowanie albo dane i modyfikuje lub przerywa zachowanie, stan lub działanie maszyny.
Aktualizacje i modyfikacje
Aktualizacje oprogramowania, zmiany oprogramowania układowego, zmiany oprogramowania aplikacyjnego związanego z bezpieczeństwem oraz aktualizacje konfiguracji mogą stanowić ingerencję, gdy wpływają na oprogramowanie lub dane związane z bezpieczeństwem.
Dowody i dzienniki śledzenia
Dowody mogą mieć postać cyfrową lub fizyczną. Projekt prEN 50742 traktuje dzienniki śledzenia jako zapisy ingerencji wpływających na układ sterowania związany z bezpieczeństwem.
Czytelna identyfikacja
Zapis identyfikuje wersję oprogramowania i konfigurację w formie czytelnej dla człowieka, za pomocą wbudowanego wyświetlacza lub powszechnie dostępnego narzędzia zewnętrznego.
Chronione zapisy
Dowody muszą zachować wiarygodność wystarczającą do uzasadnienia wniosku dotyczącego bezpieczeństwa. Dziennik, który można po cichu zmienić, nie dowodzi historii ingerencji.
Zapisy układu sterowania
Podejście A z projektu z grudnia 2025 r., punkt 7.3.4, wymaga dowodów co najmniej ostatniej ingerencji każdego rodzaju, przechowywania danych śledzenia każdej ingerencji przez co najmniej pięć lat oraz włączenia dziennika śledzenia od momentu oddania do użytku. Podejście B, punkt 8.5, wymaga zachowania zapisów audytu funkcji bezpieczeństwa przez co najmniej pięć lat. Te projektowane zasady przechowywania należy odróżnić od podanej niżej reguły rozporządzenia, której okres biegnie od wgrania oprogramowania.
Sekcja 1.2.1 załącznika III ustanawia szczególną zasadę dotyczącą dzienników śledzenia dla układów sterowania. Dziennik danych dotyczących ingerencji oraz wgranych wersji oprogramowania bezpieczeństwa musi być włączony przez pięć lat od wgrania, wyłącznie w celu wykazania zgodności z załącznikiem III w odpowiedzi na uzasadniony wniosek właściwego organu krajowego.
W odniesieniu do maszyn o w pełni lub częściowo samorozwijającym się zachowaniu lub logice sekcja 1.2.1 załącznika III dotyczy także rejestrowania danych o procesie podejmowania decyzji związanych z bezpieczeństwem przez systemy bezpieczeństwa oparte na oprogramowaniu, które zapewniają funkcję bezpieczeństwa, w tym przez elementy bezpieczeństwa.
Istotna modyfikacja
Późniejsza zmiana oprogramowania lub konfiguracji nie stanowi automatycznie istotnej modyfikacji. Artykuł 3 definiuje istotną modyfikację jako fizyczną lub cyfrową zmianę wprowadzoną po wprowadzeniu maszyny lub produktu powiązanego do obrotu albo oddaniu go do użytku, której producent nie przewidział ani nie zaplanował, która wpływa na bezpieczeństwo przez stworzenie nowego zagrożenia lub zwiększenie istniejącego ryzyka i wymaga wymienionych środków ochronnych.
Przewidywane aktualizacje oprogramowania należy uwzględnić w pierwotnej ocenie ryzyka i dokumentacji technicznej, jeśli można je przewidzieć na etapie wprowadzenia do obrotu lub oddania do użytku.
Późniejsza zmiana cyfrowa może spełniać definicję istotnej modyfikacji, jeśli producent jej nie przewidział ani nie zaplanował i zmienia ona wniosek dotyczący bezpieczeństwa w sposób opisany w art. 3.
W motywie rozporządzenia stwierdzono, że operacji naprawy i konserwacji, które nie wpływają na zgodność z odpowiednimi zasadniczymi wymaganiami w zakresie ochrony zdrowia i bezpieczeństwa, nie należy traktować jako istotnych modyfikacji.
Informacje dotyczące użytkowania
Instrukcja obsługi musi obejmować użytkowanie zgodne z przeznaczeniem i dające się racjonalnie przewidzieć niewłaściwe użycie. W odniesieniu do oprogramowania i cyberbezpieczeństwa instrukcja powinna wyjaśniać informacje niezbędne do bezpiecznego użytkowania: identyfikację wersji i konfiguracji, dozwolone i zabronione modyfikacje, dostęp do dowodów ingerencji, założenia dotyczące kontekstu bezpieczeństwa oraz wszelkie środki kompensujące, których zastosowania oczekuje się od użytkownika.
- wskazać identyfikator oprogramowania i konfiguracji związanych z bezpieczeństwem;
- wyjaśnić, w jaki sposób użytkownik lub organ może uzyskać dostęp do identyfikatora lub dowodów;
- określić modyfikacje dozwolone, zabronione lub wykraczające poza przeznaczenie określone przez producenta;
- wskazać założenia dotyczące kontekstu bezpieczeństwa wpływające na bezpieczne użytkowanie, takie jak zaufane granice sieci;
- nie przedstawiać środka zaradczego po stronie użytkownika jako zamiennika wymaganego bezpiecznego projektu.