Program bezpieczeństwa to nie tylko program aplikacyjny służący do zaprogramowania obsługi funkcji bezpieczeństwa z poziomu aplikacji użytkownika. To również oprogramowanie wbudowane, które z wykorzystaniem systemu operacyjnego napisanego na mikroprocesory i w połączeniu z kompilatorem powinno zapewniać bezawaryjną pracę w zastosowaniach przemysłowych, transportowych, jądrowych, procesowych, medycznych, lotniczych, samochodowych i urządzeń domowych. System operacyjny do takich zastosowań to tzw. system krytyczny pod względem bezpieczeństwa (ang. safety-critical system).

W przypadku oprogramowania wbudowanego, obok takich pojęć jak funkcja bezpieczeństwa pojawia się nowe pojęcie: funkcja krytyczna pod względem bezpieczeństwa. Obydwie te funkcje w systemach wbudowanych ewoluują już od dziesięcioleci, zapewniając zwiększoną funkcjonalność, ale jednocześnie stają się bardziej złożone i stają się coraz bardziej wymagające w zakresie oprogramowania.

Co to jest system krytyczny pod względem bezpieczeństwa?

System krytyczny pod względem bezpieczeństwa to jedno z pojęć, na temat których niewiele jest informacji w języku polskim. System krytyczny pod względem bezpieczeństwa lub system o krytycznym znaczeniu dla życia to system, którego awaria lub nieprawidłowe działanie może skutkować jednym (lub więcej) z następujących wyników:

• śmierć lub poważne obrażenia u ludzi,
• utratę lub poważne uszkodzenie sprzętu / mienia,
• szkody środowiskowe.

Systemy tego typu od dawna już mają zastosowanie w medycynie, inżynierii nuklearnej, transporcie, lotnictwie, kosmonautyce, a więc tam, gdzie awaria systemu może doprowadzić do katastrofy ekologicznej lub śmierci wielu ludzi. Systemy tego typu są objęte pewnymi wymogami prawnymi i regulacyjnymi. Metody projektowania takich systemów obejmują m.in. probabilistyczną ocenę ryzyka, i metodę łączącą analizę uszkodzeń i efektów (FMEA) z analizą drzewa błędów. Inżynieria oprogramowania takich systemów jest więc szczególnie trudną dziedziną. Czy jest zatem miejsce na tego typu systemy operacyjne w maszynach, których użytkowanie nie wiąże się aż z tak poważnymi konsekwencjami?

Wkraczając w epokę Industry 4.0, producenci wprowadzają coraz więcej urządzeń i czujników wyposażonych w układy mikroprocesorowe, co sprawia, że oprogramowanie wbudowane przeżywa ekspansję w zastosowaniu przemysłowym. Błędy systematyczne (o których pisałem w artykule „Warunki funkcjonowania oprogramowania w aplikacjach bezpieczeństwa”) zawarte w takim oprogramowaniu mają wpływ na niezawodność systemów sterowania. Mimo tego, że nie wszystkie tego typu urządzenia są traktowane jako część sterowania związana z bezpieczeństwem, to mogą one mieć ogromny wpływ na zachowanie się systemu sterowania, a więc na całościowe bezpieczeństwo. Budowa i struktura oprogramowania musi więc podlegać szczególnym regułom, które pozwala zminimalizować występowanie błędów systematycznych.

Powiązany temat: Warunki funkcjonowania oprogramowania w aplikacjach bezpieczeństwa

Tego typu systemy operacyjne również mają swoje miejsce w automatyce przemysłowej, gdzie obserwuje się zastosowanie coraz bardziej skomplikowanych systemów sterowania.

Powstało już kilka tzw. bezpiecznych systemów operacyjnych czasu rzeczywistego do zaimplementowania w mikrokontrolerach, m.in. Safe RTOS, EmbOS-SAFE. Systemy operacyjne tego rodzaju są używane do izolowania kodu o krytycznym znaczeniu dla bezpieczeństwa, zapewniając działanie funkcji bezpieczeństwa bez zakłóceń pochodzących z innych zadań. Systemy bezpieczeństwa czasu rzeczywistego są certyfikowane zgodnie z wymaganiami IEC 61508 z poziomem zapewnienia bezpieczeństwa do SIL3 (jest to najwyższy możliwy poziom dla komponentu wyłącznie programowego). Niektóre systemy są certyfikowane dla zastosowań w medycynie (IEC 62304), przemyśle nuklearnym (IEC 61513, IEC 62138), procesowym (IEC 61511) itd.

Podstawową cechą bezpiecznych systemów operacyjnych czasu rzeczywistego jest ochrona pamięci i izolowanie tym samym od złych skutków nieuprzywilejowanych zadań. Standardowy system operacyjny dokonuje dynamicznej alokacji pamięci, co może wprowadzić znaczące ryzyko w systemie o krytycznym znaczeniu dla bezpieczeństwa. Nie trudno przewidzieć co stanie się, jeśli system operacyjny potrzebuje więcej pamięci, aby wykonać zadanie bezpieczeństwa, ale pamięci tej brakuje. Bezpieczny system operacyjny nie wykonuje żadnych dynamicznych operacji alokacji pamięci, ale wymaga od aplikacji przydzielenia bloku pamięci dla części odpowiedzialnej za bezpieczeństwo. Izolowanie zadań poprzez system operacyjny umożliwia programistom współtworzenie kodu krytycznego pod względem bezpieczeństwa z kodem niezwiązanym z bezpieczeństwem.

Systemy operacyjne tego typu mogą również pracować w środowisku wielordzeniowym. Mogą być to rdzenie realizujące funkcje krytyczne pod względem bezpieczeństwa lub rdzenie zapewniające monitorowanie lub/i weryfikację podstawowej funkcji.

Dlaczego to takie ważne?

Gdyż wykorzystanie mikroprocesorów jest dziś coraz częściej obecne w czujnikach pomiarowych, czujnikach wielkości nieelektrycznych, czujnikach wizyjnych i innych, a błędy zawarte w programach wbudowanych tych urządzeń mają bezpośredni wpływ na niezawodność całego systemu sterowania.

Tak ogromne wykorzystanie czujników z dodatkową funkcjonalnością, np. uzyskaniem od czujnika dodatkowych wartości odległości, temperatury itp. powoduje, że nie może dojść do sytuacji, gdy dostęp do pamięci czujnika powoduje w następstwie powstanie dodatkowych zagrożeń. Weźmy jako przykład coraz częściej wykorzystywany interfejs IO-Link. W czujnikach lub hubach IO-Link istnieje możliwość dostępu do pamięci takiego urządzenia w postaci czytania lub zapisywania rejestrów. Operacja taka nie może powodować powstawania błędów związanych z niezabezpieczeniem alokowania pamięci przez system operacyjny urządzenia.

Z tego powodu, że zbyt popularne stało się ostatnio nadążanie producentów komponentów systemów sterowania za nowoczesnym trendem nazwanym kilka lat temu Przemysłem 4.0 lub Industry 4.0, producenci zbyt wcześnie decydują się na wprowadzanie do obrotu urządzeń, które mają podkreślić pozycję producenta na rynku. Powoduje to, że mimo stosowania sprawdzonych technik cechujących systemy operacyjne powstaje sporo błędów systematycznych na poziomie opisu sprzętu, które mogą ujawnić się od razu, w pewnych warunkach, albo nawet po kilku latach działania urządzenia. Dlatego producenci często udostępniają nowe wersje oprogramowania wbudowanego, które należy pobrać i załadować do urządzenia.

System krytyczny pod względem bezpieczeństwa to pojęcie, które będzie się pojawiało coraz częściej w układach sterowania, od których będzie zależało prawidłowe i bezpieczne funkcjonowanie tzw. inteligentnej fabryki. Być może nawet tego nie zauważamy, że wprowadzając programowalny komponent bezpieczeństwa do obrotu, producent tego komponentu musiał wykonać wiele pracy (o problemach dotyczących programowalnych komponentów bezpieczeństwa pisałem w artykule „Podstawy bezpieczeństwa w Industry 4.0“). Ta praca to wiele godzin testów i prób, a użycie bezpiecznych, certyfikowanych i sprawdzonych systemów operacyjnych pozwala ten czas skrócić. Kwestią do rozważań jest zastanowienie się, gdzie leży granica zastosowań bezpiecznych systemów operacyjnych. Czy tylko w urządzeniach odpowiedzialnych za bezpieczeństwo? Świadomość pojawiania się nowych zagrożeń związanych z nadążaniem za modą (mam na myśli Industry 4.0) będzie niezwykle istotna, aby odpowiedzieć na to pytanie.