Autor: Maciej Gajdzica (Senior Software Developer)
Projektując systemy safety-critical musimy jednocześnie zapewnić dwa cele:
Projekty safety-critical(systemy krytyczne), jak każdy inny projekt, również mają ograniczone budżety i deadline’y. Rozwijanie tego typu systemów jest więc często próbą kompromisu między dwoma sprzecznymi celami, ponieważ zarówno dodawanie funkcjonalności, a przez to zwiększanie złożoności systemu, jak i ograniczenia finansowe czy czasowe zwiększają prawdopodobieństwo wystąpienia błędów. Identyfikację potencjalnych problemów i dobranie środków zapobiegawczych, adekwatnych do poziomu bezpieczeństwa, który chcemy uzyskać, zapewnia jakościowa i ilościowa analiza ryzyka.
Pierwszą, najważniejszą zasadą analizy ryzyka jest prowadzenie jej od samego początku projektu. Nie jesteśmy w stanie zapewnić wystarczającego bezpieczeństwa, jeżeli będziemy je uwzględniać dopiero na końcu prac. Nie powiedzie się również próba zapewnienia bezpieczeństwa poszczególnym modułom, aby dopiero na koniec połączyć je w całość.
To właśnie błędy w integracji, na styku elementów, są właśnie największym źródłem problemów. Dlatego właśnie nie mamy wyboru – analizę ryzyka musimy prowadzić od samego początku projektu. Ale jak to robić?
Analiza ryzyka składa się z dwóch etapów:
Podczas analizy konkretnych punktów z listy możemy wykorzystać macierz ryzyka. Każdemu elementowi na sporządzonej wcześniej liście przyporządkowujemy dwie wartości – jak duże są konsekwencje wystąpienia i jak prawdopodobne jest jego wystąpienie. Konsekwencje mogą być katastrofalne, poważne, aż do zupełnie pomijalnych. Szansa wystąpienia zaś może być wysoka, niska, albo też zdarzenie może być niemożliwe. Znając te dwie wartości jesteśmy w stanie umieścić zdarzenie na macierzy oceny ryzyka:
Jak widać – macierz ta jest podzielona na kilka regionów zaznaczonych różnymi kolorami. W zależności od wymaganego poziomu bezpieczeństwa SIL niektóre regiony są niedozwolone. Oznacza to, że jeżeli ryzyko znalazło się w takim regionie, musimy podjąć działania, aby przesunąć je na macierzy w prawo (czyli zmniejszyć negatywne konsekwencje) albo w dół (czyli zmniejszyć lub wyeliminować szansę wystąpienia). Takie działania możemy podjąć na trzy sposoby – wykorzystując hardware, software lub ludzi i procedury.
Rozwiązania hardware’owe są najbardziej pożądane. Maszyny działają w sposób szybki i powtarzalny, dodatkowo hardware psuje się w przewidywalny sposób i możemy łatwo stwierdzić, czy system działa poprawnie. Na drugim miejscu są sposoby wykorzystujące software. Soft również działa w sposób szybki i automatyczny, a za jego pomocą można nawet realizować dużo bardziej skomplikowane operacje. Niestety wiąże się to z dużym zwiększeniem złożoności uniemożliwiającym udowodnienie, że układ działa poprawnie. Duża złożoność zwiększa ryzyko wprowadzania błędów przy zmianach kodu. Najmniej pożądanym rozwiązaniem jest wykorzystanie ludzi i procedur. Ludzie działają dużo wolniej od maszyn, wyniki ich pracy nie są powtarzalne, mają problemy ze zmęczeniem, stresem i znudzeniem. Poza tym jeżeli ludzie popełnią błąd, mogą odpowiadać przed sądem.
Znana ekspert od bezpieczeństwa systemów Nancy Leveson twierdzi wręcz, że „przestrzeganie procedur nie gwarantuje bezpieczeństwa systemu. Gwarantuje jedynie, że będzie kogo obciążyć winą: albo za nieprzestrzeganie procedur, albo za przestrzeganie ich widząc, że sytuacja wymyka się spod kontroli.”
Czasem jednak interwencja operatora jest nieodzowna. Tym bardziej, że system safety-critical przechodzi w stan bezpieczny, odmawia restartu przy podejrzeniu błędu i nie próbuje za wszelką cenę kontynuować pracy. Lepiej jednak jest zgłosić fałszywy alarm niż przegapić niebezpieczną sytuację. Musimy jednak pamiętać, aby nie nadużywać tego mechanizmu – jeśli system zgłasza fałszywe błędy zbyt często – ludzie przestają im wierzyć, co może prowadzić do przeoczenia prawdziwych pomyłek.
Dowiedz się więcej o rozwoju systemów, od których zależy ludzkie życie -> oprogramowanie safety-critical
