Systemy kosmiczne są rozwijane stosując z zastosowaniem rygorystycznych procesów, w Europie najczęściej zgodnie ze standardami ECSS (European Cooperation for Space Standardization). Standardy te opisują procesy zapewniające kosmiczny wręcz poziom bezpieczeństwa i niezawodności w realizacji misji. Stosowanie assurance case nie jest wprost wymagane przez standardy ECSS, ale w praktyce dla złożonych systemów assurance case jest często stosowany jako element weryfikacji.
Kontekst projektów kosmicznych i standardów ECSS
Zanim przejdziemy do tematu argumentacji dla systemów kosmicznych należy powiedzieć, że procesy związane z takimi systemami są bardzo mocno uporządkowane na wszystkich etapach rozwoju aż do akceptacji do lotu, następnie podczas eksploatacji systemu, która może trwać wiele lat, aż do wycofania z użycia. Stosowane są rygorystyczne zasady zarządzania wymaganiami, testowania, weryfikacji i walidacji, przeglądów. Przeglądy generują zgłoszenia RID (Review Item Discrepancy), których rozwiązanie jest śledzone. Określone są bramki kolejnych faz i określone są precyzyjnie warunki przejścia przez taką bramkę fazy. Mówimy przede wszystkim o standardach ECSS stosowanych w Europie, ale poziom rygorów standardów NASA nie jest niższy. Czy w takich sformalizowanych procesach stosowanie assurance case jest dodatkowym formalizmem, czy przynosi korzyści?
Nie będziemy raczej zalecali stosowania assurance case dla małych projektów typu CubeSat, gdzie poziom złożoności nie jest duży. Ale w większych projektach argumentacja dobrze uzupełnia sam proces rozwoju systemu. Standardy ECSS raczej mówią, co należy zrobić i jakie artefakty wytworzyć. Natomiast assurance case pokazuje, dlaczego można ufać, że system rzeczywiście spełnia wymagane cele. Nie chodzi o to, aby argumentacja była checklistą wymagań standardu, bo wtedy utracimy korzyści jej stosowania. Ma prezentować ciąg logiczny od celów poprzez argumentację i uzasadnienia, aż do dowodów, ale z zachowaniem podejścia określonego przez ECSS.
- Assurance case pomaga identyfikować luki, na przykład brakujące dowody.
- Usprawnia prowadzenie przeglądów. Dla osoby prowadzącej przegląd daje to dobre możliwości przejścia od celów do dokumentów dowodowych.
- Ułatwia określanie zakresu zmian i zarządzanie zmianami.
- Wspiera komunikację między różnymi grupami zaangażowanymi w projekt.
- Dokumentuje decyzje i ich uzasadnienie, co może być użyteczne szczególnie w wieloletnich projektach.
Architektura argumentacji assurance case
W ramach naszych prac wypracowaliśmy architekturę assurance case, która, po niewielkim dostosowaniu, może być stosowana dla różnych systemów, gdzie mają zastosowanie standardy ECSS. Koncentrujemy się na misjach bezzałogowych, bez aspektów misji planetarnych i powrotu na Ziemię.
Architektura jest zorganizowana jako modułowy assurance case. Każdy moduł ma jasno określony cel i zakres odpowiedzialności, w tym przypisanie do standardów ECSS.
- MAC (Mission Assurance Case) integruje wszystkie argumenty niższego poziomu i wspiera decyzje dotyczące fazy cyklu życia. MA (Mission Assurance) pokazuje, że cele misji są osiągalne.
- TA (Technical Assurance) wykazuje, że system posiada wymagane właściwości techniczne i jest podzielony na moduły Bezpieczeństwa (TA1: Safety), Niezawodności (TA2: Dependability), Zapewnienia Oprogramowania (TA3: Software Assurance) oraz Cyberbezpieczeństwa (TA4: Cybersecurity).
- CA pokazuje, dlaczego argumentacja jest wiarygodna i jest podzielone na moduły Weryfikacji i Walidacji (CA1) oraz Zapewnienia Produktu (CA2: Product Assurance).
- OP (Operations) obejmuje cechy systemu w okresie eksploatacji, podczas gdy RG (Risk Governance) dotyczy akceptacji i zarządzania ryzykiem resztkowym.
Diagram modułów poniżej prezentuje wszystkie moduły assurance case. Argumentacja jest przedmiotem prac rozwojowych, ale architektura wydaje się być stabilna.
Diagram sugeruje, że moduły wspierają moduł główny MAC, pozostając od siebie niezależne — jest to jednak tylko uproszczenie wynikające z formy diagramu. Moduły MA/TA/OP współdzielą dowody z modułem RG, który obejmuje całościowe zarządzanie ryzykiem. Powiązanie tych modułów z modułami CA, które można nazywać argumentacją zaufania (confidence argument) odbywa się przez kontrakty, co nie jest pokazane na diagramie.
Ewolucja argumentacji
Moduły ewoluują przez kolejne fazy cyklu życia systemu. Pierwsza faza, czyli faza 0 (Mission Analysis) jest wyjątkowa. W tej fazie celem assurance case nie jest wykazanie, że system spełnia wymagania, lecz wykazanie, że jest możliwa budowa systemu oraz realizacja przez niego celów misji, nie zidentyfikowano nieakceptowalnych ryzyk na poziomie misji oraz nie istnieją istotne bariery techniczne lub operacyjne. Argumentacja ta jest uproszczona w porównaniu do przedstawionej architektury.
Architektura ta ma zastosowanie począwszy od fazy A (Feasibility). W każdej kolejnej fazie argumentacja jest rozszerzana o kolejne grupy dowodów. W fazie A są to głównie analizy wykonalności oraz modele wstępne. W fazie B (Preliminary Definition) są już analizy i projekty inżynierskie, budżety. Faza C (Detailed Definition) obejmuje projektowanie szczegółowe, analizy bezpieczeństwa (FTA, FMECA) oraz przeglądy. Pełna weryfikacja i niezależna ocena jest prowadzona w fazie D (Qualification & Acceptance), która kończy się przeglądem dopuszczającym system do lotu – Flight Acceptance Review (FAR).
W fazie E (Utilisation), która może trwać kilka lat (pomijając krótką podfazę E1 – Launch and Early Orbit Phase) wykorzystywane są dane operacyjne. Celem argumentacji jest utrzymanie pewności realizacji celów misji. W ograniczonym zakresie mogą występować zmiany samego systemu, na przykład aktualizacje oprogramowania.
Podsumowanie
Prezentowana architektura assurance case jest zorientowana na cechy systemu, co odpowiada głównej perspektywie audytorów. Moduły są powiązane, ale mogą być rozwijane w dużym zakresie niezależnie. Posiadają jasno określone zakresy odpowiedzialności i mogą wykorzystywać wspólne dowody poprzez jawne kontrakty lub zależności między modułami. Dzięki temu architektura jest skalowalna oraz umożliwia stopniowe dojrzewanie argumentacji od fazy 0 do fazy F. Jednocześnie wspiera przeglądy realizowane w kolejnych fazach, w tym wspomniany FAR, który jest głównym punktem decyzyjnym dopuszczającym system do lotu.
Architektura argumentacji ewoluuje wraz z kolejnymi fazami rozwoju systemu. Pełny cykl życia takiej argumentacji trwa kilka lat. Omówiliśmy podstawowe założenia tej architektury, ale jest jeszcze wiele istotnych tematów z nią związanych. Będziemy o tym pisać w kolejnych wpisach.
Prezentowana architektura assurance case jest rozwijana w ramach projektu realizowanego wspólnie z Politechniką Gdańską.
Andrzej Wardziński