Argumentacja przez eliminację (Eliminative Argumentation) jest alternatywnym podejściem do budowy assurance case. Zwykle argumentacja jest budowa w sposób pozytywny i koncentruje się na zapewnieniu dlaczego uważamy, że cel został osiągnięty. Argumentacja przez eliminację polega na stałym zadaniu pytania „a jeżeli?”. Struktura argumentacji może być całkiem podobna do zwykłej argumentacji pozytywnej, ale chodzi tu o nastawienie podczas prac na szukanie słabych punktów argumentacji, które stanowią przeszkodę w wykazaniu celu argumentacji. Osiąga się to przez jawne wskazywanie możliwych słabych punktów i następnie jawne wykazywanie, że podane słabości nie występują. Siłą podejścia jest właśnie jawne pokazywanie wszystkich znanych przeszkód. Pozwala to na uniknięcie błędu nadmiernego optymizmu i naginania faktów do planowanego celu.

Proces budowy argumentacji przez eliminację też jest trochę inny. Dla każdego kroku wnioskowania, rozpoczynając od wnioskowania dla głównego postulatu (claim’a), wykonywana jest analiza dla identyfikacji wszystkich możliwych przyczyn, że dany cel nie może zostać osiągnięty. Każda przeszkoda (defeater) zostaje jawnie opisana w argumentacji. W kolejnym kroku dla każdej przeszkody należy znaleźć argumentację popartą dowodami, że dana przeszkoda nie jest skuteczna. Dla tej argumentacji też należy sprawdzić, jakie są możliwe kolejne przeszkody, które mogą sprawić, że nie będzie skuteczna. Budowa argumentacji trwa tak długo, aż nie można już zidentyfikować więcej przeszkód, oraz wszystkie przeszkody są skutecznie odrzucone.

Prześledzimy stosowanie podejścia budowy argumentacji przez eliminację na prostym przykładzie, zaczerpniętym z pierwszej publikacji o tym podejściu, raportu SEI „Eliminative Argumentation: A Basis for Arguing Confidence in System Properties” z roku 2015. Celem argumentacji jest wykazanie, że działa światło w pokoju.

Zaczniemy od tradycyjnego podejścia do budowy argumentacji, to znaczy definiujemy główny postulat, a dla niego strategię bazującą na dekompozycji na cele szczegółowe takie jak dostępność energii elektrycznej, podłączenie włącznika oraz sprawność żarówki. Dla każdego z nich należy podać dowody na spełnienie wymagań. Przykładowa argumentacja jest pokazana na diagramie poniżej.

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:

1. Granice i zakres zamierzonej funkcjonalności muszą zostać zdefiniowane w Projektowej Domenie Operacyjnej (ODD).
2. Zachowanie systemu jest analizowane pod kątem potencjalnie niebezpiecznych scenariuszy.
3. Identyfikacja zabezpieczeń, które mogą być powiązane z modyfikacjami funkcjonalnymi w celu osiągnięcia celów SOTIF.
4. Wdrożenie i weryfikacja zaplanowanych środków łagodzących.
5. Walidacja przeprowadzana jest w zróżnicowanych i reprezentatywnych warunkach.
6. 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).

Podczas pracy z argumentacjami assurance case użyteczny może być prosty tekstowy format ich opisu. Chodzi o to, aby taka tekstowa argumentacja była możliwa do zrozumienia dla człowieka oraz do stosowania z narzędziami AI, a jednocześnie formalnie zdefiniowana, aby można było takie argumentacje importować do edytorów assurance case. W takim właśnie celu wprowadzamy LTAC – Lightweight Text Assurance Case. Spójrzmy na przykład argumentacji. Czy jest zrozumiały?

Argumentacje zaufania (confidence argument) pomagają uzasadnić, że główne argumentacje w assurance case są skuteczne i wiarygodne. Podczas gdy argumentacja główna bezpośrednio odnosi się do bezpieczeństwa systemu, celem argumentacji zaufania jest odpowiedź na pytanie, dlaczego powinniśmy ufać, że argumentacja główny jest wiarygodna. Niektóre standardy i wytyczne, a także niektóre organizacje certyfikujące, wymagają wykazania wprost argumentacji zaufania, czyli spójnego i kompletnego uzasadnienia dla argumentacji głównej.

Punktem początkowym jest zademonstrowanie zaufania w pojedynczym kroku argumentacji. Istnieje kilka sposobów, aby to zrobić. Poniżej przedstawiamy zastosowanie elementów argumentacji typu uzasadnienia. Standard GSN, wersja 3, w sekcji 1:2.2.18 podaje: „Uzasadnienie może być również powiązane ze strategią, aby zapewnić wsparcie dla argumentacji opisanej przez strategię” („A justification can also be connected to a strategy, to provide backing for the argument described by the strategy”). O to właśnie chodzi. Potrzebujemy wyraźnego wsparcia dla kroku wnioskowania argumentacji opisanego przez strategię. Wsparcie powinno mówić, na jakiej podstawie powinniśmy zaufać, że dana argumentacja jest właściwa, działająca dla pełnego wymaganego zakresu, wspierana przez wszystkie wymagane przesłanki, a wszystkie znane problemy i słabości zostały rozwiązane. Aby stworzyć takie wsparcie, rozszerzyliśmy stosowanie elementu typu Uzasadnienia o możliwość jego wsparcia przez argumentację. Umożliwiamy również powiązanie uzasadnień z postulatami zaufania (confidence claims). Takie podejście pozwala na oddzielenie argumentu głównego od argumentu o pewności.

PREMIS rozszerza strukturę argumentacji GSN umożliwiając wsparcie uzasadnienie przez dowolną argumentację. Poniższy diagram przedstawia po lewej stronie prostą argumentację bezpieczeństwa z uzasadnieniem J1, które jest linkiem do postulatu zaufania CC1. Jego struktura argumentacji jest przedstawiona po prawej stronie. Ten przykład ilustruje, jak można zaimplementować argumentację zaufania i jak jest ona powiązana z główną argumentacją bezpieczeństwa.

Assurance case stosowane są nie tylko w fazie rozwoju systemu, ale też jego eksploatacji. Dla wielu systemów stosowane są wtedy wskaźniki bezpieczeństwa – Safety Performance Indicators (SPI). Wskaźniki te służą do monitorowania i oceny poziomu bezpieczeństwa systemu w czasie jego eksploatacji. Pomagają one określić, czy cele bezpieczeństwa są osiągane i dostarczają wczesnych sygnałów ostrzegawczych o pojawiających się zagrożeniach. Są również przydatne w identyfikacji słabych punktów w systemie zarządzania bezpieczeństwem.

Argumentacje bezpieczeństwa systemów nie powinny ignorować SPI, ponieważ są one istotnym źródłem informacji o bezpieczeństwie systemu w trakcie jego eksploatacji. Charakter tych wskaźników jest jednak inny, niż zwykłe dowody w argumentacji assurance case. Wartości wskaźników SPI są zmienne i argumentacja musi być w stanie tę zmienność obsłużyć. Potrzebujemy dynamicznych przypadków zapewnienia bezpieczeństwa, które mogą reagować na zmiany raportowanego SPI.

Silne argumentacje assurance case są tworzone poprzez budowanie zaufania do skuteczności poszczególnych kroków wnioskowania oraz demonstrowanie sposobu rozwiązania znanych słabości i błędów argumentacji. Te dwa podejścia reprezentują dwa różne kierunki argumentacji. Pierwszy koncentruje się na dostarczeniu solidnych podstaw argumentacji, a drugi na jej obronie przed znanymi słabościami i błędami.

Które podejście jest skuteczniejsze i powinno być stosowane? Jawne określenie słabości i błędów argumentacji wydaje się atrakcyjne, ponieważ dostarcza bezpośrednich odpowiedzi na nasze wątpliwości. Kiedy mam uwagę „ale…”, ktoś może wskazać odpowiadający jej fragment argumentacji i przedstawić sposób rozwiązania. W ten sposób argumentacja może rozwiać obawy osób wątpiących. Mogą być oni usatysfakcjonowani, gdy znajdą bezpośrednie odpowiedzi na swoje wątpliwości.