Udany lot prototypu nie dowodzi jeszcze, że powstał właściwy system wojskowy. Wynik może dotyczyć innej konfiguracji, łatwiejszego środowiska albo tylko części funkcji. Z drugiej strony doskonale sformułowana specyfikacja nie ma wartości, jeśli nie prowadzi do architektury i obiektywnego dowodu dostarczonego wyrobu. Inżynieria wymagań łączy oba kierunki.

Teza artykułu brzmi: zgodność systemu nie jest sumą zaliczonych prób, lecz kontrolowanym, dwukierunkowym argumentem łączącym zwalidowaną potrzebę z wymaganiami, architekturą, konfiguracją wyrobu i dowodami o jawnie określonej ważności oraz niepewności. W dół biegnie intencja: potrzeba → wymaganie → architektura → projekt. W górę biegnie dowód: konfiguracja wykonana → wynik → zweryfikowane wymaganie → zwalidowana potrzeba. Pętle analizy, prób i zmian łączą oba kierunki przez cały cykl życia.

granica bezpieczeństwa. Przykłady są neutralne lub znormalizowane. Tekst nie podaje wymagań, tolerancji, profili misji, kryteriów prób ani konfiguracji konkretnego współczesnego systemu uzbrojenia. Metody służą zarządzaniu znaczeniem i dowodem, nie optymalizacji efektora.

Ostrzeżenie EOD: żądanie „zdobycia dowodu” nie upoważnia do zasilania nieznanego sprzętu, zwierania obwodów, wymuszania stanu ani obchodzenia blokad. Próby urządzeń energetycznych i uzbrojenia prowadzą wyłącznie uprawnione zespoły w zatwierdzonych obiektach. Niepewna konfiguracja albo stan bezpieczny wstrzymują próbę.

Od potrzeby do mierzalnego wymagania

Pięć artefaktów nie może zostać zredukowanych do jednego zdania

Potrzeba opisuje problem lub pożądany skutek dla użytkownika. Wymaganie jest normatywną własnością, którą system albo jego element ma spełnić. Decyzja projektowa wybiera sposób spełnienia. Twierdzenie zgodności mówi, że określona konfiguracja spełnia wymaganie w określonym zakresie. Dowód jest wynikiem analizy, inspekcji, demonstracji lub próby, który wspiera to twierdzenie.

Mieszanie artefaktów tworzy ukryte błędy. Zdanie „system ma używać sensora X” może być decyzją podszywającą się pod potrzebę. „Próba zakończona powodzeniem” może nie wskazywać wymagania ani kryterium. „Zgodne z normą” nie identyfikuje własności egzemplarza. Samo słowo shall nie zmienia propozycji rozwiązania w dobre wymaganie.

Każdy artefakt potrzebuje właściciela, źródła, wersji i relacji. Potrzebę zatwierdza właściwy interesariusz. Wymaganie ma podmiot odpowiedzialny. Decyzja ma uzasadnienie oraz odrzucone alternatywy. Twierdzenie ma zakres i założenia. Dowód ma rodowód danych, konfigurację oraz kryterium. NASA Systems Engineering Handbook porządkuje ten przepływ od oczekiwań interesariuszy przez projekt systemu do realizacji produktu i zarządzania technicznego.3

Słownik używany w dalszej części jest celowo wąski:

Termin główny Znaczenie w artykule Czego nie oznacza
sprawa zapewnienia (assurance case) uporządkowane twierdzenia, argumenty, dowody, założenia i obalacze samego segregatora raportów
macierz zgodności i weryfikacji wymagań (VCRM/RVM) rekord łączący wymaganie, intencję, metodę, konfigurację, wynik i decyzję listy PASS/FAIL bez rodowodu
zakres obowiązywania (effectivity) populacja wersji, partii lub egzemplarzy, dla których decyzja jest ważna ogólnej ważności dla „podobnych” wyrobów
rodowód obiektu próbnego (test article pedigree) udokumentowana tożsamość, wykonanie, historia, wyposażenie i stan obiektu samego numeru części
weryfikacja dowód zgodności z określoną podstawą wymagań potwierdzenia, że wybrano właściwą potrzebę
walidacja potwierdzenie właściwej potrzeby lub przydatności w kontekście ponownego wykonania tej samej weryfikacji

Granica systemu obejmuje produkty umożliwiające

Systemem nie jest tylko pocisk. Kontekst może obejmować platformę, wyrzutnię, sensory, dowodzenie, interfejsy, dane, oprogramowanie, personel, szkolenie, transport, obsługę, aparaturę naziemną, stanowiska, części zamienne i wycofanie. Elementy te są produktami umożliwiającymi (enabling products), ponieważ bez nich wyrób końcowy nie uzyskuje albo nie utrzymuje zdolności.

Diagram kontekstu pokazuje aktorów i sąsiednie systemy oraz przepływy energii, materii, informacji i uprawnień. Każda strzałka przez granicę powinna prowadzić do kontraktu interfejsowego. Brak strzałki często oznacza przeoczone wymaganie, nie brak rzeczywistego oddziaływania.

Koncepcja użycia (ConOps) opisuje role, fazy, warunki nominalne, degradacje i cel operacyjny bez stawania się instrukcją wykonawczą. Wątek misji (mission thread) prowadzi konkretny przypadek od potrzeby i przygotowania przez decyzję, współdziałanie podsystemów, efekt oraz odtworzenie gotowości. Na każdym kroku wskazuje wejście, wyjście, jakość, czas i właściciela decyzji.

Dodatek do podręcznika NASA wymaga, aby plan V&V identyfikował architekturę, elementy końcowe, wyposażenie wsparcia i obiekty potrzebne do uzyskania dowodu.5 Jest to użyteczna zasada ponad domenami: próba elementu bez rzeczywistego kontekstu może zweryfikować część, a nie system.

Potrzeba musi zostać zwalidowana przed optymalizacją rozwiązania

Walidacja potrzeby pyta: czy rozwiązujemy właściwy problem dla rzeczywistego użytkownika i środowiska? Interesariuszami są nie tylko operator i dowódca. Należą do nich obsługa, logistyk, integrator platformy, właściciel bezpieczeństwa, cyberbezpieczeństwo, producent, jednostka próbna i organizacja wycofująca. Ich oczekiwania mogą być sprzeczne.

Przykładowo użytkownik chce krótkiego czasu reakcji, obsługa — szerokiej diagnostyki, bezpieczeństwo — dodatkowych blokad, a platforma — ograniczonego poboru mocy. Żadne z tych żądań nie staje się automatycznie wymaganiem systemowym. Zespół najpierw ustala scenariusz, źródło, priorytet, konflikt i kryterium wartości.

Zbyt wczesne wpisanie rozwiązania do potrzeby zamyka przestrzeń alternatyw. „Potrzebny jest konkretny typ sensora” może ukrywać właściwy cel: dostarczenie informacji o określonej jakości i czasie. Jeżeli wskazany sensor jest rzeczywistym ograniczeniem interoperacyjności albo dostawy, należy zapisać go jako ograniczenie wraz z uzasadnieniem, a nie przedstawiać jako naturalne prawo.

GAO, analizując programy uzbrojenia, wiąże wykonanie szczegółowej inżynierii systemowej przed rozwojem produktu z dojrzalszymi wymaganiami i liniami bazowymi.11 Badanie dziewięciu przypadków nie jest uniwersalnym prawem, ale dobrze ilustruje koszt rozpoczynania konstrukcji przed rozstrzygnięciem potrzeby i architektury.

MOE, MOP i TPM łączą wartość operacyjną z parametrem technicznym

Miara efektywności (MOE) pyta, czy zdolność tworzy wartość w scenariuszu użytkownika. Miara osiągów (MOP) opisuje techniczną cechę systemu lub elementu: opóźnienie, dokładność, przepustowość, pobór mocy albo niezawodność. Techniczna miara postępu (TPM) śledzi, jak prognozowana i mierzona wartość dojrzewa względem planu oraz progów decyzji.

Relacja nie jest zwykle jeden do jednego. Jedna MOE może zależeć od kilku MOP różnych podsystemów, a ta sama MOP może wspierać kilka scenariuszy. Model powinien pokazać kierunek wpływu i niepewność. Laboratoryjna dokładność sensora nie staje się MOE bez uwzględnienia opóźnienia, fuzji, łącza, decyzji i reakcji efektora.

TPM ma wartość, jeśli zawiera planowaną trajektorię, aktualny pomiar, prognozę, niepewność i właściciela reakcji. Zielony wskaźnik bez błędu pomiaru albo prognoza bez wersji modelu są dekoracją. NPR 7123.1C wymaga ustanowienia mierników pokazujących bieżący stan w odniesieniu do planu oraz łączy je z procesami technicznymi i przeglądami.4

Dobre wymaganie jest jedną sprawdzalną obligacją

Użyteczny wzorzec brzmi:

[podmiot] shall [wykonać jedną funkcję lub posiadać cechę] [w zdefiniowanych warunkach] [z mierzalnym kryterium].

Źródło, uzasadnienie, priorytet, metoda weryfikacji, właściciel i notatki są atrybutami rekordu, a nie dodatkowymi zdaniami upchniętymi w części normatywnej. MIL-STD-961 porządkuje format specyfikacji obronnych i pomaga odróżnić wymagania produktu od opisu pracy wykonawcy.6

Wymaganie powinno być konieczne, pojedyncze, jednoznaczne, kompletne, spójne, wykonalne, mierzalne, weryfikowalne, identyfikowalne i pod kontrolą konfiguracji. DoD Systems Engineering Guidebook wykorzystuje ten zestaw cech w procesie analizy wymagań, wiążąc go z potrzebami interesariuszy, architekturą i V&V.2 „System shall transmit data quickly and reliably” łączy co najmniej funkcję, czas oraz niezawodność, nie podaje odbiorcy, warunków ani jednostek. Podział na rekordy ułatwia niezależne kryteria, lecz nie może zgubić wspólnego warunku.

Słowa „odpowiednio”, „minimalizować”, „standardowo”, „w razie potrzeby” i „tak szybko, jak możliwe” ukrywają decyzję. Wymaganie powinno zawierać mierzalny próg albo odwołanie do kontrolowanej definicji. Wartość aspiracyjna, cel projektowy i minimalny próg zgodności są różnymi atrybutami.

NPR 7123.1C opisuje wymagania techniczne jako unikalne, ilościowe i mierzalne stwierdzenia shall oraz wymaga ich walidacji i śledzenia do potrzeb wyższego poziomu.4 Słowo normatywne jest zatem końcem analizy znaczenia, nie jej substytutem.

Wymaganie weryfikacyjne nie jest procedurą próby

Trzeba rozdzielić pięć pojęć. Intencja weryfikacji mówi, jaką własność należy obiektywnie wykazać. Metoda wybiera analizę, inspekcję, demonstrację albo próbę. Kryterium sukcesu wyznacza granicę decyzji. Procedura opisuje kontrolowane wykonanie. Rekord macierzy weryfikacji wiąże wymaganie z metodą, poziomem, konfiguracją, odpowiedzialnością oraz wynikiem.

Wymaganie dotyczące procesu może nakazać wykonanie określonego przeglądu albo raportu. Nie należy go mylić z technicznym wymaganiem produktu ani z intencją jego weryfikacji. Jeśli zespół nie umie zaproponować obiektywnego kryterium dla zdania produktowego, treść wymagania prawdopodobnie nie jest jeszcze dojrzała.

Procedura jest niższym poziomem i może się zmieniać bez zmiany wymagania, o ile zachowuje intencję, reprezentatywność i kryterium. Z kolei zmiana kryterium po poznaniu wyniku jest zmianą podstawy zgodności, nie redakcją raportu.

Dekompozycja wymaga dowodu wystarczalności

Śledzenie w dół pokazuje, gdzie wymaganie nadrzędne zostało przydzielone. Nie dowodzi, że zbiór wymagań niższych jest łącznie wystarczający. Potrzebny jest argument architektoniczny: funkcje, przepływy, budżety, marginesy i założenia muszą składać się z powrotem we własność wyższego poziomu.

Jeżeli całkowite opóźnienie ma ograniczenie $L_{max}$, alokację można zapisać

$$L_{tot}=L_1+L_2+\ldots+L_n+L_{int}+L_{unc}\le L_{max},$$

gdzie $L_{int}$ obejmuje narzut integracji, a $L_{unc}$ rezerwę na niepewność i niedojrzałość. Samo nadanie każdemu podsystemowi lokalnego limitu nie wystarcza. Trzeba wykazać, że definicje początku i końca, tryb pracy, percentyl oraz wspólny zegar są zgodne.

Wymaganie pochodne (derived requirement) powstaje z analizy, architektury, fizyki albo hazardu. Musi mieć źródło w modelu i właściciela zatwierdzającego. Anonimowe wymaganie pochodne jest szczególnie ryzykowne: może być niezbędnym warunkiem albo przypadkową decyzją projektanta bez autoryzacji.

Kompletność dekompozycji bada się dwukierunkowo. W dół każde zobowiązanie wyższego poziomu ma realizację. W górę każde zobowiązanie niższego poziomu ma potrzebę, interfejs, hazard albo uzasadnioną decyzję. Rekordy osierocone i cele bez pokrycia są dwiema różnymi klasami luki.

Formalnie zbiór wymagań potomnych $C_i$ oraz jawnych założeń interfejsowych $A_j$ jest wystarczający dla wymagania nadrzędnego $R$ tylko wtedy, gdy

$$\left(\bigwedge_i C_i\right)\land \left(\bigwedge_j A_j\right)\Rightarrow R.$$

Same krawędzie R → C1, C2, C3 w bazie śledzenia nie dowodzą tej implikacji. Weźmy neutralne wymaganie: „odebrany pakiet jest aktualny, ma określoną jakość i ważny znacznik integralności”. Lokalnie sensor może spełnić limit tworzenia danych, łącze — limit transportu, a odbiornik — limit przetwarzania. Wszystkie trzy rekordy przejdą weryfikację, lecz wymaganie nadrzędne nadal może być fałszywe, jeżeli znaczniki czasu pochodzą z niespójnych epok albo jakość zmienia definicję na granicy interfejsu.

Kontrprzykład ujawnia dwa brakujące założenia: wspólną podstawę czasu oraz zachowanie semantyki jakości. Jeśli są konieczne w każdej realizacji, powinny zostać przekształcone w kontrolowane wymagania pochodne, a nie pozostać przypisem do modelu. Dowód wystarczalności polega więc także na szukaniu modelu, w którym wszystkie dzieci są prawdziwe, a rodzic fałszywy. Znalezienie takiego modelu jest wartościowym wynikiem analizy, nie porażką testu.

Architektura alokuje także odpowiedzialność za dowód

Architektura funkcjonalna mówi, co musi się wydarzyć i jakie informacje lub energie przepływają. Architektura fizyczna przypisuje funkcje elementom. Alokacja wymagania powinna równocześnie wskazać właściciela implementacji, modelu i dowodu. Jeżeli funkcja przecina sprzęt, FPGA i oprogramowanie, jeden zespół musi odpowiadać za wynik na granicy systemowej.

Interfejs nie jest tylko złączem. Obejmuje geometrię, układ odniesienia, masę, obciążenie, moc, jakość zasilania, sygnał, semantykę danych, czas, tryby, stany błędne, wersję i odpowiedzialność. Dokument interfejsu (ICD) powinien być uzgodniony po obu stronach. Jednostronny rysunek wyprowadzeń nie dowodzi wspólnego znaczenia.

Spójność architektury można sprawdzać przez wątki prowadzone od początku do końca. Dla każdego zdarzenia należy przejść od sensora przez przetwarzanie, decyzję, interfejs i wykonanie, uwzględniając utratę danych oraz zasilania. Wątek wyłania wymagania na czasy, jakość, stan po błędzie, diagnostykę i konfigurację, których nie widać w osobnych specyfikacjach części.

ECSS-E-ST-10C Rev.1 łączy model klient–system–dostawca, drzewa funkcji i specyfikacji, budżety techniczne, macierz śledzenia i plik uzasadnień.10 Jest standardem domeny kosmicznej, więc wymaga dostosowania, ale dobrze pokazuje, że alokacja oraz justification file są dwoma stronami tej samej decyzji.

Budżet, margines i niepewność muszą pozostać rozdzielone

Budżet rozdziela wspólny limit pomiędzy elementy. Margines jest kontrolowaną różnicą pomiędzy przydziałem a prognozowanym lub zmierzonym użyciem. Rezerwa zarządcza chroni przed niedojrzałością. Niepewność opisuje zakres wiarygodnych wartości. Łączenie ich w jedną „bezpieczną nadwyżkę” utrudnia decyzję i pozwala wielokrotnie wydać ten sam zapas.

Dla addytywnej wielkości

$$M=L_{alloc}-\sum_i \hat L_i$$

jest marginesem względem bieżącej prognozy, ale jego znaczenie zależy od niepewności $\hat L_i$. Sumowanie pierwiastkowe błędów jest dopuszczalne tylko dla uzasadnionej niezależności i właściwego modelu statystycznego. Wspólny zegar, temperatura lub narzędzie może skorelować składniki i unieważnić takie uproszczenie.

Budżet ma wersję oraz właściciela. Zmiana jednego podsystemu aktualizuje całkowity model i wszystkie zależne TPM. Lokalny zespół nie może wydać marginesu interfejsowego bez decyzji właściciela systemu. Wartość nominalna bez tolerancji i dojrzałości nie powinna otrzymywać tego samego statusu co pomiar zwalidowanego egzemplarza.

Linia bazowa zamraża podstawę porównania, nie sam rozwój

Linia bazowa funkcjonalna opisuje zatwierdzone funkcje i wymagania systemowe. Linia przydzielona wiąże je z elementami architektury. Linia produktowa opisuje wykonany wyrób i dokumentację potrzebną do jego odtworzenia. Nazwy oraz formalne momenty zależą od programu, ale zasada jest stała: wynik można porównać tylko z rozpoznawalną podstawą.

Zamrożenie nie oznacza zakazu zmian. Oznacza, że zmiana ma właściciela, analizę wpływu, decyzję, zakres obowiązywania (effectivity) i aktualizację zależnych artefaktów. Jeśli próba dotyczyła rewizji A, a dostarczany wyrób ma rewizję B, wynik nie przechodzi automatycznie. Trzeba wykazać brak wpływu albo stworzyć dowód różnicowy.

Konfiguracja dowodu obejmuje więcej niż badany egzemplarz: wyposażenie, stanowisko, oprogramowanie, obraz FPGA, dane, narzędzia, kalibracje, procedurę oraz model redukcji. Identyczny numer części może kryć inną partię, poprawkę lub historię środowiska. Rodowód artykułu próbnego (test article pedigree) jest częścią wyniku.

DoDI 5000.88 wymaga zarządzania inżynierią, liniami bazowymi, specjalnościami i przeglądami w cyklu systemów obronnych.1 Dokument nie narzuca szczegółowego rozwiązania każdego programu, ale potwierdza, że konfiguracja i decyzje techniczne są częścią zarządzania zdolnością, nie administracyjnym dodatkiem.

Sprawa zapewnienia powinna organizować dowody od początku

Sprawa zapewnienia (assurance case) składa się z twierdzeń, argumentów i dowodów. Twierdzenie ma zakres: konkretny system, konfigurację, środowisko i warunek. Argument wyjaśnia, dlaczego zestaw wymagań, modeli oraz prób wspiera twierdzenie. Dowód dostarcza obiektywnego wyniku. Założenia i potencjalne obalacze (defeaters) pozostają widoczne.

Przykładowe twierdzenie „interfejs dostarcza dane o wymaganej jakości i czasie” może zależeć od pięciu argumentów: wspólnej semantyki, zsynchronizowanego czasu, budżetu opóźnienia, integralności transmisji i reakcji na brak danych. Każdy argument ma osobny dowód. Pomyślna próba nominalna nie zamyka przypadków utraty synchronizacji lub konfiguracji.

Sprawa zapewnienia nie jest dopiero końcowym rozdziałem raportu. Już przy formułowaniu wymagania wskazuje, jaki dowód będzie potrzebny i gdzie istnieje luka. Przy zmianie pozwala otworzyć tylko zależne twierdzenia, o ile relacje są kompletne. Przy przeglądzie pokazuje nie liczbę dokumentów, lecz siłę oraz granice argumentu.

Bezpieczeństwo systemu używa tej samej logiki dla zagrożeń. MIL-STD-882E obejmuje eliminację zagrożeń i ograniczanie ryzyka sprzętu, oprogramowania, infrastruktury oraz pełnego cyklu od projektu do wycofania.7 NIST SP 800-160 integruje potrzeby ochrony i wiarygodność z inżynierią systemu przez cykl życia.9 Oba źródła mają inne domeny, ale wspólnie pokazują, że bezpieczeństwo nie może wejść jako końcowa lista kontrolna.

Strategia weryfikacji zaczyna się od intencji i ryzyka

Weryfikacja odpowiada: czy zbudowano zgodnie ze specyfikacją? Walidacja: czy zbudowano właściwy produkt dla użytkownika i rzeczywistego kontekstu? System może przejść wszystkie testy specyfikacji i nie zaspokoić potrzeby, jeżeli sama specyfikacja była błędna. Może też dobrze wypaść w demonstracji operacyjnej mimo niezamkniętego wymagania bezpieczeństwa.

Cztery podstawowe metody mają różne granice. Inspekcja potwierdza obecność, wymiar, oznaczenie lub dokument. Analiza wnioskuje z danych i modelu. Demonstracja pokazuje funkcję bez pełnego pomiaru. Próba wymusza kontrolowane wejście i mierzy odpowiedź. Wybór metody wynika z treści, ryzyka, reprezentatywności i możliwości bezpiecznego uzyskania danych.

Strategia określa poziom integracji. Próbka materiału identyfikuje własność, komponent — funkcję lokalną, podsystem — interfejsy, a system — wątki prowadzone od początku do końca. Próba niższego poziomu może być dokładniejsza, lecz nie obejmuje wspólnych zależności. Próba systemowa jest reprezentatywna, ale kosztowna i daje mniej realizacji. Model łączy poziomy tylko po walidacji dla chronionych wielkości.

MIL-STD-810H nie jest tabelą uniwersalnych „wojskowych poziomów”. Wymaga dostosowania środowisk do profilu cyklu życia.8 To samo dotyczy kolejności: osobne próby temperatury i drgań mogą nie odtworzyć mechanizmu zależnego od ich historii.

VCRM łączy wymaganie z decyzją, nie tylko z metodą

Macierz zgodności i weryfikacji wymagań (VCRM/RVM) powinna zawierać co najmniej: identyfikator, źródło, poziom, intencję, metodę, poziom integracji, obiekt i konfigurację, wyposażenie, obiekt badawczy, procedurę, kryterium, dane, wynik, rozbieżność, decyzję, właściciela oraz zakres obowiązywania.

Pole Pytanie, na które odpowiada Czerwona flaga
wymaganie i wersja co dokładnie zamykamy? tekst skopiowany bez identyfikatora linii bazowej
intencja i metoda jaka własność i dlaczego ta metoda? samo słowo „test”
konfiguracja czego oraz z czym dotyczy wynik? „typowy egzemplarz” bez rodowodu
kryterium jaka reguła istniała przed wynikiem? próg ustalony po analizie danych
wynik i niepewność co rzeczywiście zaobserwowano? samo PASS bez surowych danych
rozbieżność i decyzja co nie pasowało i kto rozstrzygnął? zamknięcie przez autora próby bez uprawnionego decydenta
zakres obowiązywania dla jakiej populacji wynik obowiązuje? przeniesienie na „podobny” wariant

Status wymagania nie powinien być binarny aż do końca procesu. Możliwe są stany: zaplanowane, procedura zatwierdzona, wykonane, wynik analizowany, zgodne, niezgodne, warunkowo przyjęte oraz ponownie otwarte. „Test wykonany” nie oznacza „wymaganie zweryfikowane”.

Metrologia i reguła decyzji nadają wynikowi znaczenie

Wynik pomiaru obejmuje wartość, jednostkę, niepewność, identyfikację toru, kalibrację, warunki i metodę redukcji. Dla górnego limitu $L$ prosta konserwatywna reguła może wymagać

$$y+U\le L,$$

gdzie $y$ jest wynikiem, a $U$ rozszerzoną niepewnością dla zadeklarowanego poziomu pokrycia. Jeżeli przedział przecina limit, wynik jest nierozstrzygający według tej reguły — nie automatycznie zgodny ani niezgodny. Program może przyjąć inną regułę, ale musi zrobić to przed poznaniem danych.

Dla znormalizowanego górnego limitu $L=1{,}00$ i niepewności rozszerzonej $U=0{,}08$ trzy wyniki prowadzą do różnych decyzji:

Wynik $y$ Przedział $y\pm U$ Decyzja według zadeklarowanej reguły Dlaczego
$0{,}91$ $[0{,}83;0{,}99]$ zgodny górna granica nie przekracza limitu
$0{,}94$ $[0{,}86;1{,}02]$ nierozstrzygający przedział przecina granicę
$1{,}10$ $[1{,}02;1{,}18]$ niezgodny nawet dolna granica przekracza limit

Liczby nie opisują żadnego rzeczywistego wyrobu. Pokazują natomiast, że 0,94 < 1,00 nie wystarcza do akceptacji. Wynik nierozstrzygający może prowadzić do dokładniejszego pomiaru, dodatkowych danych, poprawy procesu albo jawnej decyzji ryzyka — nie do automatycznego zaokrąglenia na korzyść programu.

Reguła decyzji rozdziela dwa błędy. Fałszywa akceptacja dopuszcza wyrób niespełniający limitu; fałszywe odrzucenie eliminuje wyrób zgodny. Poszerzenie pasa ochronnego zmniejsza pierwszy rodzaj ryzyka kosztem częstszych wyników nierozstrzygających lub odrzuceń. Właściciel wymagania powinien przed próbą określić, który błąd jest bardziej dotkliwy, jaki poziom pokrycia reprezentuje $U$ i kto może przyjąć ryzyko. Sama algebra nie podejmuje tej decyzji.

Niepewność pochodzi z sensora, kalibracji, kwantyzacji, synchronizacji, ustawienia, środowiska, próbkowania i modelu redukcji. Wspólna przyczyna może skorelować kanały. Uśrednienie zmniejsza część szumu losowego, lecz nie usuwa błędu systematycznego. Wygładzony wykres nie jest dokładniejszym pomiarem bez uzasadnienia filtra.

Surowe dane, konfiguracja, skrypty i ich sumy kontrolne powinny zostać zachowane. Wynik z prezentacji nie wystarcza do ponownej analizy. Jeśli filtr, jednostka albo wybór okna zmienia decyzję, te elementy są częścią dowodu i podlegają konfiguracji.

Dowód w trzech studiach i modelach

Studium I: jakość danych inicjalizacyjnych przechodzi przez cały system

Rozważmy neutralny wątek, w którym zewnętrzny sensor dostarcza efektorowi pakiet inicjalizacyjny. Potrzeba użytkownika brzmi: system ma rozpocząć funkcję na podstawie aktualnej i wystarczająco dokładnej informacji. Nie jest jeszcze wymaganiem technicznym, ponieważ nie definiuje granicy, czasu ani odpowiedzialności.

Wątek przechodzi przez wykrycie, utworzenie śladu, decyzję, transmisję, odbiór, sprawdzenie jakości i użycie. Z niego powstają wymagania na wspólny układ współrzędnych, znacznik czasu, maksymalny wiek danych, integralność, stan braku pakietu i potwierdzenie przyjęcia. Budżet opóźnienia ma postać

$$L_{end}=L_{sensor}+L_{fusion}+L_{decision}+L_{link}+L_{receive}+L_{queue}.$$

Dwukierunkowy graf śledzenia wymagania i dowodu

Wartości znormalizowane mogą przyjąć alokacje $0{,}20$, $0{,}25$, $0{,}10$, $0{,}15$, $0{,}10$ i $0{,}10$ limitu, pozostawiając $0{,}10$ rezerwy nominalnej. Nie są to dane żadnego systemu. Pokazują natomiast, że rezerwa $0{,}10$ nie jest jeszcze wykazanym marginesem probabilistycznym, jeżeli czasy mają wspólny ogon rozkładu albo różne definicje punktu końcowego.

Wspólny ogon można pokazać bez przyjmowania konkretnego rozkładu. Niech opóźnienie składnika ma postać

$$L_i=\mu_i+\beta_i Z+\varepsilon_i,$$

gdzie $Z$ opisuje wspólne obciążenie — na przykład przeciążenie zasobu lub błąd synchronizacji — a $\varepsilon_i$ lokalną zmienność. Wtedy dla $i\ne j$

$$\operatorname{Cov}(L_i,L_j)=\beta_i\beta_j\operatorname{Var}(Z)+ \operatorname{Cov}(\varepsilon_i,\varepsilon_j).$$

Jeżeli składniki lokalne są niezależne, drugi człon znika, ale pierwszy pozostaje. Wariancja sumy zawiera wtedy dodatnie wyrazy krzyżowe. Liczenie każdego percentyla osobno i łączenie ich tak, jakby fazy były niezależne, może zaniżyć ogon całego wątku. Model nie wyznacza wartości liczbowej; wskazuje, jakie dane o współzależności muszą wejść do dowodu.

Dowód składa się z analizy budżetu, synchronizacji czasu, próby interfejsu z opóźnieniami, HiL z modelem ruchu oraz walidacji operacyjnego skutku. Sam test łącza nie sprawdza jakości śladu. Sam HiL nie dowodzi rzeczywistego opóźnienia sensora, jeśli wejście jest idealne. Każdy wynik ma wskazaną konfigurację, wersję semantyki komunikatu i zakres opóźnień.

Załóżmy, że integracja ujawnia kolejkę zwiększającą ogon opóźnienia, ale średnia pozostaje nominalna. Wymaganie o samej średniej nie chroni wątku. Zespół ponownie otwiera definicję miary, model MOE oraz budżet. Może zmienić alokację, architekturę kolejki albo warunek ważności danych. Dowód nie „naprawia” wymagania; odkrycie wraca pętlą do intencji.

Studium kończy się dwukierunkowym śledzeniem. W dół potrzeba tworzy wymagania interfejsowe i budżet. W górę surowe dane z konkretnej linii bazowej wspierają każdy składnik, a model pokazuje wpływ na potrzebę. Wynik obowiązuje tylko dla zbadanej semantyki, zegara, oprogramowania i sprzętu.

Modele oraz MiL/SiL/PiL/HiL potrzebują własnego dowodu

Model może zastąpić niebezpieczną albo niemożliwą próbę, eksplorować rozrzuty i łączyć poziomy. Jego ważność nie jest jednak ogólna. Trzeba wskazać zamierzone zastosowanie, chronione wielkości, zakres wejść, równania, parametry, dane kalibracyjne, błąd walidacji i ograniczenia ekstrapolacji.

Model w pętli (Model-in-the-Loop, MiL) sprawdza algorytm w środowisku modelowym. Program w pętli (Software-in-the-Loop, SiL) bada skompilowane zachowanie programu. Procesor w pętli (Processor-in-the-Loop, PiL) dodaje platformę wykonawczą. Sprzęt w pętli (Hardware-in-the-Loop, HiL) łączy rzeczywisty sprzęt z symulowanym obiektem. Każdy poziom usuwa część abstrakcji, ale wprowadza opóźnienia, wejścia i wyjścia oraz ograniczenia stanowiska.

Pisownia SiL jest tu celowa. Skrót SIL bywa używany także dla poziomu nienaruszalności bezpieczeństwa (Safety Integrity Level) w rodzinie IEC 61508. Są to niezależne pojęcia: pierwsze oznacza konfigurację symulacji, drugie poziom związany z redukcją ryzyka w określonej podstawie normatywnej. Wynik SiL nie ustanawia SIL, a ten artykuł nie przypisuje żadnemu przykładowi poziomu nienaruszalności bezpieczeństwa.

Porównanie modelu z pomiarem powinno używać miary związanej z decyzją. Znormalizowana reszta

$$r_i=\frac{y_i-\hat y_i}{u_i}$$

ma sens tylko wtedy, gdy $u_i$ rzeczywiście opisuje odpowiednią niepewność łączną. Dobry błąd globalny może ukrywać lokalny pik decydujący o zgodności. Walidacja dla jednego trybu nie przenosi się automatycznie na reset, nasycenie albo uszkodzenie.

Wstrzykiwanie błędów powinno wynikać z hazardów, FMEA i architektury. Duża liczba przypadkowych zakłóceń nie dowodzi pokrycia. Stanowisko potrzebuje własnej analizy bezpieczeństwa, ponieważ test celowo wprowadza awarie i może wygenerować niekontrolowane wyjście.

Studium II: funkcja czasu rzeczywistego w FPGA ma dwa produkty

Neutralna funkcja FPGA otrzymuje próbki, wykonuje obliczenie stałoprzecinkowe i wystawia wynik w ograniczonym czasie. Produktem nie jest tylko kod w języku opisu sprzętu (HDL). Drugim produktem jest dowód: śledzenie wymagań, samosprawdzające środowisko testowe, analiza przejść domen zegara i resetu (CDC/RDC), wyniki syntezy, analiza czasowa, plik konfiguracyjny oraz próba na sprzęcie.

Wymaganie funkcjonalne definiuje wejście, tryby, inicjalizację, reset, stan błędu i wynik. Wymaganie czasowe określa punkty pomiaru oraz warunki. Osobne wymagania obejmują przepełnienie, kwantyzację, przejścia CDC/RDC i tożsamość obrazu. Użycie „maksymalnej liczby cykli” nie wystarcza, jeśli częstotliwość, arbitraż lub buforowanie mogą się zmienić.

Przepływ dowodu jest iteracyjny; angielskie skróty w diagramie są rozwinięte w tekście:

specyfikacja → architektura RTL → środowisko testowe i właściwości
      ↓                    ↓
  analiza stałoprzecinkowa   CDC/RDC i reset
      ↓                    ↓
synteza → implementacja → analiza czasowa → plik konfiguracji
      ↘                próba sprzętowa i HiL        ↗

Środowisko testowe potwierdza zachowanie modelu RTL (poziomu przesłań między rejestrami) dla wybranych przypadków. Analiza czasowa potwierdza spełnienie ograniczeń w modelu implementacji. HiL bada interfejs oraz zachowanie z otoczeniem. Żaden wynik sam nie dowodzi całości. Literatura FPGA dobrze opisuje przepływ specyfikacja–HDL–synteza–sprzęt i rolę samosprawdzających środowisk, ale nie zastępuje formalnej kwalifikacji funkcji istotnej dla bezpieczeństwa.13,14

Po zmianie wersji narzędzia identyczny kod źródłowy może dać inną implementację. Analiza wpływu obejmuje ograniczenia narzędzia, raporty, bloki własności intelektualnej (IP), ostrzeżenia, analizę czasową, plik konfiguracji i próbę regresyjną. Suma kontrolna pliku identyfikuje jego bity, ale nie dowodzi poprawności funkcji. VCRM musi wiązać dokładny plik konfiguracyjny z wynikami, które go dotyczą.

Kwalifikacja, odbiór, certyfikacja i walidacja nie są synonimami

Kwalifikacja pokazuje, że projekt i proces potrafią spełnić wymagania w przewidzianej obwiedni. Odbiór potwierdza, że konkretny egzemplarz został wykonany zgodnie z zatwierdzoną konfiguracją bez niedopuszczalnego zużycia resursu. Certyfikacja jest formalnym stwierdzeniem właściwego organu według określonej podstawy. Walidacja operacyjna ocenia wartość systemu w kontekście użytkownika.

Egzemplarz kwalifikacyjny powinien reprezentować produkt w cechach istotnych dla mechanizmu. Jeśli ma inne materiały, proces, oprogramowanie lub oprzyrządowanie, potrzebny jest argument podobieństwa. Nadmierna próba może wykazać odporność nierealnej konfiguracji albo zużyć mechanizm inaczej niż eksploatacja.

Odbiór nie powtarza całej kwalifikacji. Wybiera cechy wykrywające wady wykonania i konfiguracji. Wynik kwalifikacji nie zwalnia z kontroli procesu, a wynik odbioru nie potwierdza marginesu projektu. Oba dowody spotykają się w rekordzie egzemplarza.

Certyfikat nie ma większego zakresu niż jego podstawa. Powinien wskazywać system, wersję, ograniczenia i obowiązujące odstępstwa. Użycie dokumentu z innej domeny może wspierać metodę, lecz nie tworzy automatycznie certyfikacji programu wojskowego.

Studium III: podobny wyrób nie dziedziczy automatycznie kwalifikacji

Załóżmy zmianę dostawcy elementu elektronicznego, materiału obudowy, oprogramowania układowego aparatury pomiarowej i wersji skryptu redukcji. Zespół chce wykorzystać poprzednią kwalifikację, ponieważ funkcja nominalna i wymiary pozostały podobne. To za mało do decyzji.

Najpierw tworzy się graf wpływu. Nowy komponent może zmienić rozruch, opóźnienie i uszkodzenie wspólne. Materiał wpływa na termikę oraz ekranowanie. Oprogramowanie układowe przyrządu zmienia filtr i znacznik czasu. Skrypt redukcji wpływa na wynik historycznych danych. Każda różnica prowadzi do wymagań, zagrożeń, modeli i dowodów, które mogą utracić ważność.

Następnie klasyfikuje się dowody. Wynik pozostaje ważny, jeżeli zmiana nie dotyka mechanizmu i istnieje obiektywne uzasadnienie. Dowód różnicowy wystarcza, gdy wpływ jest ograniczony i mierzalny. Pełne powtórzenie jest potrzebne, gdy zmienia się chroniony mechanizm, założenie modelu, środowisko albo kryterium. Brak danych nie jest dowodem braku wpływu.

Przykładowa macierz decyzji:

Zmiana Prawdopodobny wpływ Minimalne pytanie dowodowe Możliwa decyzja
dostawca komponentu rozruch, dryf, sposób uszkodzenia czy charakterystyka i proces są równoważne w obwiedni? analiza + próba różnicowa albo rekwalifikacja
materiał obudowy termika, masa, EMC które modele i środowiska zależą od własności? ponowna analiza i wybrane próby
oprogramowanie układowe przyrządu filtr, czas, format danych czy rodowód wcześniejszego wyniku jest zachowany? ponowna redukcja lub pomiar
skrypt analityczny obliczona miara i niepewność czy zmiana może przesunąć decyzję? regresja wszystkich zależnych zbiorów

Na końcu rada zmian zatwierdza nowy zakres obowiązywania, a sprawa zapewnienia pokazuje twierdzenia zachowane, zastąpione i ponownie otwarte. Wynik nie jest „odziedziczony”; jego zakres został ponownie dowiedziony. To odróżnia analizę podobieństwa od wygodnego stwierdzenia, że wyrób wygląda tak samo.

Przeglądy techniczne oceniają dojrzewanie argumentu

SRR nie powinien pytać tylko, czy baza wymagań istnieje, lecz czy potrzeby zostały zwalidowane, konflikty rozstrzygnięte, a wymagania są mierzalne i śledzone. SFR ocenia kompletność funkcji oraz wątków. PDR pyta, czy wybrana architektura może spełnić wymagania z marginesem. CDR — czy projekt i dowód są wystarczająco dojrzałe do wykonania.

TRR ocenia gotowość próby: zatwierdzone wymagania i procedury, konfigurację, obiekt, wyposażenie, kalibrację, bezpieczeństwo, dane, personel i regułę decyzji. SVR ocenia, czy zweryfikowano system. FCA porównuje funkcjonalność z wymaganiami, a PCA — dokumentację produktu z konfiguracją wykonaną. Nazwy bramek mogą się różnić, lecz każde wydarzenie ma odrębne twierdzenie o dojrzałości.

Bramka Główne twierdzenie Dowód konieczny Powód odmowy przejścia
SRR wiadomo, czego i dlaczego potrzeba zwalidowane potrzeby, dobre wymagania, śledzenie otwarte sprzeczności lub nieweryfikowalne shall
SFR funkcje oraz wątki łącznie pokrywają wymagania architektura funkcjonalna, przepływy, stany i argument wystarczalności funkcja bez właściciela, niezamknięty interfejs albo kontrprzykład dla dekompozycji
PDR architektura może zamknąć wymagania modele, budżety, interfejsy, ryzyka brak wystarczalności alokacji lub ujemny margines
CDR projekt jest gotowy do wykonania szczegółowa konfiguracja i plan dowodu krytyczne TBD/TBR, niedojrzałe interfejsy
TRR próba może bezpiecznie dać ważny wynik procedura, rodowód, kalibracja, kryterium niepewna konfiguracja, brak analizy bezpieczeństwa lub danych
SVR/FCA/PCA wymagania i produkt są zgodnie zamknięte wyniki, rozbieżności, linia bazowa, zakres obowiązywania otwarte dowody albo niezgodna konfiguracja powykonawcza

Przegląd jest oceną opartą na zdarzeniu i kryteriach, nie prezentacją według kalendarza. Warunkowe przejście ma właściciela, termin, ryzyko i zakaz wykorzystania poza ustalonym zakresem. Nadzieja na późniejsze zamknięcie nie jest dowodem wejściowym.

Kontrakt musi przenosić znaczenie i dowód przez łańcuch dostaw

Zamawiający definiuje potrzeby, ograniczenia, interfejsy, podstawę akceptacji i oczekiwane dane. Wykonawca pokazuje, jak zarządza analizą, architekturą, dostawcami, konfiguracją i weryfikacją. DI-SESS-81785 opisuje zawartość SEMP oraz jego relację do procesów wykonawcy i zamawiającego.12

Przepływ wymagania do podwykonawcy musi zachować źródło, kryterium i obowiązek dowodu. Sam numer shall bez kontekstu może prowadzić do lokalnej optymalizacji. Dostawca powinien wiedzieć, które cechy są krytyczne, jakie dane mają zostać zachowane i które zmiany wymagają zgody.

Rozważmy neutralne wymaganie systemowe R-SYS-042: komunikat ma dotrzeć w stanie aktualnym według wspólnej definicji wieku danych. Integrator nie powinien przekazać dostawcy pierwszego poziomu samego lokalnego limitu opóźnienia. Kontrakt musi także zachować punkt początku i końca pomiaru, epokę czasu, semantykę stanu braku danych, budżet niepewności oraz oczekiwany dowód.

Poziom łańcucha Obowiązek Przekazywany dowód Zmiana otwierająca analizę wpływu
integrator systemu utrzymuje definicję aktualności i budżet całego wątku wynik integracyjny, model budżetu i decyzja systemowa zmiana miary, zegara nadrzędnego lub architektury wątku
dostawca pierwszego poziomu alokuje lokalny czas, kolejkę i zachowanie po utracie wejścia surowe dane, konfiguracja programu, niepewność i wynik według kryterium zmiana kolejki, programu, interfejsu albo narzędzia
dostawca drugiego poziomu dostarcza element pomiaru czasu zgodny z przydzielonym kontraktem charakterystyka partii, kalibracja i zakres warunków zmiana części, procesu, partii lub podstawy kalibracji

Dowód płynie w górę, lecz decyzja nie jest automatycznie delegowana. Świadectwo dostawcy drugiego poziomu może zamknąć własność elementu, ale dopiero dostawca pierwszego poziomu wykazuje wpływ na moduł, a integrator — na aktualność komunikatu w całym wątku. Jeżeli umowa nie wymaga surowych danych lub identyfikacji konfiguracji, brakującego rodowodu nie da się odtworzyć samym raportem zbiorczym.

Pozycja danych kontraktowych nie jest automatycznie dowodem. Raport może być kompletny formalnie, a nie zawierać surowych danych, konfiguracji lub niepewności. Ocena dostawy powinna pytać, czy artefakt wspiera określone twierdzenie i czy można go utrzymać po zmianie.

Prawa do danych, eksport, poufność i bezpieczeństwo informacji trzeba ustalić wcześnie. Brak dostępu do modelu lub danych dostawcy może uniemożliwić niezależną ocenę. Wówczas ograniczenie jest częścią sprawy zapewnienia i decyzji ryzyka, a nie problemem administracyjnym do ukrycia.

Synteza: zgodność zamyka się tylko w obu kierunkach

Dojrzały program nie liczy jakości liczbą wymagań ani liczbą prób. Pyta, czy każda potrzeba ma zwalidowany kontekst i miarę; czy każde zobowiązanie jest konieczne, jednoznaczne i sprawdzalne; czy architektura oraz budżety łącznie wystarczają; czy każdy wynik ma konfigurację, niepewność i regułę decyzji; oraz czy właściwa osoba zamknęła rozbieżności i zakres obowiązywania.

Gdy dowody są ograniczone, nie maksymalizuje się jednocześnie kompletności, realizmu, bezpieczeństwa, kosztu i liczby prób. Zespół buduje zróżnicowany pakiet: dokładne testy niższego poziomu, reprezentatywne próby integracyjne, zwalidowane modele, analizę niepewności i jawne ograniczenia. Siła argumentu wynika z komplementarności dowodów, nie z udawania, że jeden typ pokrywa wszystko.

Trzy studia pokazują tę samą regułę. Dane inicjalizacyjne wymagają budżetu całego wątku i dowodu semantyki, czasu oraz efektu. FPGA ma równoległy produkt funkcjonalny i dowodowy, zależny od łańcucha narzędzi oraz pliku konfiguracji. Ponowne użycie kwalifikacji wymaga grafu wpływu i nowej decyzji o zakresie obowiązywania. W każdym przypadku odkrycie z integracji wraca do wymagań, a zmiana wymagań schodzi ponownie do konfiguracji.

Dwukierunkowy argument jest więc mechanizmem kontroli sensu. Droga w dół zapobiega budowie rzeczy niepotrzebnej lub niespójnej. Droga w górę zapobiega ogłoszeniu zgodności na podstawie niewłaściwego egzemplarza albo słabego wyniku. Dopiero ich połączenie uzasadnia stwierdzenie, że dostarczony system spełnia zatwierdzoną potrzebę w rozpoznanym zakresie.

Źródła