Oprogramowanie związane z bezpieczeństwem wg ISO 13849-1

Do tego momentu zostały omówione tradycyjne architektury części sterowania odpowiedzialnej za bezpieczeństwo. Od momentu harmonizacji normy PN-EN ISO 13849-1 maszyny mogą być wyposażone w programowalne systemy bezpieczeństwa, które zawierają oprogramowanie związane z bezpieczeństwem.

Oprogramowanie wolne od błędów nie istnieje w prawdziwym świecie. W przeciwieństwie do błędów sprzętowych, które występują w wyniku losowej awarii komponentu, przyczyny błędów oprogramowania są systematyczne. Dlatego szczególnie ważne jest podjęcie wszelkich uzasadnionych kroków w celu uniknięcia błędów podczas opracowywania oprogramowania związanego z bezpieczeństwem, którego celem jest przecież minimalizacja ryzyka. To, co uważa się za uzasadnione, zależy z jednej strony od wymaganego poziomu PL_r. Jednocześnie uszkodzenia krytyczne dla bezpieczeństwa mają tendencję do wkradania się na poszczególne etapy tworzenia oprogramowania, gdzie pozostają niewykryte, dopóki nie spowodują awarii działania. Wymagania normy PN-EN ISO 13849-1 mają zatem na celu w szczególności unikanie błędów w tych fazach. Niestety, w praktyce często zwraca się niewielką uwagę na te etapy podczas konfigurowania oprogramowania związanego z bezpieczeństwem.

W tej dyskusji na temat oprogramowania związanego z bezpieczeństwem trzeba wyjaśnić, że mowa będzie o oprogramowaniu, które zostało zaprojektowane w celu zmniejszenia ryzyka. Niektóre popularne systemy, takie jak Windows, MacOS i Linux nie są przystosowane do realizacji funkcji bezpieczeństwa i nie będą tu rozważane. Ogólnie rzecz biorąc, takie systemy operacyjne są zbyt złożone, mają sporo błędów systematycznych i są podatne nieoczekiwanym zmianom. Z tego powodu nie będą one nadawały się do aplikacji wymagającej wysokiej niezawodności. Z drugiej jednak strony, nie ma żadnych przeciwskazań w używaniu takich systemów do funkcji diagnostycznych (np. monitorowania), ale funkcje bezpieczeństwa powinny być zbudowane na bardziej przewidywalnych platformach.

Metodologia omówiona w ISO 13849-1 dla oprogramowania wbudowanego jest użyteczna do PLd. Na końcu zakresu normy PN-EN ISO 13849-1 można znaleźć takie oto stwierdzenie:

UWAGA 4 W przypadku części z PL_r= e oprogramowanie wbudowane związane z bezpieczeństwem jest opisane w normie IEC 61508-3:1998, Rozdział 7.

Z tego wniosek, że w przypadku systemów o bardzo wysokiej niezawodności, tj. PLe / SIL3 lub SIL4, konieczne jest przejście do normy IEC 61508. Omówione tutaj metody oparte są na ISO 13849-1, rozdział 4.6.

Uproszczony model V cyklu życia bezpieczeństwa oprogramowania

Rysunek 6 w normie PN-EN ISO 13849-1 pokazuje „uproszczony model V cyklu życia bezpieczeństwa oprogramowania”. Takie podejście jak pokazano w tym modelu do projektowania oprogramowania obejmuje zarówno sprawdzanie poprawności, jak i weryfikację, które gwarantują prawidłowe wdrożenie oprogramowania spełniającego specyfikacje projektowe.

Rzeczywistym celem modelu V jest wykonanie czytelnego, zrozumiałego, testowalnego i łatwego w utrzymaniu oprogramowania. Programiści, którzy zwykle nie pracują nad oprogramowaniem związanym z bezpieczeństwem, prawdopodobnie uznają te wymagania za uciążliwe. Model V jednak daje pewność, że oprogramowanie zostało opracowane w odpowiednim standardzie.

Cały proces jest zależny od specyfikacji funkcji bezpieczeństwa (które definiują podstawowe wymagania dotyczące bezpieczeństwa), więc nieumiejętność rozpoczęcia tej części procesu na początku wpłynie negatywnie zarówno na projekt sprzętu, jak i oprogramowanie. Specyfikacja funkcji bezpieczeństwa jest miarą używaną przy podejmowaniu decyzji, czy „wykonałeś projekt wg założeń”. Bez tego nie masz pojęcia, nad czym pracujesz.

W modelu V pokazano każdy etap procesu weryfikacji i walidacji. Linie przerywane ilustrują proces weryfikacji na każdym etapie. Zauważ, że faktyczny etap kodowania znajduje się na samym dole modelu V. Wszystko powyżej etapu kodowania to planowanie i projektowanie lub działania związane z zapewnianiem jakości.

Jaka jest różnica pomiędzy weryfikacją a walidacją?

Zasadniczą różnicą pomiędzy weryfikacją a walidacją jest to, że podczas walidacji należy odpowiedzieć na pytanie czy projekt jest właściwy (wykonany zgodnie z założeniem), a podczas weryfikacji sprawdzamy, czy gotowy etap (produkt) jest wykonany wg założeń.

Weryfikacja opisuje działanie zapewniania jakości, za pomocą którego wynik fazy jest sprawdzany pod kątem specyfikacji poprzedniej fazy. Na przykład w trakcie lub na końcu fazy kodowania przeprowadzana jest weryfikacja, czy kod faktycznie implementuje określony projekt modułu i czy przestrzegano wytycznych programowania.

Wynik pokazany strzałką ciągłą odnosi się do fazy produktu, np. do specyfikacji, projektu oprogramowania, kodu, a w przypadku wyniku końcowego – przetestowanego, zatwierdzonego oprogramowania. Może jednak również odnosić się na przykład do wyniku fazy specyfikacji w postaci planu testów, który nie jest już wymagany do kolejnej fazy. Wynik poprzednich faz służą jako dane wejściowe dla kolejnych faz.

W kontekście walidacji sprawdzanie poprawności oprogramowania jest końcową, specjalną formą weryfikacji całego oprogramowania. Sprawdzane jest, czy zostały spełnione wymagania specyfikacji oprogramowania dotyczące funkcjonalności oprogramowania. Walidacja funkcji oprogramowania musi wykazać, czy „zobowiązania umowne” zostały spełnione.

Opis kroków przedstawionych w modelu V

Specyfikacja oprogramowania związanego z bezpieczeństwem opisuje funkcje bezpieczeństwa części odpowiedzialnej za bezpieczeństwo, które mają zostać wdrożone przez oprogramowanie. Specyfikacja ta odnosi się do wymagań specyfikacji wyższego poziomu (na podstawie wiedzy, dla jakiej części sterowania jest specyfikowana funkcja bezpieczeństwa). W tej części prezentowane są ponadto:

• funkcje wykrywające i kontrolujące uszkodzenia sprzętu
• charakterystyki wydajności, takie jak maksymalny czas reakcji
• reakcje w trybie awaryjnym
• interfejsy dostarczane do innych systemów itp.

Oprócz tych wymagań funkcjonalnych należy podać wymagany PL_r, który ma być spełniony przez funkcje bezpieczeństwa, aby umożliwić wybór niezbędnych środków dla uniknięcia defektów.

Specyfikacja oprogramowania związanego z bezpieczeństwem musi zostać zweryfikowana przez osobę nie zaangażowaną w jej tworzenie. Recenzent musi najpierw potwierdzić, że specyfikacja wymagań jest zgodna ze specyfikacją wyższego poziomu, a po drugie, że spełnia wymogi formalne regulujące sposób, w jaki należy opracować specyfikację oprogramowania. Specyfikacja powinna być ustrukturyzowana i wygenerowana szczegółowo w taki sposób, aby mogła służyć również jako lista kontrolna do późniejszej weryfikacji.

Specyfikacja oprogramowania zaczyna się od postanowień dotyczących projektowania i kodowania oprogramowania. Inne elementy związane z zapewnieniem bezpieczeństwa muszą polegać na implementacji funkcji w oprogramowaniu. Specyfikacja jest zatem punktem odniesienia dla akceptacji oprogramowania.

Architektura oprogramowania jest na ogół już zdefiniowana przez system operacyjny lub narzędzie programistyczne. Projektowanie systemu i modułów dodatkowo określa strukturę i moduły, które mają być zastosowane do realizacji określonych podfunkcji bezpieczeństwa. Należy określić, jakie istniejące funkcje biblioteczne mają być zastosowane, a także czy konieczne może być opracowanie nowych funkcji specjalnie dla projektu.

Dokument projektu oprogramowania powinien opisywać strukturę i proces oprogramowania w sposób, który uczyni te aspekty zrozumiałymi dla podmiotów zewnętrznych. Im bardziej program jest oparty na ponownie używanych funkcjach oprogramowania, które zostały już zatwierdzone i są już udokumentowane w innym miejscu, tym bardziej zwięzły może być dokument projektu oprogramowania. Projekt modułu określa również nowe funkcje oprogramowania, które mają zostać opracowane specjalnie dla projektu, ich interfejsy i przypadki testowe do testów modułowych.

Następnie rozpoczyna się właściwe kodowanie. W celu uniknięcia błędów należy przestrzegać następujących trzech aspektów:

• Kod musi być czytelny i przejrzysty, aby ułatwić testowanie i bezbłędną modyfikację na późniejszym etapie. Nie bez znaczenia jest tu właściwe komentowanie programu i przypisywanie oczywistych nazw zmiennym i modułom.
• Programowanie powinno odbywać się z założeniem, że zawsze mogą występować błędy wewnętrzne lub zewnętrzne, dla których należy wprowadzić środki ich wykrywania.
• Kod musi być analizowany statycznie, tj. bez konieczności jego uruchomienia w docelowym systemie. Typowe zadania to: czy kod jest zgodny z poprzednim projektem oprogramowania? Czy istnieją punkty, w których sygnały o niższym PL (na przykład ze standardowego PLC) przesłaniają sygnał o wyższym PL? Gdzie i według jakich modułów zmienne są inicjowane, zapisywane, a następnie przypisywane do wyjścia bezpieczeństwa? Jakie funkcje oprogramowania są wykonywane warunkowo?

W fazie testowania modułów nowe funkcje oprogramowania opracowane specjalnie dla projektu są testowane i symulowane w celu sprawdzenia, czy są zakodowane zgodnie z projektem modułu. Najpóźniej podczas testowania integralności, na przykład podczas typowego uruchomienia układu sterowania maszyny, całe oprogramowanie jest testowane pod kątem poprawnego działania na sprzęcie (integracja) i zgodności z projektem systemu (weryfikacja). Obydwie fazy testowania modułu i testowania integralności są nadal środkami weryfikacji, tj. polegają na „spojrzeniu” na oprogramowanie. Testowanie integralności i sprawdzanie poprawności funkcji bezpieczeństwa są często wykonywane jednocześnie. Testy te muszą oczywiście zostać zaplanowane i muszą być udokumentowane razem z wynikami testu. To, czy podfunkcje związane z bezpieczeństwem oprogramowania działają zgodnie z ustaleniami, zależy od weryfikacji oprogramowania, która została już opisana. W przypadku wyższych PL d i e wymagany jest również rozszerzony test funkcjonalny.

Poszczególne funkcje oprogramowania, które zostały certyfikowane lub zatwierdzone za pomocą środków zapewniania jakości, nie muszą być ponownie testowane. Jednak gdy tylko kilka z tych funkcji zostanie połączonych dla konkretnego projektu, nowa forma podfunkcji bezpieczeństwa musi zostać zatwierdzona. Nawet w przypadku certyfikowanych modułów niebezpieczne systematyczne awarie mogą być spowodowane błędami w parametryzacji i logice.

Co w przypadku, gdy oprogramowanie związane z bezpieczeństwem musi być zmodyfikowane?

Doświadczenie pokazuje, że nawet po początkowych testach program nadal będzie przedmiotem rozbudowy i adaptacji podczas uruchamiania instalacji lub maszyny. Ta procedura nazywa się „modyfikacją”. Zmiany te są często tak rozległe, że nie tylko kod, ale nawet oryginalna specyfikacja nie jest już odpowiednia i powinna zostać w rzeczywistości zmieniona. Zmiany funkcji bezpieczeństwa na jednym końcu instalacji lub maszyny mogą również mieć wpływ na funkcje bezpieczeństwa na drugim końcu, które nie zostały zmodyfikowane na tym etapie. Podobnie modyfikacje mogą ujawnić luki w koncepcji bezpieczeństwa. Należy zbadać tę możliwość i powtórzyć niezbędne fazy modelu V, jeśli zajdzie taka potrzeba.

Praktyczne doświadczenie pokazuje również, że nawet po zainstalowaniu i uruchomieniu maszyna lub instalacja może nadal wymagać na przykład dodatkowego urządzenia zatrzymania awaryjnego lub drzwi ochronnych. Proces obróbki jest również często usprawniany, przez co po raz kolejny należy w tym przypadku dostosować koncepcję bezpieczeństwa. Istniejące oprogramowanie musi zostać „zmodyfikowane”. Uwaga: może tak być w przypadku oprogramowania, które było już eksploatowane przez dłuższy czas i w przeważającej części bez awarii spowodowanych błędami oprogramowania – co może również oznaczać, że obecna, ale „ukryta” usterka po prostu jeszcze nie miała szansy się pojawić. Jednak po modyfikacji sytuacja ta może ulec zmianie, na przykład jeśli oprogramowanie nie zostało odpowiednio skonstruowane, a poszczególne moduły lub funkcje nie są całkowicie pozbawione wzajemnego wpływu.

W opisanych sytuacjach często obowiązuje „Prawo Murphy’ego”: program został napisany wiele lat wcześniej, ale pierwotni programiści mają teraz pilniejsze zadania lub już opuścili firmę. W takim przypadku w interesie zarówno bezpieczeństwa, jak i oszczędności maszyny lub instalacji jest to, aby oprogramowanie posiadało niżej wymienione właściwości: czytelne, z podziałem na struktury, zrozumiałe, a także łatwe we wprowadzaniu modyfikacji, które nie powodują błędów – niezależnie od tego, jaki personel programistyczny będzie dostępny.

Zasadniczo modyfikacja oznacza, że proces projektowania musi zostać ponownie uruchomiony w modelu V, w punkcie, w którym dokonano zmiany na przykład:

• po zmianie kodu należy powtórzyć test modułów i integralności, co przełoży się na wynik walidacji;
• jeżeli zmiany były również wymagane w specyfikacji, to również ona musi zostać zweryfikowana ponownie, na przykład poprzez sprawdzenie przez inną osobę, aby upewnić się, że żadne błędy nie wkradły się w innym punkcie specyfikacji. W związku z tym należy powtórzyć wszystkie środki projektu i weryfikacji, a także walidację odpowiednich funkcji bezpieczeństwa.

Oprogramowanie związane z bezpieczeństwem – podział

Aby uprościć konfigurowanie systemów bezpieczeństwa dla projektantów i integratorów, można zastosować dwa podejścia do projektowania oprogramowania:

• z wykorzystaniem wstępnie skonfigurowanego oprogramowanie (z pre-definiowanych bloków),
• z wykorzystaniem pełnego, dostosowanego oprogramowania.

Wstępnie skonfigurowane oprogramowanie związane z bezpieczeństwem

Wykorzystanie pre-definiowanych bloków funkcyjnych jest zwykle używane do konfigurowania sterowników PLC lub programowalnych przekaźników bezpieczeństwa. Ten typ oprogramowania w normie PN-EN ISO 13849-1 jest określany jako SRESW (oprogramowanie wbudowane związane z bezpieczeństwem).

Pre-definiowane bloki funkcyjne są dostarczane przez producenta wraz z urządzeniem. Każdy blok funkcyjny może nadawać się do realizacji określonego zadania: zatrzymania awaryjnego, monitorowania blokady osłony ruchomej, wykrywania prędkości obrotowej itd. Podczas konfigurowania sterownika PLC bezpieczeństwa lub modułów bezpieczeństwa, które wykorzystują tego typu bloki, projektant wybiera odpowiedni blok, a następnie konfiguruje wejścia, wyjścia i wszelkie inne wymagane cechy funkcjonalne. Projektant nie ma dostępu do kodu związanego z bezpieczeństwem, więc oprócz definiowania połączeń między blokami, nie ma możliwości popełnienia żadnych innych błędów. Bloki funkcyjne są już zweryfikowane i zwalidowane przez producenta elementu sterowania, zwykle przy wsparciu akredytowanej jednostki certyfikującej. Bloki funkcyjne zwykle mają związane z nimi PL, a w opisie bloku funkcyjnego zostanie zamieszczona instrukcja typu „odpowiedni dla PLe”.

Takie podejście eliminuje potrzebę wykonywania szczegółowej weryfikacji i walidacji kodu przez integratora. Jednak konstruktor maszyn jest nadal zobowiązany do wykonania weryfikacji i walidacji działania całego systemu bezpieczeństwa po jego skonfigurowaniu. Weryfikacja i walidacja zawiera testy tzw. „wstrzykiwania błędów”, i testy funkcjonalne, aby upewnić się, że system będzie zachowywał się zgodnie z przeznaczeniem w przypadku zapotrzebowania na funkcję bezpieczeństwa.

Korzystanie ze pre-definiowanych bloków funkcyjnych pozwala osiągnąć pierwszy cel, czyli uniknięcie błędów, przynajmniej w zakresie kodowania oprogramowania. Oprogramowanie konfiguracyjne dokona weryfikacji konfiguracji bloków funkcyjnych przed skompilowaniem oprogramowania przeznaczonego do przesłania do kontrolera bezpieczeństwa, aby na tym etapie wychwycić większość błędów konfiguracji. Oprogramowanie konfiguracyjne zazwyczaj zawiera możliwość opisania konfiguracji odpowiednimi szczegółami, aby program był czytelny, zrozumiały i łatwy w diagnozowaniu.

Pełne, dostosowane oprogramowanie związane z bezpieczeństwem

Takie podejście jest stosowane, gdy używana jest w pełni dostosowana platforma sprzętowa, a oprogramowanie związane z bezpieczeństwem jest zaprojektowane do działania na tej konkretnej platformie. Norma PN-EN ISO 13849-1 odnosi się do tego typu oprogramowania jako „Oprogramowania użytkowego związanego z bezpieczeństwem (SRASW)”. Tego typu w pełni spersonalizowane oprogramowanie związane z bezpieczeństwem wykorzystywane jest w bardzo wyspecjalizowanym systemie bezpieczeństwa, w którym używane są np. układy FPGA lub mikroprocesory. Systemy te są zwykle programowane przy użyciu języków o pełnej zmienności FVL.

W takim przypadku należy zastosować pełne podejście do sprzętu i oprogramowania. PN-EN ISO 13849-1 nie jest najlepszym wyborem dla tego podejścia ze względu na jego uproszczenie, więc zalecane jest stosowanie normy IEC 61508-3 jako podstawy do projektowania, weryfikacji i walidacji w pełni spersonalizowanego oprogramowania.

Wymagania PN-EN ISO 13849-1 dotyczące oprogramowania

Punkt 4.6.3 normy PN-EN ISO 13849-1 zawiera listę wymagań, które należy spełnić w procesie walidacji i weryfikacji wg modelu V dla SRASW i pozwala, aby poziom PLa do PLe można było uzyskać za pomocą kodu napisanego w LVL, a aplikacje PLe można również zaprojektować przy użyciu FVL. W przypadkach, w których oprogramowanie jest opracowywane przy użyciu FVL, oprogramowanie może być traktowane jako obsługiwane oprogramowanie wbudowane (SRESW).

Jeśli w tym momencie zastanawiasz się nad tym co oznaczają skróty FVL i LVL odsyłam do artykułu Układy programowalne bezpieczeństwa – zasady programowania, gdzie znajdziesz odpowiedź na to pytanie.

Rysunek poniżej pokazuje wymagania normy PN-EN ISO 13849-1 zarówno dla SRASW jak i SRESW. Odpowiedni pakiet podstawowych środków jest najpierw ustalony dla wszystkich PL zarówno dla SRASW, jak i SRESW. Te podstawowe środki można uznać za podstawowe zasady bezpieczeństwa specyficzne dla oprogramowania i są wystarczające do opracowania oprogramowania dla PL a lub b. W przypadku oprogramowania stosowanego w części sterowania dla PL c do e, podstawowe wymagania są uzupełniane przez dodatkowe wymagania w celu uniknięcia błędów. Te ostatnie są wymagane dla PLc o niższej skuteczności, dla PLd ze średnią skutecznością i dla PLe o wyższej skuteczności.

Jedną z istotnych zmian w normie PN-EN ISO 13849-1 w porównaniu z poprzednio obowiązującą PN-EN 954-1 było sformułowanie po raz pierwszy wymagań dotyczących oprogramowania i jego rozwoju. W tym miejscu należy podkreślić: wymagania zawarte w podpunkcie 4.6 normy umożliwiają opracowanie oprogramowania związanego z bezpieczeństwem dla wszystkich części sterowania związanych z bezpieczeństwem w sektorze maszynowym i dla wszystkich wymaganych poziomów Performance Level od a do e.

Wymagania dotyczące oprogramowania związanego z bezpieczeństwem przeznaczone są przede wszystkim dla programistów aplikacji, których zadaniem jest opracowanie funkcji bezpieczeństwa maszyny, np. w języku zorientowanym na aplikację w programowalnym sterowniku logicznym (PLC). Z kolei te wymagania normy EN ISO 13849-1 nie są szczególnie nowe dla twórców SRESW (oprogramowanie wbudowane związane z bezpieczeństwem), tj. oprogramowania układowego lub narzędzi programowych dla elektronicznych elementów bezpieczeństwa. Takie „wbudowane oprogramowanie” dla komponentów, które są generalnie certyfikowane, często podlegają bardzo złożonym wymaganiom podstawowej normy bezpieczeństwa IEC 61508-3 (i jej dalszych siedmiu części), która jest wiążąca dla norm IEC obejmujących bezpieczeństwo funkcjonalne.

---

Artykuł w dużej części powstał na podstawie raportu IFA Report 2/2017e “Functional safety of machine controls – Application of EN ISO 13849”