Systemy safety-critical różnią się od standardowych projektów informatycznych.  Niepoprawne działanie takiego systemu może powodować śmierć ludzi, czy skażenie środowiska. Dlatego podczas realizacji takiego projektu musimy podjąć specjalne kroki minimalizujące ryzyko defektu. Obejmują one między innymi szczegółową dokumentację, czy rygorystyczny proces wytwarzania oprogramowania precyzujący poszczególne kroki od zbierania wymagań i architektury aplikacji po zalecane techniki programistyczne, czy procedury korzystania z zewnętrznych bibliotek. Zgodność projektu z normami jest sprawdzana przez niezależne urzędy certyfikacyjne. Dzięki temu ryzyko wystąpienia błędu jest bardzo małe, ale koszty projektu są średnio dziesięciokrotnie większe, niż w normalnym projekcie.

Wprowadzenie do systemów safety-critical

Na tym blogu staram się dzielić wiedzą o systemach safety-critical, którą zdobyłem pracując nad projektami dla branży medycznej, czy kolejowej, a także czytając wiele norm i innych materiałów. Oto lista najciekawszych artykułów, jakie tutaj opublikowałem:

Kiedy od softu zależy ludzkie życie – jeżeli nie miałeś nigdy do czynienia z systemami safety-critical, zacznij od tego artykułu. Tłumaczę w nim, dlaczego narzędzia i praktyki używane w zwykłych projektach tutaj się nie sprawdzą. Opisuję też restrykcje dotyczące softu i prowadzenia projektu narzucane przez normy.

Sposoby przeciwdziałania błędom – możliwym błędom zapobiegamy odpowiednio projektując zarówno software, jak i hardware. Często te same zadania są wykonywane przez kilka niezależnych modułów, albo praca jednych jest kontrolowana przez inne. W tym artykule opisuję popularne metody.

Architektura wieloprocesorowa – wydzielenie części safety – działający system jednocześnie realizuje wiele zadań. Część z nich wpływa na bezpieczeństwo np. sterowanie silnikami, a część nie np. wyświetlanie danych. Musimy więc zapewnić, żeby mniej ważne zadania nie spowodowały błędów w działaniu tych kluczowych. Dobrym rozwiązaniem może okazać się podzielenie tych zadań na niezależne procesory.

V-model – sposób prowadzenia projektu – systemy safety-critical są prowadzone zwykle według schematu zwanego V-modelem. Daje on pewne założenia, które muszą być spełnione w szczegółowym procesie wytwarzania oprogramowania. Opisuje takie kroki jak planowanie, implementacja i weryfikacja.

Poziomy bezpieczeństwa – nie wszystkie systemy wymagają tak samo rygorystycznego podejścia do projektu. Tym bardziej, że zawsze wiąże się to ze zwiększonymi kosztami. Dlatego poszczególne normy definiują różne poziomy bezpieczeństwa.

Techniki zwiększające bezpieczeństwo – aby zapewnić wymagany poziom bezpieczeństwa, stosuje się odpowiednie techniki podczas projektowania, implementacji i walidacji systemu. Część z nich jest specyficzna dla systemów safety-critical, ale wiele zostało zaczerpniętych ze standardowych systemów.

Jakie języki programowania używamy w systemach safety-critical i dlaczego?

Analiza ryzyka – Jak znajdować w systemie możliwe defekty i zapewnić wystarczające metody zmniejszające ryzyko ich wystąpienia.

Software of Unknown Provenance – czyli jak wykorzystywać istniejący soft w safety-critical.

Koszty wytworzenia systemu safety-critical – ile kosztuje średnio linijka kodu produkcyjnego i czy warto korzystać z płatnych narzędzi.

Sanity checki

System safety-critical musi być również odporny na różne problemy ze sprzętem. Nie zdarzają się zbyt często, ale są możliwe. Szczególnie, jeśli system ma działać np. 15 lat w słońcu, mrozie i deszczu i narażony na wstrząsy czy uderzenia – co jest prawdą choćby dla samochodu. Dlatego systemy safety cyklicznie sprawdzają poprawność pamięci stałej, RAMu, procesora, czy zegara. Zabezpieczają się również na wypadek zawieszenia programu.

Testy RAM – wprowadzenie – odczytanie z RAMu nie tej wartości, którą tam ostatnio zapisaliśmy może zupełnie zmienić przebieg programu. W tym artykule tłumaczę budowę wewnętrzną pamięci RAM i możliwe błędy w jej działaniu.

Testy RAM – algorytmy – dobry algorytm testowania RAM musi być w stanie wykryć wszystkie typy błędów i wykonywać się w wystarczająco szybko, aby znaleźć je zanim spowodują katastrofę. Przy okazji nie powinny negatywnie wpływać na podstawowe działanie systemu. W tym artykule opisuję możliwe opcje.

Watchdog timer – wprowadzenie – watchdog to proste zabezpieczenie przed zawieszeniem się procesora. Aby poprawnie z niego korzystać, należy jednak znać kilka niuansów, których dowiecie się z tego artykułu.

Watchdog w środowisku wielowątkowym – obsługa watchdoga dodatkowo komplikuje się, jeżeli działamy w środowisku wielowątkowym i chcemy jednocześnie monitorować kilka procesów. W tym celu niezbędne jest zastosowanie kilku bardziej zaawansowanych technik.

Historie słynnych bugów

Zanim odpowiednie standardy zostały ustanowione, niestety musieliśmy uczyć się na własnych błędach. Niektóre defekty systemów safety miały tragiczne konsekwencje. Ich analiza pozwoliła jednak wyciągnąć wnioski na przyszłość. W tym cyklu przytaczam historie słynnych błędów.

Therac-25 – Błąd w urządzeniu medycznym stosowanym w radioterapii, który powodował silne napromieniowanie niektórych pacjentów.

Ariane 5 – Rakieta Europejskiej Agencji Kosmicznej, która wybuchła podczas swojego pierwszego lotu przez integer overflow.