Assurance cases zazwyczaj opierają się na argumentach dotyczących bezpieczeństwa funkcjonalnego, aby wykazać, że awarie nie spowodują niebezpiecznych sytuacji. Jednak wypadki mogą mieć też inne przyczyny związane z zachowaniem systemu niż awarie. Właśnie tutaj pojawia się SOTIF. Skrót ten oznacza bezpieczeństwo zamierzonej funkcjonalności. Co to oznacza? Obejmuje on łagodzenie czynników ryzyja związanych z nieoczekiwanymi sytuacjami lub ograniczeniami systemu. Jednym z przykładów nieoczekiwanej sytuacji jest jasne światło słoneczne utrudniające pojazdowi autonomicznemu identyfikację pasów ruchu. Innym przykładem jest niewłaściwe użycie systemu, takie jak wydanie przez operatora systemu poleceń, których nie przewidziano dla danego trybu pracy systemu. SOTIF pomaga nam zapewnić bezpieczne zachowanie systemu we wszelkich nieoczekiwanych sytuacjach.
SOTIF rozszerza bezpieczeństwo funkcjonalne
Bezpieczeństwo funkcjonalne koncentruje się na zagrożeniach wynikających z usterek lub awarii komponentów systemu, sprzętu lub oprogramowania. W sektorze motoryzacyjnym jest to opisane w normie ISO 26262. Natomiast norma ISO 21448 reguluje zapewnienie bezpieczeństwa w przypadku zagrożeń spowodowanych ograniczeniami systemu i nieoczekiwanymi sytuacjami, czyli SOTIF.
Proces zapewnienia bezpieczeństwa SOTIF obejmuje kilka kroków:
- Granice i zakres zamierzonej funkcjonalności muszą zostać zdefiniowane w Projektowej Domenie Operacyjnej (ODD).
- Zachowanie systemu jest analizowane pod kątem potencjalnie niebezpiecznych scenariuszy.
- Identyfikacja zabezpieczeń, które mogą być powiązane z modyfikacjami funkcjonalnymi w celu osiągnięcia celów SOTIF.
- Wdrożenie i weryfikacja zaplanowanych środków łagodzących.
- Walidacja przeprowadzana jest w zróżnicowanych i reprezentatywnych warunkach.
- Monitorowanie w terenie w celu oceny i utrzymania SOTIF jest definiowane do wdrożenia w trakcie eksploatacji systemu.
Argumentacja SOTIF
Realizacja procesu SOTIF musi być przedstawiona w argumentacji safety case systemu. ISO 21488 zwiera wskazówki jak to robić oraz przykładowe argumentacje GSN. Poniżej przedstawiono przykładowy fragment argumentacji najwyższego poziomu dla procesu zapewnienia bezpieczeństwa SOTIF przed jego wdrożeniem. Dla każdej głównej fazy procesu SOTIF utworzono w argumentacji osobny postulat (Claim).
Argumentację tę należy rozszerzyć o drugą gałąź dla fazy operacyjnej cyklu życia systemu. Ponieważ argumentacja jest opracowywana i zatwierdzana przed rozpoczęciem eksploatacji systemu, koncentruje się na nie na realizacji procesu utrzymania bezpieczeństwa SOTIF, ale na zademonstrowaniu możliwości realizacji tego procesu. W trakcie eksploatacji systemu można argumentację rozszerzyć o dowody, że te działania są wykonywane.
Ponieważ SOTIF stanowi rozszerzenie bezpieczeństwa funkcjonalnego, pojawia się pytanie, jak te dwie argumentacje są ze sobą powiązane. Istnieje kilka wspólnych działań lub produktów procesu, które są współdzielone między bezpieczeństwem funkcjonalnym a SOTIF, takich jak:
- zidentyfikowane hazardy
- ograniczenia i założenia bezpieczeństwa funkcjonalnego
- cele i wymagania bezpieczeństwa
- weryfikacja i walidacja wymagań bezpieczeństwa
Można opracować oddzielne moduły assurance case dla bezpieczeństwa funkcjonalnego oraz dla SOTIF, które mogą w razie potrzeby odwoływać się do wspólnych artefaktów. Prawdopodobnie konieczne będzie dodanie postulatu, aby wykazać, że środki bezpieczeństwa funkcjonalnego i SOTIF są spójne i łącznie wystarczające do osiągnięcia akceptowalnego poziomu ryzyka systemu.
Prezentowaną argumentację SOTIF można przeglądać online w PREMIS, korzystając z tego linku.
Podsumowując, wspólne assurance case obejmujące SOTIF i bezpieczeństwo funkcjonalne pozawala na zapewnienie bezpieczeństwa systemu obejmującego hazardy związane zarówno z awariami, jak i ograniczeniami systemu, w tym z sytuacjami nieoczekiwanymi. Norma ISO 21448 jest dedykowana dla sektora motoryzacyjnego, ale to podejście jest również przydatne w innych branżach.