Oprogramowanie czasu rzeczywistego jest poprawne tylko wtedy, gdy dostarcza właściwy wynik, dla właściwego stanu fizycznego i przed właściwym terminem. Orientacja obliczona bezbłędnie po upływie terminu może być systemowo bezużyteczna. Komenda o dobrym znaku, ale utworzona ze starej próbki, może pogorszyć pętlę. Autentyczny obraz programu uruchomiony z tablicą kalibracyjną innej rewizji sprzętu jest poprawnie podpisany, lecz tworzy błędną konfigurację.
Teza artykułu brzmi: o niezawodności oprogramowania pocisku nie decyduje pojedynczy algorytm ani sam system operacyjny czasu rzeczywistego, lecz zachowanie wspólnego kontraktu czasu, danych, stanu fizycznego i konfiguracji w całym łańcuchu od sensora do efektora. Kwalifikacja ma wykazać zachowanie tego kontraktu w stanach nominalnych, przeciążeniowych, uszkodzeniowych i po resecie.
Pocisk stawia szczególne wymagania: lot jest krótki i niepowtarzalny, start gwałtownie zmienia środowisko, po starcie nie ma interwencji serwisowej, zasoby energii i chłodzenia są ograniczone, a program uruchamia mechanizmy istniejące fizycznie także wtedy, gdy procesor został zresetowany. Oprogramowanie nie steruje abstrakcyjnymi zmiennymi; steruje obiektem, którego czas nie cofa się przy ponownym rozruchu.
granica jawności. Przykłady są syntetyczne i znormalizowane. Pominięto okresy prawdziwych pętli, priorytety, adresy pamięci, protokoły wojskowe, klucze, sekwencje uzbrajania, progi rozpoznawania i sposoby obchodzenia zabezpieczeń. Nie są potrzebne do zrozumienia architektury ani dowodu czasowego.
Kontrakt czasu rzeczywistego ma cztery osie
Każdy interfejs powinien określać co najmniej cztery klasy własności:
| Oś kontraktu | Przykładowe pytanie | Skutek naruszenia |
|---|---|---|
| czas | kiedy powstała próbka, do kiedy wynik ma wartość, jaki jest jitter? | spóźniona lub źle wyrównana komenda |
| dane | jakie są jednostki, osie, zakres, jakość i numer sekwencji? | poprawne obliczenie niewłaściwej wielkości |
| stan fizyczny | w której fazie i przy jakim położeniu mechanizmów obowiązuje wynik? | użycie starego polecenia po zmianie fazy |
| konfiguracja | które sprzęt, firmware, tablice i kalibracje tworzą zestaw? | autentyczny, ale niezgodny obraz |
Klasa czasu nie wynika z nazwy zadania. Wymaganie twarde oznacza, że wynik po terminie jest awarią; wymaganie stanowcze — że spóźniony wynik należy odrzucić, choć pojedyncze pominięcie może być tolerowane; wymaganie miękkie — że jakość stopniowo maleje. Ta sama funkcja może mieć różny kontrakt w różnych fazach.
Wymaganie powinno wskazywać zdarzenie początku, punkt końcowy, najgorszy dopuszczalny czas, jitter, stan systemu, zachowanie po spóźnieniu i sposób obserwacji naruszenia. Średni czas wykonania nie jest takim dowodem.
Od regulatora analogowego do SoC
Wczesne systemy realizowały część sterowania regulatorami analogowymi, przekaźnikami i logiką przewodową. Ich czas wynikał z fizyki obwodów, a zmiana funkcji wymagała zmiany sprzętu. Cyfryzacja wprowadziła cykliczny program wykonawczy: funkcje uruchamiały się w z góry ułożonych ramach, co ułatwiało analizę kolejności, lecz utrudniało obsługę zdarzeń asynchronicznych.
Mikroprocesory i systemy operacyjne czasu rzeczywistego pozwoliły użyć zadań, priorytetów, przerwań i usług komunikacyjnych. Elastyczność zwiększyła liczbę stanów współbieżnych oraz zależność od harmonogramu. FPGA przeniosły wybrane tory o stałej strukturze do równoległej logiki, a współczesne SoC połączyły rdzenie procesorowe, akceleratory, DMA i pamięć współdzieloną. Wydajność wzrosła, ale dowód najgorszego czasu stał się trudniejszy.
Salauyou i współautorzy opisują partycjonowanie sprzęt–oprogramowanie, synchroniczność, automaty stanów, timery i przejście od specyfikacji przez osobne modele do kosymulacji oraz testu fizycznego.2 Bruno i Eschemann pokazują granice CPU–FPGA, interfejsy, DMA i przetwarzanie w SoC.13 Ewolucja nie prowadzi zatem od „prostego” do „bezpiecznego”, lecz od łatwo widocznych zależności do architektur wymagających coraz bardziej jawnego dowodu współbieżności.
Referencyjna architektura i podział odpowiedzialności
Użyteczny układ ma warstwę uruchomienia i inicjalizacji platformy, sterowniki oraz firmware, system wykonawczy, usługi czasu i komunikacji, a nad nimi aplikacje misji. Publiczna architektura NASA core Flight System rozdziela warstwę platformową, abstrakcję systemu operacyjnego, usługi czasu, zdarzeń, tablic i magistrali programowej od aplikacji.1 Nie jest projektem pocisku, lecz daje czytelny przykład kontroli zależności.
W pocisku funkcje można przedstawić jako łańcuch:
$$\text{sensor}\rightarrow\text{akwizycja}\rightarrow\text{estymacja} \rightarrow\text{naprowadzanie}\rightarrow\text{autopilot} \rightarrow\text{sterownik}\rightarrow\text{aktuator}.$$
Równolegle działają zarządzanie fazą, seeker, łącze danych, BIT, FDIR, zasilanie, pamięć i telemetria. Granica komponentu ma sens, jeśli daje własność wymagań, rytmu, danych i uszkodzeń. Nadmierna liczba komponentów dodaje kolejki, kopie i wersje; monolit ułatwia czas, ale pogarsza izolację i niezależne testowanie.
Partycjonowanie CPU–FPGA powinno wynikać z charakteru funkcji. Stały tor znacznikowania lub interfejs o ścisłym rytmie może pasować do logiki, a złożona maszyna stanów i algorytm z tablicami — do procesora. Akcelerator zmniejsza obciążenie CPU, lecz DMA oraz pamięć współdzielona tworzą nowe kanały interferencji. Interfejs musi określać jednostki, czas, reset, atomowość i zgodność wersji.
Czas jest zarówno zasobem, jak i daną
System używa kilku pojęć czasu: licznika sprzętowego, czasu monotonicznego od rozruchu, czasu misji, chwili ważności próbki, chwili odbioru, terminu zadania i czasu telemetrii. Nie wolno ich utożsamiać. Korekta epoki zewnętrznej nie powinna cofać zegara harmonogramu; znacznik po transferze DMA nie jest chwilą fizycznego pomiaru.
Mapowanie zegara lokalnego można przybliżyć:
$$t_{ref}=a+bt_{loc}+\epsilon(t),$$
gdzie $a$ jest przesunięciem, $b$ błędem tempa, a $\epsilon$ resztkową niestabilnością. Utrata zewnętrznego odniesienia powinna prowadzić do trybu podtrzymania z rosnącą niepewnością, nie do skoku wszystkich znaczników.
Próbka potrzebuje wartości, czasu ważności, licznika sekwencji, jednostki, układu odniesienia, jakości, źródła i identyfikatora kalibracji. Flaga valid nie wystarcza: poprawna próbka może być zbyt stara dla bieżącej decyzji. Atomowy snapshot zapobiega zestawieniu połowy starego wektora z połową nowego.
Harmonogram jest równaniem interferencji
Cykliczny program wykonawczy daje jawną kolejność i mały narzut, lecz długie zadanie przesuwa całą ramkę. Harmonogram priorytetowy reaguje elastycznie, ale dodaje wywłaszczenia, blokowanie i odwrócenie priorytetów. Architektura zdarzeniowa pasuje do pakietów i dyskretnych sygnałów, lecz seria zdarzeń może przepełnić kolejkę.
Dla zadań okresowych z priorytetami czas odpowiedzi zadania $i$ można iterować. Poniższy model zakłada priorytety stałe, ograniczony czas blokowania, znane najgorsze czasy wykonania, brak samowstrzymania zadania i ograniczony jitter wydania. Nie opisuje automatycznie architektury wielordzeniowej ani kolejek urządzeń — ich interferencję trzeba najpierw sprowadzić do jawnych składników modelu.
$$R_i^{(n+1)}=C_i+B_i+ \sum_{j\in hp(i)}\left\lceil\frac{R_i^{(n)}+J_j}{T_j}\right\rceil C_j,$$
gdzie $C_i$ jest najgorszym czasem wykonania, $B_i$ blokowaniem, $T_j$ okresem, a $J_j$ ograniczeniem jitteru wydania zadania wyższego priorytetu. Dla $J_j=0$ otrzymujemy prostszą postać bez jitteru. Jeśli iteracja nie osiąga punktu stałego przed terminem, zestaw nie został wykazany jako planowalny w ramach tych założeń.
Rozważmy syntetyczne jednostki czasu: badane zadanie ma $C_i=2$, blokowanie $B_i=1$ i termin 12. Dwa ważniejsze zadania mają pary $(C,T)=(1,4)$ oraz $(2,10)$. Iteracja daje
$$R^{(0)}=3,\quad R^{(1)}=6,\quad R^{(2)}=7,\quad R^{(3)}=7.$$
Nominalne wykonanie trwa 2, lecz systemowy najgorszy czas wynosi 7. Margines do terminu to 5, zanim dodamy przerwania, cache, DMA i interferencję magistrali. To właśnie różnica między pomiarem średniego obciążenia CPU a dowodem czasu odpowiedzi.
Jeżeli pierwsze ważniejsze zadanie ma syntetyczny jitter wydania $J_1=2$, ta sama iteracja stabilizuje się na $R=8$. Jednostkowe zwiększenie wyniku nie jest „karą za RTOS”, lecz skutkiem dodatkowego zdarzenia wyższego priorytetu mieszczącego się w oknie odpowiedzi. Przykład pokazuje zarazem granicę rachunku: wartość $J_1$ musi pochodzić z dowodu źródła zdarzenia i ścieżki wybudzenia, a nie z uznaniowego zapasu.
Przerwania, współbieżność i zasoby wspólne
Procedura przerwania powinna wykonywać minimalną pracę: uchwycić zdarzenie, zabezpieczyć dane i obudzić właściwe zadanie. Długie ISR zwiększa jitter wszystkich funkcji o niższym poziomie maskowania. Burza przerwań wymaga ograniczenia częstości, agregacji i diagnostyki; samo podniesienie priorytetu przenosi problem.
Sekcja krytyczna blokuje zadanie nawet wtedy, gdy procesor ma wolny czas. Protokół dziedziczenia lub pułapu priorytetów ogranicza inwersję, ale musi być uwzględniony w $B_i$. Kolejki mają skończoną pojemność i jawną politykę: odrzucenie najstarszej, odrzucenie nowej, nadpisanie lub przejście w degradację daje inne znaczenie danych.
Wielordzeniowość dodaje kanały interferencji przez cache, pamięć, interconnect, DMA i urządzenia I/O. Raport FAA o procesorach wielordzeniowych w systemach pokładowych podkreśla potrzebę identyfikacji oraz ograniczenia takich kanałów w dowodzie czasowym.3 Dwa zadania na różnych rdzeniach nie są niezależne, jeśli konkurują o wspólny kontroler pamięci.
Studium I: spóźniona próbka od IMU do aktuatora
Prześledźmy syntetyczną próbkę. Sensor znacznikuje ją w chwili 0, transfer DMA kończy się po 0,6 jednostki, kolejka dodaje od 0,2 do 0,8, estymator wykonuje się od 1,0 do 1,6, naprowadzanie od 0,6 do 1,0, autopilot od 0,5 do 0,9, a sterownik aktuatora przyjmuje wynik po kolejnych 0,4. Najgorsza latencja wynosi
$$L_{max}=0{,}6+0{,}8+1{,}6+1{,}0+0{,}9+0{,}4=5{,}3.$$
Jeśli każdy moduł sprawdzono osobno tylko dla wartości typowej, można otrzymać pozorną sumę 3,7. Różnica 1,6 wynika z systemowego złożenia jitteru. Dodatkowo znacznik utworzony po DMA zwiększyłby wiek fizycznej obserwacji o niejawne 0,6.
Załóżmy, że kontrakt końcowy dopuszcza znormalizowany wiek 5,0. Wszystkie funkcje lokalnie kończą pracę, ale komenda jest już spóźniona. Poprawna polityka może odrzucić wynik i użyć jawnie zdefiniowanej predykcji lub degradacji; nie wolno po cichu zastosować starej komendy dlatego, że „pakiet jest valid”.
Dowód end-to-end wymaga wspólnego znacznika, limitów kolejek, czasu najgorszego, interferencji i pomiaru w HIL. Produktem studium jest budżet wieku danych, nie osobne procenty użycia CPU. Zmiana jednego modułu musi zostać oceniona w całym łańcuchu.
Stan misji musi odpowiadać stanowi fizycznemu
Maszyna stanów nie jest tylko zestawem instrukcji if. Jej przejścia mają warunki, akcje wejścia i wyjścia, limit czasu, źródło potwierdzenia i zachowanie po przerwaniu. Niektóre stany fizyczne są nieodwracalne, choć program może się zresetować.
Wpis w pamięci „faza = inicjalizacja” nie dowodzi, że mechanizm wrócił do położenia początkowego. Po restarcie trzeba zrekonstruować czas, zasilanie, pozycje aktuatorów, stan sensorów, ważność kalibracji i to, które polecenia zostały już fizycznie wykonane. Akcja inicjalizacyjna powinna być idempotentna tylko wtedy, gdy jej powtórzenie jest bezpieczne w każdym osiągalnym stanie.
NASA Software Safety Guidebook wiąże bezpieczeństwo programu z komendami, danymi, zasobami, czasem oraz funkcjami, które muszą zadziałać lub nie mogą zadziałać.8 W pocisku szczególną rolę ma relacja cyfrowego stanu do energii i mechanizmów pozostających poza procesorem.
Studium II: ciepły restart podczas lotu
Rozważmy zawieszenie zadania nadzorczego. Watchdog wykrywa brak postępu i resetuje procesor, ale peryferia, FPGA i aktuator nie muszą resetować się w tej samej chwili. Cztery strategie dają odmienne argumenty:
| Strategia | Zaleta | Główne ryzyko | Wymagany dowód |
|---|---|---|---|
| pełny reboot | prosty stan programu | długi brak funkcji, utrata historii | bezpieczne stany wyjść i rekonstrukcja fazy |
| restart usługi | krótsza przerwa | skażony stan współdzielony pozostaje | izolacja pamięci i kontrakt ponownego dołączenia |
| przełączenie na drugi kanał | ciągłość funkcji | wspólny błąd danych lub konfiguracji | niezależność oraz arbitraż |
| stan zdegradowany | ogranicza złożoność | może nie spełniać funkcji misji | jawny zakres zdolności i bezpieczne przejście |
Chronologia dowodu ma kolejność: wykrycie braku postępu, zamrożenie lub ustawienie wyjść, zapis pierwszego błędu, reset wybranej domeny, weryfikacja obrazu i tablic, odtworzenie monotonicznego czasu, rekonstrukcja fazy z niezależnych obserwacji, synchronizacja z FPGA i dopiero wtedy kontrolowane wznowienie.
Schemat nie jest procedurą konkretnego pocisku. Pokazuje niezmiennik, który musi znaleźć odzwierciedlenie w wymaganiach: domena cyfrowa może rozpocząć życie od nowa, podczas gdy czas, energia i położenie mechanizmu zachowują ciągłość. Dlatego źródłem rekonstrukcji powinny być aktualne obserwacje i uzgodnione liczniki, a nie wyłącznie kopia stanu programu sprzed resetu.
Watchdog nie jest recovery. Jeżeli przyczyna leży w tym samym wejściu albo buildzie, restart odtworzy błąd. Jeżeli stan aktuatora jest nieznany, ponowne wysłanie komendy inicjalizacyjnej może być gorsze niż jawna degradacja. Studium kończy się wymaganiem HIL z asynchronicznym resetem domen, a nie deklaracją „system uruchamia się ponownie”.
Sensor, estymator, naprowadzanie i autopilot mają różne kontrakty
Akwizycja odpowiada za próbkę, czas, zakres i stan sensora. Estymator łączy dane o różnych rytmach i tworzy stan z kowariancją. Naprowadzanie formułuje żądanie ruchu na podstawie celu i stanu. Autopilot realizuje je w granicach dynamiki oraz elementów wykonawczych. Złączenie tych funkcji w jednym zadaniu nie usuwa granic semantycznych.
Model wieloczęstotliwościowy musi propagować stan do chwili ważności obserwacji, nie chwili jej przetworzenia. Opóźniony pomiar może wymagać aktualizacji historycznego stanu i ponownej propagacji; proste dołączenie go do bieżącego wektora tworzy błąd czasu.
Kontrakt żądania powinien zawierać jednostki, układ odniesienia, czas, jakość i ograniczenia. Autopilot powinien zwracać także informację o nasyceniu lub utracie zdolności wykonawczej. Anti-windup chroni stan regulatora przed narastaniem podczas nasycenia, a harmonogramowanie parametrów wymaga jawnego źródła zmiennej harmonogramującej i właściwej tablicy.
Seeker i tracker mają zmienny koszt zależny od obrazu. Liczba detekcji lub cech musi mieć ograniczenie, inaczej trudna scena tworzy nieograniczone obciążenie dokładnie w krytycznej chwili. Przeciążenie powinno prowadzić do przewidywalnego zmniejszenia jakości, nie losowego naruszenia terminów stabilizacji.
FDIR ogranicza skutek, nie tylko wykrywa błąd
Usterka (fault) może wytworzyć błędny stan (error), który następnie prowadzi do utraty funkcji (failure). FDIR ma wykryć obserwowalny symptom, odizolować domenę, wybrać reakcję i zachować dowód pierwszej przyczyny. Monitor poza domeną, którą nadzoruje, daje mocniejszy argument niż proces sprawdzający sam siebie.
Obszar izolacji uszkodzeń może obejmować zadanie, partycję, rdzeń, FPGA, sensor lub źródło zasilania. Restart jednej usługi pomaga tylko wtedy, gdy stan wspólny nie został skażony. Redundancja sprzętu nie daje różnorodności wymagań, danych i kompilatora.
Wspólna przyczyna może wejść przed rozdzieleniem kanałów, wewnątrz ich wspólnej infrastruktury albo po ponownym scaleniu wyniku:
| Wspólny element | Jak może unieważnić oba kanały | Dowód mocniejszy niż „są dwa” |
|---|---|---|
| wymaganie lub model | oba kanały realizują tę samą błędną interpretację | niezależna analiza zagrożeń i założeń |
| sensor lub kalibracja | różne procesory dostają ten sam błędny stan świata | zróżnicowane źródło obserwacji albo jawna detekcja niespójności |
| zegar, zasilanie, magistrala | wspólna utrata czasu, energii lub danych | analiza zależności i próba wspólnej awarii |
| kompilator, biblioteka, konfiguracja | ten sam defekt lub niewłaściwy manifest w obu obrazach | kontrola narzędzi, różnorodność tam, gdzie ma uzasadnienie, i test dokładnych binariów |
| arbiter lub aktuator | poprawne kanały tracą skutek w jednym punkcie wykonawczym | monitor końcowego efektu i jawna polityka rozstrzygania |
Architektura 1oo2 może podtrzymać funkcję po utracie jednego kanału, ale zwiększa znaczenie arbitrażu i ryzyko zaakceptowania błędnego kanału. Architektura 2oo2 ogranicza niezamierzone wykonanie, lecz pojedyncza rozbieżność może zatrzymać funkcję. Sam zapis głosowania nie rozstrzyga, który kompromis jest właściwy; wynika on z analizy skutków utraty i niezamierzonego działania. Test należy więc prowadzić także dla wspólnego, wiarygodnego bodźca błędnego oraz usterki infrastruktury, a nie tylko przez wyłączenie jednego procesora.
Reakcje tworzą hierarchię: ponowienie operacji, odrzucenie starej próbki, przełączenie źródła, ograniczenie funkcji, izolacja komponentu, restart domeny lub stan bezpieczny. Każda ma koszt czasowy i wpływ na sterowanie. Polityka FDIR jest częścią dynamiki systemu, dlatego musi być testowana z rzeczywistym obiektem lub reprezentatywnym HIL.
Arytmetyka, pamięć i platforma są częścią wyniku
Arytmetyka stałoprzecinkowa wymaga skalowania, analizy przepełnienia i zaokrąglenia. Zmiennoprzecinkowa ma NaN, nieskończoności, denormale i zależność od ustawień jednostki. Typy reprezentujące jednostki i układy odniesienia mogą przenieść część błędów z testu do kompilacji, ale nie zastępują wymagań zakresu.
Pamięć dynamiczna po inicjalizacji utrudnia dowód czasu i fragmentacji. Stosy potrzebują analizy ścieżek, przerwań i marginesu. ECC koryguje określone klasy błędów, ale wymaga monitoringu, polityki dla błędu niekorygowalnego i kontroli wspólnego źródła. Scrubbing zużywa magistralę i wchodzi do analizy interferencji.
DMA może zapisywać bufor równolegle z CPU. Potrzebne są bariery pamięci, własność bufora, atomowe przełączenie i kontrola koherencji. Błąd nie zawsze pojawia się w kodzie aplikacji; może wynikać z nieudokumentowanej kolejności sterownika, FPGA i cache.
Łańcuch uruchomienia chroni autentyczność, nie przydatność
Od niezmiennego korzenia zaufania przez bootloader, firmware, FPGA i aplikację każda warstwa powinna weryfikować następną oraz wiązać pomiar z identyfikatorem konfiguracji. NIST SP 800-193 porządkuje odporność firmware przez funkcje ochrony, wykrywania i odtwarzania.4 W systemie wbudowanym wymaga to dopasowania do braku sieci, ograniczonej pamięci i fizycznych stanów urządzeń.
Podpis odpowiada na pytanie, czy bity pochodzą od uznanego wydawcy i nie zostały zmienione. Nie odpowiada, czy wersja jest właściwa dla rewizji płytki, sensora, tablicy ani misji. Manifest zgodności powinien wiązać obraz z hardware'em, firmware'em, danymi i dopuszczoną ścieżką aktualizacji.
GAO wykazywało, że podatności systemów uzbrojenia bywają wykrywane późno, a same deklaracje kontroli i niepełne testy nie dają wystarczającego dowodu.5 Późniejszy raport wskazał znaczenie jednoznacznych wymagań kontraktowych i kryteriów akceptacji cyberbezpieczeństwa.6 Ochrona musi więc obejmować development, build, provisioning, stanowiska testowe, debug, depot i utrzymanie, nie tylko boot.
Studium III: autentyczny, lecz niewłaściwy obraz
Załóżmy dwie rewizje sprzętu: H1 i H2. Obraz S2 jest poprawnie podpisany, ale przeznaczony dla H2 i tablicy kalibracji K2. Wskutek błędu logistycznego trafia na H1 z K1. Secure boot akceptuje podpis; program startuje. Błąd pojawia się dopiero wtedy, gdy sterownik interpretuje inną skalę sensora lub mapę wyjść.
Łańcuch ochronny musi sprawdzić jednocześnie:
$$\text{autentyczność}\land\text{integralność}\land \text{zgodność}\land\text{dopuszczalną świeżość}\land \text{atomową aktywację}.$$
Manifest powinien zawierać dopuszczone pary H–S–K, wersję FPGA, identyfikator platformy i zakres obowiązywania. Anti-rollback zapobiega wgraniu autentycznej, lecz niedopuszczonej wersji starej. Aktualizacja obrazu i tablic musi być transakcją: albo aktywuje się cały zestaw, albo poprzedni zestaw pozostaje uruchamialny. Rekord as-loaded zapisuje to, co rzeczywiście znalazło się w egzemplarzu, nie tylko plan wydania.
Test regresji musi uruchomić dokładny zestaw na reprezentatywnym HIL i sprawdzić interfejsy oraz czas. Studium pokazuje, dlaczego „podpis prawidłowy” i „testy S2 przeszły” nie wystarczają bez konfiguracji H2/K2. Porównawcze zasady obrony warstwowej, separacji funkcji bezpieczeństwa i zarządzania zmianą omawiają Bouhdada i Ayala dla systemów przemysłowych; transfer do pocisku wymaga własnego modelu zagrożeń.14
Wymagania i assurance tworzą ślad dwukierunkowy
Wymaganie powinno być testowalne, jednoznaczne i przypisane do stanu, interfejsu oraz konfiguracji. Ślad dwukierunkowy łączy wymagania i zagrożenia z architekturą, kodem, testami, wynikami oraz niezgodnościami. NASA Software Engineering Handbook opisuje taki ślad jako podstawę oceny pokrycia i wpływu zmian.10
Assurance nie jest końcowym audytem dokumentów. NASA-STD-8739.8B wiąże zapewnienie jakości oprogramowania, bezpieczeństwo i IV&V z całym cyklem życia.9 Niezależność powinna być proporcjonalna do krytyczności i obejmować możliwość zakwestionowania założeń, a nie tylko ponowne uruchomienie tych samych testów.
FAA AC 20-115D dotyczy oprogramowania lotnictwa cywilnego i nie jest normą pocisku, ale pokazuje dojrzałą zasadę: poziom dowodu wynika z konsekwencji awarii, a zgodność wymaga kontrolowanego procesu oraz obiektywnych danych.7 W programie wojskowym właściwe kryteria muszą pochodzić z jego własnych wymagań i akceptacji ryzyka.
Piramida testów musi zachować prawdziwy czas i konfigurację
Test jednostkowy na komputerze gospodarza szybko sprawdza logikę. SIL łączy moduły z symulacją, lecz nie odwzorowuje timerów, DMA i cache. Test na docelowym procesorze sprawdza kompilator i platformę. HIL zamyka pętlę z rzeczywistymi I/O, opóźnieniami i modelem fizycznym. Próby zintegrowane oraz lotne sprawdzają sprzężenia, których wcześniejsze poziomy nie odtwarzają.
NASA Handbook SWE-066 rozdziela testy oparte na wymaganiach od pokrycia strukturalnego i wskazuje, że samo wykonanie kodu nie dowodzi kompletności testu.11 Sto procent wybranego pokrycia nie wykryje brakującego wymagania ani błędnego orakla. Kod martwy i kod wyłączony przez konfigurację wymagają odmiennego uzasadnienia.
Próby odporności powinny obejmować przeciążenie, utratę i duplikację danych, zmianę kolejności, błędne jednostki, reset domeny, uszkodzenie pamięci i przerwę czasu. Test czasu uruchamia najgorszą kombinację dróg, przerwań i zasobów, a pomiar ma jawny punkt początku i końca. Średnie obciążenie CPU z nominalnego scenariusza nie zastępuje tego dowodu.
Kwalifikacja dotyczy dokładnego obrazu na dokładnym sprzęcie
Kwalifikacja oprogramowania lotnego łączy V&V, analizę bezpieczeństwa, przeglądy, testy, zarządzanie konfiguracją, niezgodności i ocenę pozostałego ryzyka. NASA Software Engineering Handbook opisuje ją jako całość dowodów, nie pojedynczy udany lot.12
Identyfikator wydania powinien wiązać kod źródłowy, zależności, narzędzia, opcje kompilacji, obraz wykonywalny, firmware, FPGA, tablice, kalibracje, sprzęt i wyniki testów. Niezależny build oraz kontrola załadowania wykazują, że badano te same bity, które dopuszczono.
Zmiana tablicy jest zmianą wykonywalnego zachowania nawet bez zmiany kodu. Zmiana kompilatora, procesora lub arbitra pamięci może zmienić czas. Ocena wpływu prowadzi od różnicy przez wymagania i zagrożenia do testów regresji. Utrzymanie przez lata wymaga inwentarza zależności, pochodzenia builda, kontroli wycofanych kluczy, narzędzi i stanowisk.
Synteza: dowód przebiega od sensora do efektora
Oprogramowanie pocisku jest systemem kontraktów. Czas określa, czy informacja nadal opisuje bieżący świat. Dane określają jednostki, osie i jakość. Maszyna stanów wiąże program ze stanem fizycznym. Konfiguracja wiąże obraz z hardware'em, firmware'em i tablicami. Naruszenie jednej osi może unieważnić lokalnie poprawne wyniki pozostałych.
Trzy studia pokazują ten mechanizm. W pierwszym każdy moduł mieścił się w lokalnym czasie, ale suma najgorszych opóźnień przekroczyła kontrakt wieku próbki. W drugim restart procesora nie cofnął mechanizmów i wymagał rekonstrukcji fazy przed wznowieniem. W trzecim podpis kryptograficzny potwierdził autentyczność obrazu, lecz dopiero manifest H–S–K potwierdził jego przydatność.
Najważniejsze pytanie nie brzmi więc „czy RTOS jest szybki?” ani „czy software przeszedł testy?”, lecz: czy dokładny obraz, na dokładnym sprzęcie i z dokładnymi danymi, zachowuje end-to-end kontrakt czasu, stanu i bezpieczeństwa we wszystkich wymaganych warunkach — oraz jaki odtwarzalny dowód to potwierdza?