2025 - Argevide

Uwzględnianie ograniczeń systemu w assurance case (SOTIF)

Andrzej Wardziński — Thu, 20 Nov 2025 13:57:48 +0000

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.

Artykuł Uwzględnianie ograniczeń systemu w assurance case (SOTIF) pochodzi z serwisu Argevide.

LTAC – Prosty tekstowy format opisu assurance case

Andrzej Wardziński — Thu, 30 Oct 2025 04:41:46 +0000

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?

- Claim G1: System is acceptably safe to operate
  - Context C1: System Definition
  - Strategy S1: Argue by mitigating all hazards
    - Claim G2: All  hazards have been identified
      - Evidence E1: Hazard analysis report
    - Claim G3: All identified hazards have been mitigated
      - Strategy S3: Decompose mitigation argument by identified hazards
        - Claim S5: All identified hazards have been accurately assessed
        - Claim S6: Mitigation strategies have been implemented for all hazards
        - Claim S7: The effectiveness of the mitigation measures has been validated
    - Claim S4: Continuous monitoring of risks is in place

Powyższy fragment argumentacji jest zrozumiały dla człowieka i to jest bardzo ważne. Można łatwo taką argumentację przeglądać i modyfikować w razie potrzeby.

Gdy argumentacja ta zostanie wklejona do PREMIS, otrzymujemy diagram GSN jak poniżej.

Argumentacja LTAC może być tworzona ręcznie, ale też z użyciem narzędzi AI lub skryptów. Jeżeli chcesz stosować narzędzie AI, to najpierw podaj instrukcję, aby stosować notację LTAC zgodnie ze specyfikacją LTAC. Gdy narzędzie AI pozna notację LTAC, może bez problemu tworzyć i analizować takie argumentacje.

Gdy argumentacja jest większa, to taka forma tekstowa staje się już trudniejsza do przeglądu przez człowieka. Tym niemniej fragmenty argumentacji w LTAC są ciągle łatwe do stosowania.

Jest też jeszcze jedno poważne ograniczenie LTAC. Taka tekstowa argumentacja jest skutecznym rozwiązaniem, gdy nie ma opisów elementów argumentacji lub metadanych takich jak oznaczenie ‘undeveloped’ lub tagi. W takim wypadku można stosować bardziej zaawansowane notacje tekstowe, w tym stosujące YAML. Jednak, gdy dane pojedynczego elementu argumentacji są bardziej złożone i nie są prezentowane w jednym wierszu, stają się trudniejsze do ręcznej analizy.

LTAC jest skutecznym rozwiązaniem gdy stosujesz narzędzia AI, a jednocześnie chcesz przeglądać i korygować argumentację przed wstawieniem do narzędzia assurance case.

Artykuł LTAC – Prosty tekstowy format opisu assurance case pochodzi z serwisu Argevide.

Stosowanie argumentacji zaufania w assurance case

Andrzej Wardziński — Tue, 21 Oct 2025 12:06:59 +0000

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.

To podejście można zastosować zarówno do poszczególnych kroków argumentacji, jak i do przypadków pełnego zapewnienia bezpieczeństwa.

Argument główny stwierdza, że osiągnięto akceptowalny poziom bezpieczeństwa systemu. Każde stwierdzenie w tym argumencie przyczynia się do osiągnięcia bezpieczeństwa systemu.
Argument pewności powinien uzasadniać, że każdy krok argumentacji argumentu głównego jest prawidłowy. Nie przyczynia się to bezpośrednio do bezpieczeństwa systemu, ale jest wymagane, aby zaufać głównemu argumentowi bezpieczeństwa. Jeśli nie możemy przedstawić przekonującego argumentu pewności dla danego kroku argumentu głównego, nie możemy ufać jego poprawności.

Przykład argumentacji bezpieczeństwa i wiarygodności procesu

Poniższy diagram mapy argumentacji przedstawia to zastosowanie opisywanego podejścia dla prostego przykładu assurance case. Mapa argumentacji pokazuje strony diagramów sekcji argumentacji. Dla każdej strony podana jest nazwa głównego postulatu danej strony. Lewa część diagramu zawiera główną argumentację bezpieczeństwa, a argumentacja zaufania jest wyświetlana po prawej stronie. Pełna argumentacja tego assurance case jest dostępna online w systemie PREMIS pod poniższym linkiem.

Przedstawiona tutaj argumentacja zaufania zawiera zaledwie pięć postulatów, co jednak wystarcza do zademonstrowania jej struktury. Powinna być tworzona bezpośrednio w oparciu o proces rozwoju systemu lub jego cykl życia. Argumentacja zaufania powinna być z jednej strony spójna z procesem rozwoju, a jednocześnie zachowywać spójność ze strukturą głównej argumentacji bezpieczeństwa. Dla każdego kroku głównej argumentacji należy przedstawić odpowiadającą mu argumentacje zaufania. W praktyce będą istnieć setki postulatów zaufania oraz linków do argumentacji bezpieczeństwa. Chociaż zastosowanie bramek jakości i innych punktów kontrolnych wdrożonych w procesie zapewnienia bezpieczeństwa może uprościć powiązanie tych dwóch argumentacji, to cały czas argumentacja zaufania musi pokrywać swoim zasięgiem wszystkie wymagania odpowiednich standardów w zakresie procesu rozwoju systemu.

To podejście można rozszerzyć o stosowanie dodatkowych warstwy argumentacji. Na przykład w wytycznych MISRA dotyczących argumentacji bezpieczeństwa w motoryzacji zaproponowano kolejną warstwę argumentacji o nazwie „Środowisko organizacyjne”, która powinna zawierać argumentacje wykazującą, że wszystkie działania w cyklu życia systemu są wykonywane przez organizację w odpowiednim środowisku, obejmującym między innymi system zarządzania jakością (SZJ), proces ciągłego doskonalenia i odpowiednie kwalifikacje zespołu.

Podział warstw argumentacji poprzez stosowanie oddzielnych gałęzi lub modułów argumentacji może ułatwić zarządzanie dużymi assurance case podczas rozwoju, przeglądów i utrzymania systemów. Relacje między główną argumentacją a warstwami argumentacji zaufania są łatwe do utrzymania w systemie PREMIS, gdy struktura argumentacji głównej jest spójna z procesem rozwoju systemu.

Artykuł Stosowanie argumentacji zaufania w assurance case pochodzi z serwisu Argevide.

Szablony assurance case bazujące na modelach

Andrzej Wardziński — Tue, 21 Jan 2025 20:29:31 +0000

Pracujemy nad rozszerzeniem wzorców GSN o powiązania do modeli kontekstowych systemu. Wzorce GSN obejmują abstrakcję argumentacji, ale szczegóły jak ona działa nie są dokładnie opisane. Można zdefiniować postulat „{System S} jest wystarczająco bezpieczny”, ale Standard GSN nie powie, w jaki sposób zarządzać parametrem S. Można znaleźć publikacje, jak argumentacje bazujące na modelach mogą działać dla SACM, ale nie ma takich informacji w Standardzie GSN.

Pracujemy nad rozwiązaniem umożliwiającym systematyczne odwołania szablonów argumentacji do modeli systemu z zapewnieniem spójności dla modularnego assurance case. Budujemy to jako rozszerzenie parametrów szablonów argumentacji proponowane w Standardzie GSN.

Poniższy rysunek przedstawia szablon w stylu GSN po lewej stronie i odpowiadający mu szablon oparty na modelu po prawej stronie. Można zauważyć kilka różnic między tymi dwoma szablonami.

Szablon oparty na modelu określa warunek, że G3 jest tworzony tylko wtedy, gdy atrybut contracts w C nie jest pusty, gdzie C jest typu Component. Ten formalny warunek odpowiada opisowi tekstowemu opcjonalnej instancji w szablonie GSN.
Zamiast czarnego koła dla wielokrotnej instancji we wzorcu GSN, wzorzec oparty na modelu określa, że G9 powinien być tworzony dla każdego K, które należy do atrybutu contracts w C.

Warunki określone w takim szablonie będą działać z System Assurance Reference Model (SARM), który opisuje cały kontekst assurance case. Może to obejmować modele architektury systemu, modele ryzyka (zagrożenia, zagrożenia itp.), środowisko, warunki operacyjne, procesy cyklu życia i inne istotne czynniki.

Podejście jest opisane w naszym artykule „Automated Generation of Modular Assurance Cases with the System Assurance Reference Model” opublikowanym w grudniu w the ACM Journal Formal Aspects of Computing (https://dl.acm.org/doi/10.1145/3685936)

Obecnie prowadzimy eksperymenty z prototypowym narzędziem, które generuje modularne assurance case na podstawie szablonów odwołujących się do modeli kontekstowych. Generowane są pliki XML definiujące assurance case, które są następne importowane do PREMIS. Prowadzimy testy generowania argumentacji, a w kolejnym etapie naszego projektu będziemy pracować nad aktualizowaniem assurance case dla zmian w modelach systemu.

Jeżeli jesteś zainteresowany takim podejściem do stosowania szablonów assurance case, chętnie przedstawimy nasze podejście i sprawdzimy, czy będzie też skuteczne dla Twoich szablonów.

Artykuł Szablony assurance case bazujące na modelach pochodzi z serwisu Argevide.