Zarządzanie konfiguracją systemu rakietowego

Zdolność istnieje tylko w określonej konfiguracji

Pocisk może być sprawny, wyrzutnia gotowa, sensor poprawnie śledzić obiekt, a stanowisko dowodzenia nie wykazywać usterek — i mimo to zestawienie tych elementów może nie tworzyć potwierdzonej zdolności bojowej. Każdy składnik może osobno spełniać własną specyfikację, lecz wynik systemowy zależy od zgodności interfejsów, oprogramowania, danych, procedur i zakresu kwalifikacji. Zdolność nie jest więc trwałą cechą nazwy handlowej ani rodziny pocisków. Jest własnością zweryfikowanej konfiguracji całego łańcucha systemowego, przypisaną do określonej populacji i chwili cyklu życia.

Zarządzanie konfiguracją (configuration management, CM) dostarcza mechanizmu dowodowego, który łączy wymaganie, zatwierdzony projekt, rzeczywiście wykonany produkt, wynik weryfikacji oraz aktualny stan egzemplarza. Nie ustanawia zdolności przez sam zapis w bazie. Pozwala natomiast rozstrzygnąć, czy dowód zdolności odnosi się do tego systemu, który znajduje się przed użytkownikiem. Bez tej relacji pomyślna próba może być prawdziwym wynikiem nieodtwarzalnej konfiguracji, a poprawnie wykonany egzemplarz — produktem nieobjętym właściwą kwalifikacją.

Problem zaczyna się od czterech pytań, które w potocznym opisie bywają zastępowane jednym: jaki projekt zatwierdzono, jakie wydanie danych udostępniono, co zainstalowano w konkretnym egzemplarzu oraz jaki jest rozkład tych stanów w całej flocie? Projekt opisuje to, co powinno zostać wykonane. Wydanie jest zatwierdzonym pakietem przeznaczonym do użycia. Egzemplarz ma własną historię produkcji, napraw i aktualizacji. Flota jest populacją, w której mogą współistnieć różne bloki, modyfikacje i ograniczenia.

Najnowszy projekt nie musi być projektem obowiązującym dla każdej sztuki. Najnowsze wydanie oprogramowania nie musi być dopuszczone do starszej rewizji komputera. Zatwierdzenie modyfikacji nie oznacza jej wykonania. Dostarczenie pakietu aktualizacyjnego nie dowodzi instalacji, a instalacja nie dowodzi przywrócenia egzemplarza do służby. Jeżeli ewidencja redukuje te zdarzenia do statusu „zaktualizowano”, nie opisuje konfiguracji, lecz administracyjne życzenie.

Można to zapisać jako relację:

zdolność w chwili $t$ = funkcja zatwierdzonej architektury, zgodności składników, stanu egzemplarzy, ważności danych, wykonanej obsługi i dowodów odnoszących się do dokładnie tej konfiguracji

Nie jest to równanie obliczeniowe. Pokazuje, że zdolności nie wolno wyprowadzać z jednego atrybutu. Prawidłowy numer części nie zastępuje wiedzy o zainstalowanym obrazie FPGA. Pozytywny test pocisku nie zastępuje testu jego współpracy z wyrzutnią. Stan „sprawny” w systemie logistycznym nie dowodzi, że urządzenie testowe użyło właściwego programu i limitów. CM jest właśnie dyscypliną utrzymywania tych zależności.

Granica systemu wyznaczona przez zależności

Granica systemu rakietowego nie powinna kończyć się na obudowie pocisku. Należy ją wyznaczać według pytania o zdolność: trzeba objąć analizą każdy element, którego stan lub niezgodność może zmienić wykonanie funkcji, ocenę gotowości albo ważność dowodu.

Rdzeń fizyczny obejmuje pocisk i wyrzutnię lub platformę startową. Pocisk zawiera konstrukcję, napęd, źródła energii, sensory, komputer, urządzenia wykonawcze oraz inne podsystemy właściwe jego roli. Wyrzutnia zapewnia nie tylko podparcie mechaniczne, lecz także energię, inicjalizację, komunikację, synchronizację, kontrolę stanu i przejście między warunkami magazynowania, gotowości oraz użycia. Mechaniczne dopasowanie kontenera nie dowodzi poprawności żadnej z pozostałych relacji.

Następną warstwę tworzą sensory zewnętrzne i system dowodzenia oraz kierowania (command and control, C2). Sensor wytwarza obserwację albo estymatę w określonym układzie odniesienia, formacie i czasie. C2 łączy dane, zarządza stanem misji oraz przekazuje informacje do elementów wykonawczych. Łącze danych jest w tej relacji środkiem transportu, a nie samą zdolnością: jego obecność nie mówi jeszcze, jakie wiadomości przenosi, w którym kierunku, z jaką aktualnością ani do jakiego wydania odbiorcy.

Do granicy należą również automatyczne urządzenia testowe (automatic test equipment, ATE), adaptery, sprzęt obsługowy, programy testowe, wzorce, wyposażenie do ładowania danych i infrastruktura kalibracyjna. Tester może przesądzić o dopuszczeniu pocisku do służby. Jeśli używa niewłaściwego programu, błędnie rozpoznaje wariant albo stosuje limity niezgodne z badaną populacją, jego pozytywny wynik nie jest dowodem poprawności produktu. ATE jest zatem oddzielnym systemem o własnej konfiguracji, nie przezroczystym narzędziem poza systemem uzbrojenia.

Granica przecina również dziedzinę cyfrową. Obejmuje oprogramowanie wykonywane na procesorach, firmware urządzeń, źródła i obrazy logiki FPGA, program rozruchowy, dane kalibracyjne, tablice zgodności, konfigurację protokołów, dane inicjalizacyjne, procedury testowe oraz informacje używane przez sprzęt obsługowy. Dwa fizycznie identyczne komputery mogą realizować odmienne funkcje, jeżeli zawierają inne obrazy lub dane. Z kolei identyczny plik wykonywalny może zachowywać się inaczej z innym zestawem współczynników, mapą wejść i wyjść albo konfiguracją logiki programowalnej.

Tak wyznaczona granica nie oznacza, że wszystkie elementy mają jednego właściciela albo znajdują się w jednym kontrakcie. Przeciwnie: system rakietowy często łączy wyroby rozwijane przez różne organizacje i według różnych cykli. Właśnie dlatego potrzebne są jawne granice odpowiedzialności, kontrolowane interfejsy i wspólna reguła orzekania o zgodności.

Kręgosłup normatywny i cztery poziomy zobowiązania

Nie istnieje jeden dokument, który sam ustanawiałby kompletny proces CM dla każdego programu NATO. Normy, publikacje sojusznicze, wymagania jakościowe, umowa, plan programu i zapisy wykonania pełnią odmienne role. Pomieszanie tych ról prowadzi do pozornej zgodności: organizacja wskazuje właściwy standard, ale nie potrafi wykazać, jakie wymagania faktycznie przyjęła ani jak zostały wykonane.

STANAG 4427 ustanawia natowską ramę zarządzania konfiguracją w cyklu życia i wiąże ją z publikacjami ACMP-2000, ACMP-2009 oraz ACMP-2100. Publiczny rekord potwierdza aktywny status Revision 3 i jego powiązanie z tymi trzema publikacjami, lecz pełny dokument nie jest dostępny anonimowo w ASSIST; z samego rekordu można więc rzetelnie potwierdzić tytuł, status, datę promulgacji i strukturę odniesień, nie zaś pozornie cytować nieodczytane postanowienia.^zks1-stanag

ACMP-2000 jest publikacją polityki CM, ACMP-2009 — wskazówkami stosowania, a ACMP-2100 — zbiorem wymagań przeznaczonych do użycia kontraktowego. Aktualne publiczne rekordy ASSIST potwierdzają te role oraz ujawnione wydania, ale dostęp do obrazów dokumentów wymaga zalogowania. Granicę dowodu trzeba zachować również tutaj: tytuł „wymagania kontraktowe” opisuje przeznaczenie publikacji, lecz nie dowodzi, że dokument obowiązuje w danym zamówieniu. Musi zostać przywołany we właściwej wersji i włączony do relacji zamawiający–dostawca, z ustalonym zakresem dostosowania.^{zks1-acmp2000,zks1-acmp2009,zks1-acmp2100}

AQAP-2110 dotyczy wymagań zapewnienia jakości podczas projektowania, rozwoju i produkcji, natomiast AQAP-2210 uzupełnia wymagania jakościowe dotyczące oprogramowania w relacji z AQAP-2110 albo AQAP-2310. Nie należy przedstawiać AQAP jako konkurencyjnego systemu CM. Zapewnienie jakości i zarządzanie konfiguracją przecinają się: kontrolowane wymagania, identyfikacja wyrobu, zarządzanie zmianą i dowody zgodności są potrzebne obu dyscyplinom, lecz ich przedmiot i odpowiedzialności nie są identyczne.^{zks1-aqap2110,zks1-aqap2210}

SAE/EIA-649C formułuje pięć funkcji CM i związane z nimi zasady w modelu niezależnym od jednego resortu i rodzaju produktu. Oficjalny rekord SAE wskazuje planowanie i zarządzanie, identyfikację, zarządzanie zmianą, ewidencję stanu oraz weryfikację i audyt. Opisuje też użycie zasad wewnątrz przedsiębiorstwa oraz w relacji nabywca–dostawca. Sama norma jest płatna, dlatego publiczny opis zakresu nie pozwala przypisywać jej szczegółowych nakazów niewidocznych w rekordzie. SAE publikuje osobno EIA-649-1A, zawierającą dostosowywane wymagania dla kontraktów obronnych; rozdzielenie tych dokumentów dobrze pokazuje różnicę między zasadą a klauzulą wymaganiową.^{zks1-eia649,zks1-eia6491}

MIL-HDBK-61B Change 1 jest podręcznikiem DoD opisującym praktyki CM w pozyskiwaniu i utrzymaniu systemów. Jego rekord mówi wprost, że dokument służy wyłącznie jako wskazówka i nie może zostać przywołany jako wymaganie. Podręcznik jest cennym objaśnieniem identyfikacji, kontroli zmian, ewidencji stanu, punktów bazowych i audytów, ale obowiązek dostawcy musi wynikać z umowy, specyfikacji albo innego właściwego dokumentu zamówienia.^zks1-milhdbk

Relację tych instrumentów można uporządkować następująco:

Poziom	Odpowiada na pytanie	Typowa treść	Czego sam nie dowodzi
dokument odniesienia	jakie zasady i praktyki są uznane?	polityka, terminologia, funkcje CM, wskazówki	że dana praktyka obowiązuje strony umowy
wymaganie kontraktowe	co ma wykonać dostawca i co może ocenić nabywca?	dostosowane obowiązki, wyniki, terminy, prawa do danych	że proces został prawidłowo zaplanowany i wykonany
plan programu	kto, kiedy i jak spełni wymaganie?	CI, organy decyzyjne, punkty bazowe, klasy zmian, raporty i narzędzia	że deklarowane czynności rzeczywiście wykonano
dowód wykonania	co zrobiono i z jakim wynikiem?	zatwierdzenia, manifesty, protokoły, raporty, zapisy egzemplarza, ślady audytowe	że wynik można rozszerzyć poza badaną konfigurację i zakres

Plan zarządzania konfiguracją nie jest więc normą, a norma nie jest planem. Protokół zatwierdzenia planu nie jest dowodem wdrożenia procesu. Z kolei tysiące rekordów w bazie nie dowodzą zgodności z kontraktem, jeżeli nie wiadomo, jakie pola, decyzje i kryteria miały być utrzymywane. Dojrzały system zachowuje przejście od dokumentu odniesienia do klauzuli, od klauzuli do planu i od planu do dowodu.

Żaden z wymienionych dokumentów nie ustanawia jednego natowskiego systemu numerowania firmware’u. Standardy mogą wymagać identyfikowalności, kontroli zmian i jednoznacznego wskazania konfiguracji, lecz postać numeru, semantyka pól, sposób wiązania obrazu z urządzeniem oraz zasady zwiększania numerów pozostają sprawą programu i kontraktu. Twierdzenie o uniwersalnym „numerze firmware NATO” byłoby zastąpieniem wymogu identyfikacji nieistniejącą wspólną składnią.

Pozycja konfiguracji jako granica decyzji

Pozycja konfiguracji (configuration item, CI) nie jest po prostu częścią wyróżnioną na liście materiałowej. Jest elementem wybranym do odrębnego zarządzania, ponieważ program potrzebuje kontrolować jego wymagania, interfejs, tożsamość, zmiany i dowody. CI może być całym podsystemem, wymiennym urządzeniem, oprogramowaniem, zbiorem danych albo elementem wsparcia. Śruba może podlegać ścisłej kontroli rysunkowej, a mimo to nie być CI. Z drugiej strony pakiet programowy bez fizycznej obudowy może być CI, jeżeli jego zmiana wymaga osobnej decyzji i kwalifikacji.

Programowa pozycja konfiguracji (computer software configuration item, CSCI) wyznacza kontrolowany składnik oprogramowania, dla którego można przypisać wymagania, wydania, interfejsy, odpowiedzialność i wyniki weryfikacji. Nie każdy moduł, biblioteka ani repozytorium powinny automatycznie stawać się CSCI. Granica musi być na tyle niska, aby ujawnić niezależne tempo zmian i skutki, lecz na tyle wysoka, aby proces decyzyjny nie został zasypany zmianami implementacyjnymi bez znaczenia systemowego.

Firmware wymaga szczególnej ostrożności pojęciowej. W praktyce słowem tym nazywa się zarówno program związany z urządzeniem, jak i gotowy obraz do załadowania. Dla CM trzeba rozdzielić co najmniej źródła, zależności, środowisko budowania, wynikowy plik, urządzenie docelowe, sposób instalacji oraz zapis tego, co rzeczywiście zainstalowano. Sam napis „firmware 3.2” nie wskazuje, czy chodzi o gałąź źródeł, zatwierdzone wydanie, konkretny build, obraz binarny czy wartość odczytaną z interfejsu serwisowego.

Obraz FPGA również nie jest zwykłym dokumentem ani klasycznym programem procesora. Opis HDL, rdzenie własności intelektualnej, pliki ograniczeń, ustawienia syntezy, wersja narzędzia, model układu docelowego i proces implementacji współtworzą wynikową konfigurację sprzętową. Literatura FPGA pokazuje przepływ od specyfikacji, przez opis i ograniczenia, symulację, syntezę oraz analizę czasu, do bitstreamu. Ten przepływ jest ważny dla CM, ponieważ identyczne źródła bez identycznych wejść i kontrolowanego środowiska nie gwarantują identycznego artefaktu ani zachowania czasowego.^{zks1-fpga-handbook,zks1-fpga-pl}

Interfejs jest kontrolowaną relacją co najmniej dwóch stron. Może obejmować geometrię, masę, energię, sygnały dyskretne, protokół, czas, jednostki, układy współrzędnych, kolejność stanów, zachowanie po błędzie oraz odpowiedzialność za weryfikację. Dokument kontroli interfejsu nie powinien mieć „właściciela” rozumianego jako strona mogąca jednostronnie zmienić wspólne wymaganie. Potrzebny jest właściciel każdego parametru, organ zatwierdzający zmianę i wskazani uczestnicy, których zgoda jest konieczna ze względu na wpływ.

Właściciel decyzji nie musi być właścicielem danych ani projektantem CI. Państwo może zachowywać prawo zatwierdzania zmian wpływających na zdolność, bezpieczeństwo albo interoperacyjność, podczas gdy dostawca kontroluje szczegółową dokumentację wykonawczą. Integrator może zarządzać interfejsem między produktami dwóch poddostawców, ale nie mieć prawa samodzielnie modyfikować ich wewnętrznych projektów. Plan programu musi rozdzielić co najmniej autora propozycji, wykonawcę analizy, właściciela dokumentu, organ zmiany i stronę akceptującą dowód.

Identyfikatory nie tworzą jednej drabiny

Numer części (part number) identyfikuje projekt albo klasę zamienności zgodnie z regułami właściciela. Numer seryjny (serial number) identyfikuje konkretny egzemplarz. Partia (lot lub batch) grupuje egzemplarze według określonego przebiegu produkcji, materiałów, odbioru lub śledzenia jakości. Te trzy identyfikatory odpowiadają odpowiednio na pytania: jaki wyrób, która sztuka oraz z jakiej populacji procesowej.

Blok (block) zwykle grupuje kontrolowany etap rozwoju lub zestaw zmian, lecz jego znaczenie jest lokalne. Nie musi odpowiadać pojedynczemu numerowi części ani obejmować równocześnie wszystkich składników systemu. System może zawierać pocisk jednego bloku, wyrzutnię o innym stanie modyfikacji i C2 rozwijane według własnej linii wydań.

Modyfikacja (modification) opisuje zatwierdzoną zmianę projektu albo działanie wprowadzane do określonej populacji. Stan modyfikacji egzemplarza wymaga dowodu wykonania; nie wynika z samego opublikowania biuletynu. Rewizja (revision) identyfikuje zmianę dokumentu, projektu lub elementu według reguł danego systemu danych. „Rewizja C” bez identyfikatora dokumentu nie jest jednoznaczna, ponieważ wiele rysunków, procedur i programów może równocześnie nosić ten symbol.

Build jest konkretnym wynikiem procesu budowania oprogramowania albo obrazu logicznego. Powinien być możliwy do związania ze źródłami, zależnościami, opcjami i środowiskiem. Wydanie (release) jest zatwierdzonym zestawem buildów, danych, dokumentów i informacji o zgodności przeznaczonym do określonego użycia. Można zbudować wiele wyników, z których tylko jeden zostanie wydany. Można również wydać ten sam build w dwóch pakietach różniących się zakresem dopuszczenia albo dokumentacją.

Relacja	Poprawna interpretacja	Niedopuszczalny skrót
part number → serial number	egzemplarz jest realizacją wskazanego projektu lub klasy zamienności	każdy egzemplarz o tym numerze części ma identyczną historię
lot → serial number	egzemplarz należy do określonej populacji produkcyjnej	data produkcji sama wyznacza partię
block → part number	blok może grupować kilka kontrolowanych projektów	blok jest uniwersalnym odpowiednikiem rewizji
modification → serial/lot	zmiana ma określony zakres obowiązywania i status wykonania	zatwierdzenie zmiany oznacza jej obecność we flocie
revision → dokument lub element	rewizja ma znaczenie tylko wraz z obiektem i właścicielem	„Rev B” identyfikuje cały system
build → źródła i środowisko	wynik pochodzi z określonego procesu	numer builda dowodzi odtwarzalności
release → buildy i dane	zatwierdzony pakiet obejmuje wskazane artefakty i zastosowanie	najnowsze wydanie jest właściwe dla każdej konfiguracji

Relacje spotykają się dopiero w zapisie egzemplarza. Powinien on wskazywać, jaki numer części i rewizję miał zamontowany moduł, z jakiej partii pochodził, jaki build został w nim zainstalowany, do jakiego wydania należał oraz według jakiej modyfikacji i na jakiej podstawie wykonano instalację. Żaden pojedynczy identyfikator nie przenosi całej tej wiedzy.

Punkty bazowe i rzeczywiste stany produktu

Punkt bazowy konfiguracji (configuration baseline) jest zatwierdzonym opisem ustanowionym w określonej chwili i podlegającym formalnej kontroli zmian. Nie jest każdą zapisaną wersją roboczą, dowolnym znacznikiem w repozytorium ani automatyczną kopią stanu floty.

Funkcjonalny punkt bazowy (functional baseline) utrwala wymagane funkcje i właściwości systemu na poziomie, na którym można ocenić, co ma zostać osiągnięte. Przydzielony punkt bazowy (allocated baseline) wiąże wymagania z podsystemami lub CI oraz ustanawia ich interfejsy. Produktowy punkt bazowy (product baseline) opisuje rozwiązanie wystarczająco dokładnie do wytwarzania, budowania oprogramowania, testowania i utrzymywania. MIL-HDBK-61B przedstawia te trzy poziomy jako kolejne techniczne punkty odniesienia, ale sposób i moment ich ustanowienia musi zostać dostosowany do programu.^zks1-milhdbk

Inną kategorią są kontrolowane rekordy opisujące stan:

• as-designed — zatwierdzony projekt mający zastosowanie do wskazanego zakresu;
• as-built — rzeczywisty skład egzemplarza po produkcji, wraz z reworkiem i zaakceptowanymi odstępstwami;
• as-delivered — konfiguracja przekazana odbiorcy, obejmująca także właściwe pakiety oprogramowania, danych i wsparcia;
• as-maintained — stan po naprawach, wymianach, aktualizacjach i ograniczeniach eksploatacyjnych.

Rekord as-built nie staje się automatycznie nowym rodzajem formalnego punktu bazowego. Może być porównywany z produktowym punktem bazowym oraz uzupełniany o zatwierdzone odstępstwa. Podobnie as-maintained jest opisem rzeczywistości, nie normą projektową. Program może używać dodatkowych nazw punktów bazowych, ale musi zachować rozróżnienie między opisem obowiązującym a zapisem tego, co faktycznie istnieje. MIL-HDBK-61B wskazuje w ewidencji stanu między innymi konfiguracje as-designed, as-built, as-delivered i as-modified właśnie jako informacje o produkcie i egzemplarzach, a nie jako prosty ciąg równorzędnych baz funkcjonalnej, przydzielonej i produktowej.^{zks1-milhdbk-csa}

Rozróżnienie ma konsekwencję operacyjną. Egzemplarz może zgodnie pozostawać w starszym stanie, jeżeli jego zakres obowiązywania wskazuje starszy produktowy punkt bazowy i nie wymaga modernizacji. Może też fizycznie odpowiadać najnowszemu projektowi, lecz pozostawać niedopuszczony, jeżeli modyfikacji nie zweryfikowano, nie zapisano albo nie zamknięto wymaganych działań. Audyt nie powinien porównywać wszystkich sztuk z „najnowszą dokumentacją”, lecz z dokumentacją właściwą dla ich obowiązującej konfiguracji.

Dekompozycja CI systemu rakietowego

Dekompozycja powinna rozpocząć się od funkcji i odpowiedzialności, a nie od próby uczynienia CI z każdego wiersza zestawienia części. Przykładowa struktura może wyglądać tak:

SYSTEM RAKIETOWY
├── łańcuch obserwacji
│   ├── sensor
│   └── przetwarzanie i dystrybucja danych
├── dowodzenie i kierowanie
│   ├── oprogramowanie C2
│   ├── dane systemowe
│   └── łącza
├── wyrzutnia lub platforma
│   ├── interfejs pocisku
│   ├── sterowanie i zasilanie
│   └── oprogramowanie wyrzutni
├── pocisk
│   ├── sekcja naprowadzania i sterowania
│   │   ├── komputer
│   │   ├── CSCI
│   │   ├── firmware i obrazy FPGA
│   │   └── kalibracje
│   ├── sensory pokładowe
│   ├── zasilanie
│   └── urządzenia wykonawcze
└── system wsparcia
    ├── ATE
    ├── programy testowe i adaptery
    ├── sprzęt obsługowy
    └── dokumentacja oraz dane szkoleniowe

Drzewo nie rozstrzyga jeszcze, które węzły są CI. Wybór powinien wynikać z kosztu utraty kontroli. Osobny CI jest uzasadniony, gdy element ma krytyczną funkcję, stabilny interfejs, odrębnego dostawcę, własny cykl zmian, niezależną kwalifikację, możliwość wymiany w obsłudze, istotne znaczenie dla bezpieczeństwa lub interoperacyjności albo wymaga jednoznacznego śledzenia w egzemplarzach.

Zbyt wysoki poziom kontroli ukrywa różnice. Jeżeli „elektronika pocisku” jest jednym CI, może nie być widać, że komputer, CSCI i obraz FPGA zmieniają się niezależnie. Zbyt niski poziom przenosi każdą korektę pliku albo zamianę części pasywnej na organ decyzyjny systemu i zaciera zmiany naprawdę ważne. Rozwiązaniem nie jest jednak rezygnacja z kontroli niższych elementów: części mogą pozostawać kontrolowane przez rysunki, wykazy materiałowe, zatwierdzone źródła i procesy bez uzyskania statusu osobnego CI.

Granica CI powinna także odpowiadać granicy możliwej decyzji. Jeśli państwo może zatwierdzić interfejs i wynik kwalifikacji, ale nie uzyskuje szczegółowych źródeł podsystemu dostawcy, CI powinien nadal mieć identyfikowalne wydanie, deklarowane zależności i dowód zgodności. „Black box” nie znosi CM; zmienia zakres danych dostępnych integratorowi i zwiększa znaczenie kontroli interfejsu, zawiadamiania o zmianach oraz praw do informacji potrzebnych w utrzymaniu.

Interfejs jako wspólna prawda

Kontrola interfejsu nie może ograniczać się do rysunku złącza. Dwie strony mogą mieć zgodne wymiary i rozkład styków, a różnić się napięciem, stanem bezpiecznym, sekwencją zasilania albo interpretacją wiadomości. Mogą używać tego samego formatu liczbowego w innych jednostkach, przeciwnych znaków osi lub różnych epok czasu. Mogą poprawnie wymieniać dane, które są zbyt stare dla funkcji systemowej.

Dla każdego interfejsu trzeba zatem określić co najmniej jego strony, właścicieli parametrów, mechanizm uzgadniania zmian, wymagania fizyczne i funkcjonalne, wersjonowanie, zachowanie w stanach nieprawidłowych oraz metodę weryfikacji. Oficjalne opisy danych DoD rozróżniają wymagania interfejsu, jego projekt i dokument kontroli, co przypomina, że zapis decyzji nie jest tym samym co wymaganie ani dowód wykonania.^{zks1-interface}

Zgodność systemowa jest relacją wielostli. Przykładowa macierz nie powinna więc pytać tylko, „czy pocisk pasuje do wyrzutni”, lecz czy cały wymagany przekrój został wykazany:

Konfiguracja	Pocisk–wyrzutnia	Wyrzutnia–C2	Sensor–C2	Oprogramowanie i dane	ATE i obsługa	Wniosek o zdolności
K-1	potwierdzona	potwierdzona	potwierdzona	wydanie zakwalifikowane	tester zgodny	zdolność wykazana w określonym zakresie
K-2	potwierdzona elektrycznie	potwierdzona	potwierdzona	nowe wydanie bez zamkniętej regresji	tester zgodny tylko ze starszym blokiem	brak podstaw do zgody systemowej
K-3	dopasowanie mechaniczne	brak dowodu protokołu	brak danych	pakiet planowany	brak programu testowego	integracja planowana, zdolność niewykazana
K-4	potwierdzona	ograniczona do wskazanej rewizji C2	potwierdzona	dane ważne dla części populacji	obsługa objęta biuletynem	zdolność ograniczona zakresem egzemplarzy

Komórka „potwierdzona” musi prowadzić do konkretnego dowodu i konfiguracji testu. Nie może oznaczać jedynie braku znanego problemu. „Brak danych” nie jest zgodnością ani niezgodnością, a „planowana” nie jest słabszą odmianą „potwierdzonej”. Są to różne stany wiedzy i programu.

Macierz pokazuje też, dlaczego świadectwo zgodności pocisku nie stanowi samodzielnej zgody na zdolność systemu. Potwierdza ono tylko zakres, według którego oceniono pocisk. Jeżeli kwalifikacja nie obejmowała aktualnego wydania C2, nowej rewizji wyrzutni, zmienionego formatu danych albo urządzenia testowego używanego przez jednostkę, brakujące relacje wymagają oddzielnego dowodu. Zdolność pojawia się dopiero na przecięciu zgodnych konfiguracji, a nie przez dziedziczenie cechy z najdroższego lub najbardziej widocznego składnika.

Od drzewa wyrobu do cyfrowych artefaktów

W systemie opartym głównie na dokumentacji papierowej produktowy punkt bazowy kojarzono z rysunkami, specyfikacjami i wykazami części. Współczesny system rakietowy wymaga szerszego modelu. Funkcja może zależeć od kodu, obrazu FPGA, ustawień narzędzia, wygenerowanego pliku, schematu danych, kalibracji konkretnego sensora i wersji programu ATE. Artefakt cyfrowy nie jest załącznikiem do „właściwego” sprzętu; może współtworzyć jego zachowanie i zakres kwalifikacji.

Repozytorium przechowuje historię źródeł, lecz samo nie ustanawia wydania. Znacznik nie dowodzi, że kompilację wykonano z kontrolowanych zależności. Skrót pliku potwierdza tożsamość bajtową, ale nie jego przeznaczenie, zatwierdzenie ani zgodność z urządzeniem. Podpis może potwierdzić pochodzenie od posiadacza klucza, lecz nie zastępuje oceny technicznej. Każdy z tych mechanizmów odpowiada na inne pytanie.

Dlatego przejście od klasycznego wykazu części do cyfrowej definicji produktu musi zachować relacje:

wymaganie
  → kontrolowany model lub projekt
  → źródła i dane wejściowe
  → narzędzia, zależności i ustawienia
  → konkretny build
  → zatwierdzone wydanie
  → manifest instalacyjny
  → zapis egzemplarza
  → wynik weryfikacji

Dla FPGA łańcuch powinien obejmować co najmniej opis HDL, użyte rdzenie, ograniczenia czasowe i fizyczne, urządzenie docelowe, wersję narzędzia oraz bitstream. Dla oprogramowania — źródła, biblioteki, kompilator, opcje, obraz wykonywalny i opis wydania. Dla danych — schemat, jednostki, zakres obowiązywania, źródło wartości i powiązanie z egzemplarzem. Dla ATE — sprzęt stanowiska, adapter, program testowy, limity, kalibrację i konfigurację badanego wyrobu.

W tym miejscu zarządzanie konfiguracją przestaje być ewidencją kolejnych numerów. Staje się kontrolą pochodzenia cyfrowych artefaktów i ich związku z fizycznym egzemplarzem — warunkiem, bez którego dalsza analiza buildu, wydania, instalacji i odtwarzalności nie może prowadzić do wiarygodnego dowodu zdolności.

Cyfrowe artefakty jako część konfiguracji wyrobu

Oprogramowanie wykonywalne nie jest samodzielną konfiguracją podsystemu elektronicznego. Jego zachowanie zależy równocześnie od rewizji sprzętu, bootloadera, firmware’u urządzeń peryferyjnych, obrazu FPGA, danych kalibracyjnych, danych konfiguracyjnych oraz reguł zgodności między tymi elementami. Z tego powodu kontrolowany pakiet cyfrowy powinien obejmować nie tylko plik ładowany do urządzenia, lecz cały zestaw wejść i wyników pozwalających ustalić pochodzenie oraz zakres ważności artefaktu:

• źródła oprogramowania, HDL i skryptów;
• kontrolowane wersje bibliotek, IP, systemu operacyjnego czasu rzeczywistego i innych zależności;
• konfigurację kompilatora, konsolidatora, syntezatora, narzędzi place-and-route i generatorów kodu;
• ograniczenia projektu FPGA, w tym przypisania i wymagania czasowe pozostające częścią kontrolowanej definicji;
• dane kalibracyjne związane z konkretnym czujnikiem albo egzemplarzem;
• dane konfiguracyjne określające zachowanie podsystemu bez zmiany kodu;
• obrazy wynikowe: plik wykonywalny, firmware, bitstream FPGA oraz pakiet danych;
• skrypty budowania, testowania, pakowania i instalacji;
• manifest identyfikujący skład pakietu, zależności, środowisko docelowe i zakres obowiązywania;
• wyniki kontroli integralności, raporty testów oraz zapis autoryzacji wydania.

NASA zaleca obejmowanie kontrolą konfiguracji między innymi kodu źródłowego, danych dostarczanego produktu, skryptów budowania i testowania, kompilatorów, konsolidatorów, systemów operacyjnych, narzędzi, baz danych oraz plików wykonywalnych. Oznacza to, że toolchain nie jest jedynie wyposażeniem warsztatu programisty. Jeżeli jego wersja lub ustawienie może zmienić wynik, staje się częścią dowodu pochodzenia buildu, nawet gdy organizacja nie nadaje każdemu narzędziu statusu odrębnej pozycji konfiguracji.^{zks2a-nasa-sci}

Manifest jest węzłem łączącym te artefakty. Powinien wskazywać co najmniej identyfikator wydania i buildu, identyfikatory wejść, wyniki budowania, docelowe rewizje sprzętu, wymagane wersje elementów współpracujących, schemat danych, ograniczenia użycia oraz odsyłacze do decyzji i dowodów weryfikacyjnych. Nie wystarcza lista nazw plików. Manifest ma odpowiadać na pytanie, dlaczego właśnie ten zestaw tworzy dopuszczoną konfigurację, a nie tylko co znalazło się w katalogu.

Hash kryptograficzny wiąże rekord z określoną zawartością pliku. Umożliwia wykrycie różnicy między kopią wzorcową a kopią przeznaczoną do instalacji, lecz sam nie wskazuje autora, organu zatwierdzającego ani przeznaczenia pliku. Podpis cyfrowy może dodatkowo potwierdzać pochodzenie i integralność w granicach przyjętego modelu zaufania, ochrony klucza oraz ważności certyfikatu. Nie dowodzi jednak, że podpisany kod spełnia wymagania, przeszedł kwalifikację albo jest właściwy dla danego egzemplarza. NIST rozdziela mechanizm weryfikacji integralności wydania od przechowywania danych o jego pochodzeniu i zaleca zachowanie zarówno plików wydania, jak i informacji integralnościowych oraz provenance.^{zks2a-nist-ssdf}

Dlatego relację dowodową należy czytać w dwóch kierunkach:

zatwierdzone źródła + zależności + toolchain + ustawienia
                         ↓
                    zapis buildu
                         ↓
        obrazy wynikowe + manifest + hash/podpis
                         ↓
           wydanie przeznaczone do określonego celu

oraz:

egzemplarz / moduł / stanowisko
            ↓
odczytany identyfikator i hash zainstalowanego obrazu
            ↓
manifest wydania i reguła zgodności
            ↓
baseline, decyzja zmiany i właściwe dowody kwalifikacyjne

Pierwszy kierunek wykazuje pochodzenie artefaktu, drugi przypisuje dowód do rzeczywistego obiektu. Żaden nie może zastąpić drugiego.

Powtarzalny build i granice identyfikatora

Identyfikator buildu jest etykietą konkretnego wyniku procesu. Może być unikatowy, a mimo to nieść niewiele informacji o tym, jak wynik uzyskano. Numer, znacznik czasu albo identyfikator commitu nie dowodzą, że zachowano właściwe biblioteki, komponenty, opcje kompilacji, generator plików, ustawienia lokalne i środowisko wykonawcze. Dwa buildy wykonane z tego samego commitu mogą różnić się wskutek innych wersji narzędzi, danych generowanych automatycznie, kolejności operacji lub niekontrolowanych wejść. Z kolei dwa różnie oznaczone buildy mogą zawierać bajtowo identyczny obraz.

Powtarzalność musi zatem zostać zdefiniowana jako kryterium i wykazana wynikiem. W najbardziej rygorystycznym wariancie ponowne wykonanie kontrolowanego procesu z zadeklarowanych wejść daje artefakt identyczny bajt po bajcie. Jeżeli właściwości użytego toolchainu nie pozwalają na taką identyczność, program powinien określić, które różnice są oczekiwane, jak są usuwane albo normalizowane na potrzeby porównania i jaki dodatkowy dowód potwierdza równoważność funkcjonalną. Nie wolno nazwać buildu powtarzalnym tylko dlatego, że skrypt zakończył się powodzeniem.

Minimalny zapis regeneracji powinien wiązać:

1. niezmienione, jednoznacznie zidentyfikowane wejścia;
2. wersje i konfiguracje wszystkich narzędzi mających wpływ na wynik;
3. czyste albo inaczej kontrolowane środowisko budowania;
4. pełny dziennik wykonania i wynik kontroli;
5. porównanie ponownie uzyskanego artefaktu z kopią wzorcową;
6. tożsamość osoby lub usługi wykonującej build oraz niezależnego sprawdzenia;
7. decyzję, według jakiego kryterium rezultat uznano za zgodny.

Opis wydania oprogramowania powinien zawierać elementy potrzebne do odtworzenia produktu: identyfikację źródeł i plików wykonywalnych, instrukcje kompilacji i konsolidacji, wymagania środowiska, procedury regeneracji oraz kontrole integralności. Wskazanie tych danych przez NASA pokazuje różnicę między zachowaniem gotowego obrazu a zachowaniem zdolności do jego kontrolowanego odtworzenia.^{zks2a-nasa-svd} Archiwalny plik pozwala ponownie załadować znany obraz; odtwarzalny proces pozwala przeanalizować błąd, wprowadzić zatwierdzoną poprawkę i wykazać pochodzenie nowego wyniku. Do wieloletniego utrzymania systemu potrzebne są obie zdolności.

Od anomalii do potwierdzonej zdolności

Spójny obieg zmiany zaczyna się od anomalii przypisanej do konfiguracji, a kończy nie na zatwierdzeniu dokumentu, lecz na potwierdzeniu stanu objętej zmianą populacji:

anomalia
→ analiza przyczyny
→ warianty rozwiązania
→ ECP
→ analiza wpływu
→ decyzja CCB
→ zmiana baseline’u
→ kwalifikacja
→ wydanie
→ wdrożenie
→ retrofit
→ potwierdzenie zdolności

Anomalia. Rekord problemu powinien utrwalić obserwację przed rozpoczęciem naprawy: konfigurację badanego egzemplarza, zainstalowane obrazy i dane, manifest, konfigurację urządzenia testowego, rewizję procedury, warunki próby, wyniki surowe i zakres zaobserwowanego skutku. Stwierdzenie „błąd występuje w wersji 4” jest zbyt szerokie, jeżeli wersja ta działa na kilku rewizjach sprzętu albo z kilkoma zestawami kalibracji. Właścicielem rekordu problemu może być zespół jakości lub system zgłoszeniowy, ale opis techniczny wymaga udziału użytkownika, integratora, zespołu oprogramowania, sprzętu i testów.

Analiza przyczyny. Celem nie jest znalezienie pliku, po którego wymianie objaw znika, lecz wyjaśnienie mechanizmu i populacji narażonej. Analiza porównuje konfigurację wadliwą z konfiguracją odniesienia, odtwarza zdarzenie, sprawdza historię zmian i rozdziela przyczynę od korelacji. Jeżeli anomalia pojawiła się po zmianie obrazu FPGA, możliwa przyczyna może znajdować się w kodzie HDL, ograniczeniach, wersji syntezatora, interfejsie z oprogramowaniem, danych albo nawet w procedurze testowej. Artefaktem decyzyjnym jest raport analizy przyczyny, wskazujący dowody, pozostałą niepewność i przewidywany zakres populacji.

Warianty rozwiązania. Zespół powinien zachować rozważane alternatywy, a nie tylko wybrane rozwiązanie. Wariantami mogą być korekta oprogramowania, firmware’u, obrazu FPGA, danych, sprzętu, procedury, testera albo ograniczenie użycia. Każdy wariant ocenia się pod kątem skuteczności, ryzyka ubocznego, czasu, kosztu, zachowania kwalifikacji, wpływu na interfejsy oraz możliwości wdrożenia w produkcji i flocie. Tak powstaje uzasadnienie wyboru, które później pozwala zrozumieć, dlaczego rozwiązania pozornie prostszego nie przyjęto.

ECP. Propozycja zmiany inżynierskiej przekształca wybrany wariant w kontrolowany przedmiot decyzji. Powinna identyfikować stan obecny i proponowany, dotknięte pozycje konfiguracji i dokumenty, powiązane zgłoszenia problemów, oba zakresy obowiązywania — produkcyjny i retrofitowy — a także zapasy, wyroby w toku, urządzenia testowe, dokumentację i szkolenie. Dla części cyfrowej ECP wskazuje planowane zmiany źródeł, danych, toolchainu i obrazów wynikowych oraz proponowany program regresji i kwalifikacji. ECP nie jest jeszcze poleceniem instalacji.

Analiza wpływu. System engineering prowadzi analizę w poprzek granic organizacyjnych. Zmiana jednej funkcji może oddziaływać na wymagania, harmonogramy czasowe interfejsów, obciążenie obliczeniowe, zachowanie diagnostyki, kalibrację, procedury produkcyjne, ATE, dokumentację obsługową i szkolenie. Szczególnie ważne jest rozstrzygnięcie ważności wcześniejszych dowodów: które wyniki pozostają reprezentatywne, które można zachować po analizie równoważności, a które próby trzeba powtórzyć. Odpowiedź „bez wpływu” jest wnioskiem wymagającym podstawy, nie domyślnym statusem.

Analiza wpływu powinna też ustalić, czy zmieniony element zachowuje zgodność z innymi składnikami łańcucha systemowego. Nie wystarcza, że nowy obraz działa na stanowisku deweloperskim. Trzeba ocenić współpracę z właściwą rewizją sprzętu, loaderem, urządzeniem testowym, pozostałym oprogramowaniem systemu oraz pakietem danych. Wynikiem jest macierz zależności i dowodów, a nie pojedynczy werdykt o „kompatybilności”.

Decyzja CCB. Configuration Control Board ocenia komplet ECP i analizy wpływu w granicach przyznanego mu upoważnienia. Właściciel techniczny uzasadnia rozwiązanie, przedstawiciele jakości i assurance oceniają dowody, produkcja i logistyka wykonalność, użytkownik konsekwencje operacyjne, a CM pilnuje jednoznaczności przedmiotu decyzji i późniejszej identyfikowalności. Protokół CCB powinien zachować dokładną rewizję ECP, decyzję, warunki, zakres obowiązywania, wymagane działania, odpowiedzialnych oraz kryteria zamknięcia.

Zatwierdzenie warunkowe nie może zostać zredukowane w ewidencji do pola „approved”. Jeżeli warunkiem jest zakończenie próby, kwalifikacja nowego narzędzia albo aktualizacja ATE, warunek pozostaje otwarty aż do pojawienia się wskazanego dowodu. NASA opisuje zmianę konfiguracji jako systematyczne proponowanie, uzasadnianie i ocenianie zmian, po którym następuje włączenie zatwierdzonej zmiany i weryfikacja jej wdrożenia; sama autoryzacja nie zamyka więc procesu.^{zks2a-nasa-cm}

Zmiana baseline’u. Po decyzji aktualizowane są kontrolowane źródła definicji produktu: wymagania, projekt, kod, dane, interfejsy, instrukcje budowania i dokumentacja testowa. Dopiero formalne wydanie tych danych tworzy nowy stan odniesienia. Protokół CCB nie zastępuje zmienionych plików, a zmieniony plik bez powiązania z decyzją nie tworzy autoryzowanego baseline’u. Ewidencja powinna zachować także poprzedni stan, ponieważ pozostaje on właściwy dla części floty i dla interpretacji historycznych wyników.

Kwalifikacja. Próba musi dotyczyć identyfikowalnej konfiguracji kandydującej, wykonanej według zatwierdzonego planu. Raport powinien wskazywać egzemplarz, sprzęt, software, firmware, obraz FPGA, dane, manifest, stanowisko, jego kalibrację, procedurę oraz odstępstwa. Jeżeli testowano artefakt roboczy, a później wykonano inny build produkcyjny, potrzebne jest porównanie albo ponowne sprawdzenie odpowiednie do różnicy. Sukces funkcjonalny nieznanego bitstreamu nie kwalifikuje później odtworzonego pliku tylko dlatego, że nadano mu tę samą nazwę.

Kwalifikacja nie musi oznaczać powtórzenia wszystkich prób systemu. Analiza wpływu może zachować dowody dotyczące niezmienionych funkcji i warunków. Musi jednak wskazać, dlaczego badana konfiguracja reprezentuje populację produkcyjną lub retrofitową. Dowód jest ważny dla określonego zestawu artefaktów i warunków, nie dla nazwy rodziny bez ograniczeń.

Wydanie. Po spełnieniu kryteriów release authority autoryzuje konkretny pakiet przeznaczony do określonego użycia. Pakiet obejmuje obrazy, manifest, hashe lub podpisy, instrukcję instalacji i weryfikacji, zgodne wersje loaderów, listę znanych problemów, ograniczenia, dokumentację oraz wskazanie dowodów dopuszczenia. NASA ujmuje release jako formalnie przygotowaną wersję przeznaczoną do wdrożenia, dostawy lub użycia operacyjnego i oddziela przygotowanie pakietu, jego utworzenie, dostarczenie oraz instalację.^{zks2a-nasa-release}

Wydanie cyfrowe oznacza, że istnieje autoryzowany pakiet możliwy do dystrybucji. Nie oznacza, że został on załadowany do któregokolwiek egzemplarza. Repozytorium może zatem prawidłowo wskazywać najnowsze wydanie, podczas gdy flota prawidłowo pozostaje na wcześniejszym, nadal obowiązującym stanie.

Wdrożenie. W produkcji wdrożenie obejmuje udostępnienie właściwych danych na stanowiskach, wycofanie kopii zastąpionych, aktualizację programatorów i testerów, przeszkolenie personelu oraz potwierdzenie pierwszego wykonania według nowego pakietu. W eksploatacji jest to kontrolowana instalacja w konkretnym module lub egzemplarzu. Log instalacji powinien zapisać stan wejściowy, użyty pakiet, wynik kontroli integralności, operatora lub stanowisko, czas, rezultat weryfikacji oraz stan po wykonaniu.

Retrofit. Zmiana już dostarczonej populacji wymaga osobnej kampanii. Jej zakres może być węższy lub szerszy od zakresu produkcyjnego, ponieważ uwzględnia rzeczywisty stan egzemplarzy, wcześniejsze modyfikacje, dostępność zestawów, harmonogram obsług i ograniczenia użytkownika. Pakiet retrofitowy łączy części fizyczne, artefakty cyfrowe, instrukcję, wymagane narzędzia, test po wykonaniu i sposób aktualizacji oznaczeń oraz ewidencji. Status kampanii musi być prowadzony dla egzemplarzy, nie tylko dla wysłanych pakietów.

Potwierdzenie zdolności. Zamknięcie następuje dopiero po wykazaniu, że zmieniona konfiguracja została prawidłowo wcielona, przeszła wymagane sprawdzenia, znalazła się w aktualnym rekordzie as-maintained i spełnia kryteria ustanowione przez organ odpowiedzialny za dopuszczenie lub gotowość. DoD wymaga w ewidencji konfiguracji rozróżniania zakresu obowiązywania, statusu instalacji i statusu wdrożenia autoryzowanych zmian; dzięki temu zatwierdzona zmiana nie jest mylona ze zmianą obecną w całej populacji.^{zks2a-dod-csa}

Cztery decyzje, których nie wolno scalać

W praktyce ten sam numer ECP może występować równocześnie w czterech prawdziwych, lecz różnych zapisach:

Stan	Co zostało rozstrzygnięte	Typowy dowód	Czego stan nie dowodzi
zmiana zatwierdzona	wolno zmienić wskazany baseline na określonych warunkach	decyzja i protokół CCB	że istnieje gotowy pakiet albo zmieniono egzemplarz
wydanie cyfrowe autoryzowane	konkretny manifest i zestaw artefaktów wolno dostarczać do wskazanego celu	zatwierdzony opis wydania, manifest, hash/podpis	że pakiet zainstalowano
zmiana wcielona fizycznie lub programowo	wskazany egzemplarz otrzymał części, obrazy i dane	zlecenie wykonania, log loadera, zapis as-built lub as-maintained	że wynik instalacji zaakceptowano operacyjnie
status operacyjny przyznany	egzemplarz lub zestaw spełnia aktualne kryterium użytkowe	wynik kontroli po wdrożeniu i decyzja właściwego organu	że cała flota ma ten sam stan

Role mogą być rozdzielone między zamawiającego, projektanta, producenta, integratora, assurance, jednostkę obsługową i użytkownika. W konkretnym programie jedna instytucja może wykonywać kilka ról, lecz ewidencja nadal powinna zachować odrębność decyzji. Podpis przewodniczącego CCB nie może zostać użyty jako zastępczy dowód poprawnej instalacji, podobnie jak pozytywny test techniczny nie zastępuje decyzji o statusie operacyjnym.

Effectivity i flota mieszana

Zakres obowiązywania zmiany powinien być opisany przez cechy rzeczywiście rozróżniające populację. Numer seryjny identyfikuje egzemplarz, partia wiąże go z przebiegiem produkcji, a wariant i blok odnoszą go do określonej definicji produktu. Żaden z tych identyfikatorów użyty osobno nie musi wystarczyć. Przedział numerów seryjnych jest zawodny, gdy produkcja nie przebiegała liniowo, egzemplarze wracały do naprawy albo modyfikację wcielano przy różnych okazjach. Partia nie opisuje późniejszych wymian modułów, natomiast identyfikator wariantu może obejmować kilka legalnych stanów modernizacji.

Effectivity może więc przyjąć postać reguły złożonej, na przykład: określony wariant, wskazane partie lub egzemplarze, właściwa rewizja modułu, brak wcześniejszej modyfikacji kolidującej i określony stan oprogramowania bazowego. Jest to reguła selekcji populacji, nie luźna uwaga w instrukcji.

Dla jednej ECP należy rozdzielić co najmniej:

• effectivity produkcyjną — od którego rzeczywistego przebiegu produkcji obowiązuje nowa definicja;
• effectivity retrofitową — które dostarczone egzemplarze kwalifikują się do modernizacji;
• effectivity dokumentacji — dla jakich stanów przeznaczona jest dana rewizja instrukcji;
• effectivity dowodów — które konfiguracje i warunki obejmuje wynik kwalifikacji;
• effectivity operacyjną — w jakiej konfiguracji oraz z jakimi ograniczeniami wyrób może otrzymać określony status użytkowy.

Flota mieszana nie jest automatycznie flotą niezgodną. Starsza konfiguracja może pozostawać zatwierdzona, nowsza może być wdrażana w produkcji, część egzemplarzy może oczekiwać na retrofit, a część przechodzić kontrolę po instalacji. Problemem jest dopiero brak możliwości rozróżnienia tych populacji albo przypisanie im wspólnej zdolności bez właściwych dowodów.

Ewidencja stanu konfiguracji powinna dlatego pozwalać przejść od ECP do listy objętych egzemplarzy i w kierunku odwrotnym — od numeru seryjnego do obowiązującego baseline’u, zainstalowanego manifestu, odstępstw, wykonanych modyfikacji, ograniczeń i ważnych wyników kontroli. NASA wskazuje, że CSA ma utrzymywać stan produktów i powiązanych wniosków zmian oraz identyfikować zawartość wersji i wydań; oficjalne doświadczenia NASA podkreślają również potrzebę raportowania effectivity i statusu instalacji zmian we wszystkich lokalizacjach.^{zks2a-nasa-csa}

Od definicji cyfrowej do dowodu produkcyjnego

Po wydaniu nowego baseline’u pytanie zmienia się z „czy projekt jest poprawny?” na „czy proces wytwarza i utrzymuje właśnie ten projekt?”. Dowód produkcyjny powinien połączyć cyfrową definicję z konkretnym wyrobem. Obejmuje to kontrolowaną instrukcję pracy, identyfikację programu maszyny lub pliku produkcyjnego, zapis programowania urządzeń, użyte obrazy i dane, partie komponentów, wyniki procesów specjalnych, status kalibracji wyposażenia, zaakceptowane niezgodności oraz wyniki kontroli i odbioru.

Dla egzemplarza z programowalną elektroniką rekord as-built powinien umożliwiać ustalenie nie tylko numeru części modułu, lecz również manifestu zainstalowanych artefaktów. Jeżeli kalibracja jest indywidualna, jej zestaw danych musi być związany z numerem seryjnym czujnika lub modułu oraz chroniony przed przypadkowym użyciem w innym egzemplarzu. Jeżeli kilka sztuk zaprogramowano wspólnie, rekord partii operacji powinien prowadzić do wszystkich objętych numerów seryjnych i do wzorca obrazu użytego przez stanowisko.

Pierwszy zgodny egzemplarz nie dowodzi jeszcze trwałej zgodności produkcji. Potrzebne są zapisy kolejnych wykonań, kontroli procesu, niezgodności, napraw i zmian dostawców. Dopiero ich ciągłość pozwala rozstrzygnąć, czy późniejszy wyrób nadal reprezentuje konfigurację objętą kwalifikacją. To samo dotyczy cyfrowego stanowiska produkcyjnego: lokalna kopia obrazu, zmieniony skrypt albo niezatwierdzona aktualizacja programatora mogą zerwać łańcuch dowodowy mimo braku zmiany na rysunku sprzętu.

W eksploatacji odpowiednikiem zapisu as-built jest aktualizowany zapis as-maintained. Każda wymiana modułu, instalacja obrazu, zmiana danych, naprawa, odstępstwo i przywrócenie poprzedniego wydania zmienia konfigurację egzemplarza albo wiedzę o niej. Rekord obsługowy powinien zachować stan przed czynnością, autoryzację, użyte części i artefakty, wynik sprawdzenia po wykonaniu oraz decyzję o dalszym statusie. Wynik BIT może być jednym z dowodów technicznych, ale nie zastępuje identyfikacji konfiguracji ani szerszych kryteriów powrotu do użytkowania.

Łańcuch można więc rozszerzyć bez utraty jego logiki:

baseline produktu
→ kontrolowane dane produkcyjne
→ zapis procesu i programowania
→ konfiguracja as-built
→ odbiór i dostawa
→ działania obsługowe oraz retrofit
→ konfiguracja as-maintained
→ bieżące wyniki kontroli i ograniczenia
→ status operacyjny w określonej chwili

Zdolność przypisana egzemplarzowi wynika z przecięcia tych zapisów. Manifest i hash wykazują tożsamość artefaktu; raport buildu — jego pochodzenie; decyzja CCB — autoryzację zmiany; raport kwalifikacji — spełnienie określonych wymagań przez reprezentowaną konfigurację; zapis produkcyjny lub obsługowy — wcielenie jej do konkretnego egzemplarza; kontrola po wdrożeniu i decyzja właściwego organu — aktualny status użytkowy. Dopiero połączenie tych dowodów pozwala przejść od konfiguracji projektowanej do rzeczywistej konfiguracji floty.

Od artefaktu produkcyjnego do dowodu zgodności

Kontrolowany build, rysunek albo wykaz materiałowy opisuje rozwiązanie, lecz nie dowodzi jeszcze, że powstał odpowiadający mu wyrób. Przejście do produkcji wymaga połączenia definicji produktu z zapisami wykonania: zleceniem produkcyjnym, wersją instrukcji, partiami materiałów, źródłami części, stanem wyposażenia, kwalifikacjami procesów, wynikami kontroli oraz rejestrem poprawek. Dopiero taki pakiet pozwala porównać konfigurację as-built z właściwym produktowym punktem bazowym.

Dowód produkcyjny powinien odpowiadać na trzy oddzielne pytania:

1. czy projekt spełnia ustanowione wymagania;
2. czy proces potrafi powtarzalnie wytworzyć projekt;
3. czy konkretny egzemplarz albo partia rzeczywiście odpowiadają projektowi i przeszły przypisane im kontrole.

Pomyślna odpowiedź na jedno z nich nie przenosi się automatycznie na pozostałe. Próba kwalifikacyjna reprezentatywnego zespołu może potwierdzić projekt, lecz nie jakość wykonania każdej sztuki. Kontrola pierwszego wyrobu może wykazać zgodność cech z dokumentacją, ale nie zastępuje walidacji zastosowania systemowego. Odbiór egzemplarza nie rozszerza z kolei zakresu kwalifikacji na nieprzebadany wariant.

Ta granica jest szczególnie ważna w systemie rakietowym, ponieważ wynik produkcji obejmuje więcej niż materiałowy skład pocisku. Produktem są również zainstalowane obrazy programowe, kalibracje, zapisy procesów, konfiguracja urządzenia testowego, dokumentacja dostawy oraz ograniczenia dotyczące zgodności z pozostałymi elementami zestawu. Egzemplarz może być wolny od wad wykonawczych, a mimo to nie należeć do konfiguracji, dla której wykazano zdolność systemową.

Weryfikacja, walidacja i kwalifikacja

Weryfikacja ustala, czy produkt spełnia wyspecyfikowane wymagania. Jej metodą może być test, analiza, inspekcja albo demonstracja. Każdy wynik powinien wskazywać wymaganie, kryterium, badaną konfigurację, metodę, warunki, użyte wyposażenie, niepewność oraz zatwierdzoną decyzję. Macierz śledzenia, w której przy wymaganiu wpisano jedynie „test zakończony”, nie pozwala ustalić, czy wynik dotyczył właściwego wariantu i czy wszystkie kryteria zostały spełnione.

Walidacja odpowiada na inne pytanie: czy otrzymany system jest odpowiedni do zamierzonego zastosowania i oczekiwanego sposobu użycia. Odnosi wynik do koncepcji operacyjnej, użytkownika, realistycznego środowiska i całego łańcucha systemowego. Można poprawnie zweryfikować każdy interfejs względem jego specyfikacji, a następnie podczas walidacji odkryć, że opóźnienia sumowane przez kilka zgodnych elementów utrudniają wykonanie funkcji na poziomie systemu. NASA Systems Engineering Handbook rozdziela te procesy właśnie według relacji do wymagań i oczekiwanego zastosowania; jest jednak podręcznikiem NASA, a nie samodzielnym wymaganiem dla programu obronnego. W programie wojskowym obowiązek, zakres i organ akceptujący muszą wynikać z właściwych dokumentów programu lub umowy.^{zks2b-nasa-vv}

Kwalifikacja jest częścią strategii dowodowej projektu. Ma wykazać, że określona konfiguracja projektu zachowa wymagane funkcje w ustanowionym zakresie warunków, zwykle z przyjętymi marginesami. Nie jest nazwą dowolnej próby środowiskowej. Raport musi określać pochodzenie obiektu kwalifikacyjnego, jego zgodność z konfiguracją produkcyjną, sekwencję narażeń, kryteria, odstępstwa od procedury i wszystkie anomalie. Wynik obowiązuje tylko w granicach badanego projektu i uzasadnionych podobieństw. Zmiana części, procesu, narzędzia budowania albo interfejsu nie wymaga automatycznie powtórzenia całego programu, lecz wymaga udokumentowanej oceny ważności dotychczasowego dowodu.

Odbiór produkcyjny dotyczy natomiast egzemplarza lub partii. Jego celem jest potwierdzenie, że wykonanie i podstawowe działanie odpowiadają wcześniej zweryfikowanemu i zakwalifikowanemu projektowi. Z tego powodu kryteria odbioru mogą być węższe niż program kwalifikacyjny, a próby niszczące nie są powtarzane na każdej sztuce. NASA ujmuje tę różnicę jako kwalifikację projektu i odbiór kolejnych jednostek produkcyjnych, którym towarzyszą indywidualne pakiety danych odbiorczych.^{zks2b-nasa-acceptance} W systemie obronnym konkretna strategia próbkowania, badań stuprocentowych i nadzoru partii pozostaje jednak sprawą wymagań technicznych i jakościowych danego programu.

FCA, PCA i FAI — trzy różne granice

Audyt funkcjonalny konfiguracji (Functional Configuration Audit, FCA) bada, czy rzeczywiste charakterystyki funkcjonalne pozycji konfiguracji albo systemu osiągnęły wymagania zapisane we właściwej dokumentacji funkcjonalnej lub przydzielonej. Jego zasadniczym materiałem są zatwierdzone wymagania, macierz weryfikacji, raporty prób i analiz, wykaz otwartych niezgodności oraz decyzje zamykające. FCA ocenia zebrany dowód; nie jest synonimem pojedynczej próby i nie zastępuje walidacji operacyjnej. MIL-HDBK-61B wyraźnie odróżnia FCA od wyników prób operacyjnych oraz dopuszcza prowadzenie audytu złożonego systemu w kolejnych przyrostach.^{zks2b-mil-fca}

Audyt fizyczny konfiguracji (Physical Configuration Audit, PCA) porównuje reprezentatywny produkt z dokumentacją konfiguracji produktu. Sprawdza, czy dokumentacja odpowiada projektowi rzeczywiście przeznaczonemu do dostaw i utrzymania, a także czy można na niej oprzeć produktowy punkt bazowy. Obejmuje sprzęt, oprogramowanie i właściwe artefakty wytwarzania, lecz nie jest kontrolą wszystkich sztuk. MIL-HDBK-61B wskazuje też możliwość ponownego PCA po wieloletnim zatrzymaniu linii albo przeniesieniu produkcji do nowego wykonawcy. Podręcznik pozostaje wskazówką DoD i sam nie ustanawia obowiązku kontraktowego; wymaganie FCA lub PCA musi zostać przywołane w zadaniu, umowie albo innym dokumencie właściwym dla programu.^{zks2b-mil-pca}

Kontrola pierwszego wyrobu (First Article Inspection, FAI) ma granicę produkcyjną. SAE AS9102C ustanawia wymagania wykonywania i dokumentowania FAI, podkreślając, że uzupełniają one — a nie zastępują — wymagania klienta, prawa i regulacji.^zks2b-as9102 FAI dostarcza obiektywnego zapisu, że pierwsza reprezentatywna realizacja określonego procesu produkcyjnego została skonfrontowana z cechami definicji produktu. Może zostać uruchomiona przez rozpoczęcie produkcji, istotną zmianę albo odtworzenie zdolności wytwarzania, jeżeli tak stanowią zastosowane wymagania.

FAI nie jest FCA, ponieważ nie audytuje kompletnego dowodu osiągnięcia wymagań funkcjonalnych. Nie jest PCA, ponieważ nie służy ustanowieniu całego produktowego punktu bazowego. Nie jest też kwalifikacją projektu ani rutynowym odbiorem każdej następnej sztuki. Te działania mogą korzystać z części wspólnych danych, lecz organ decyzji, kryterium i zakres wniosku pozostają różne.

Działanie	Główne pytanie	Typowy przedmiot decyzji	Czego nie zastępuje
weryfikacja	czy spełniono wyspecyfikowane wymaganie?	zamknięcie wymagania dla wskazanej konfiguracji	walidacji zastosowania
walidacja	czy system jest właściwy do zamierzonego użycia?	akceptacja przydatności w określonym kontekście	zgodności każdej sztuki
kwalifikacja	czy projekt działa w ustanowionym zakresie i z wymaganym marginesem?	dopuszczenie konfiguracji projektu	odbioru produkcyjnego
FCA	czy dowody potwierdzają wymagane charakterystyki funkcjonalne?	zamknięcie audytu funkcjonalnego CI lub systemu	PCA i prób operacyjnych
PCA	czy produkt reprezentatywny i dokumentacja produktu są zgodne?	ustanowienie lub potwierdzenie PBL	inspekcji wszystkich egzemplarzy
FAI	czy pierwszy reprezentatywny wyrób realizuje cechy definicji produktu?	akceptacja udokumentowanej realizacji procesu	kwalifikacji i FCA
odbiór	czy egzemplarz lub partia odpowiadają dopuszczonemu projektowi?	przyjęcie, odrzucenie albo ograniczenie dostawy	dowodu dla nowego projektu

Proces produkcyjny, dostawca i dane techniczne

Cechy, których nie można w pełni potwierdzić na gotowym wyrobie bez jego zniszczenia albo nieproporcjonalnego demontażu, wymagają kontroli procesu. W takich przypadkach dowodem nie jest wyłącznie końcowy wynik pomiaru, lecz także zatwierdzona procedura, stan urządzeń, właściwa rewizja parametrów, identyfikacja operatora, kwalifikacja procesu, pochodzenie materiałów, zapisy przebiegu i decyzja o zgodności. Oficjalne wymagania NASA dotyczące jakości sprzętu wskazują kwalifikację procesu tam, gdzie późniejsza kontrola produktu nie wystarcza do ograniczenia ryzyka wad ukrytych.^{zks2b-nasa-process}

Proces specjalny należy traktować jako kontrolowany składnik sposobu realizacji projektu, nie jako nazwę technologii w planie jakości. Zmiana zakładu, linii, urządzenia, materiału pomocniczego, podwykonawcy lub istotnej instrukcji może naruszyć podstawę kwalifikacji procesu nawet wtedy, gdy numer części pozostaje bez zmian. Decyzja wymaga porównania zakresu zmiany z granicami poprzedniego dowodu: czasem wystarczy analiza i kontrola pierwszego wyrobu, czasem potrzebna jest częściowa rekwalifikacja procesu, a czasem również kwalifikacja produktu.

Podobnie należy traktować zmianę źródła dostaw. Katalogowa zgodność formy, dopasowania i deklarowanej funkcji nie dowodzi równoważności zachowania w pełnym zakresie systemowym. Inne źródło może oznaczać odmienne materiały, proces, rozrzut parametrów, tryby uszkodzeń, trwałość, ograniczenia środowiskowe albo zasady identyfikowalności. Nie każda zmiana dostawcy jest zmianą projektu, lecz każda wymaga sklasyfikowania wpływu i zachowania zapisu decyzji.

Minimalny pakiet oceny zmiany źródła powinien obejmować:

• identyfikację starego i nowego źródła oraz dokładnych wyrobów;
• porównanie kontrolowanych wymagań, a nie tylko kart handlowych;
• wpływ na interfejsy, procesy, naprawy, testy i zapasy;
• ocenę ważności wcześniejszej kwalifikacji;
• plan kontroli pierwszego wyrobu i odbioru;
• zakres obowiązywania według partii, numerów seryjnych lub dat;
• aktualizację wykazu zatwierdzonych źródeł i danych technicznych;
• decyzję organu mającego władzę nad dotkniętym punktem bazowym.

Pakiet danych technicznych (technical data package, TDP) musi być wystarczający dla roli, jaką ma pełnić państwo, integrator albo zakład remontowy. Dostęp do ekranu systemu dostawcy nie jest równoważny dostarczeniu danych ani uzyskaniu praw potrzebnych do ich późniejszego użycia. MIL-HDBK-61B ostrzega przed zastępowaniem dostawy samym dostępem i wskazuje potrzebę oceny treści, formatu oraz oznaczeń praw do danych przed przyjęciem pakietu.^{zks2b-mil-data} Brak właściwej kopii, środowiska narzędziowego lub praw może ujawnić się dopiero po zakończeniu kontraktu, gdy trzeba odtworzyć produkcję, zmienić dostawcę albo zbadać starą konfigurację.

Eksploatacja, naprawa i stan as-maintained

Po dostawie zapis as-built staje się początkiem historii egzemplarza, nie jej zakończeniem. Każda wymiana modułu, naprawa, aktualizacja oprogramowania, korekta kalibracji, ograniczenie użytkowania i wykonany retrofit mogą zmienić stan as-maintained. Rekord powinien wiązać czynność z numerem seryjnym, użytymi częściami i wydaniami, podstawą techniczną, wykonawcą, wynikami kontroli po pracy oraz decyzją o przywróceniu do określonego statusu.

Naprawa odtwarzająca wyrób według obowiązującej dokumentacji nie musi ustanawiać nowego projektu. Jeśli jednak zmienia materiał, geometrię, interfejs, zachowanie albo metodę wytwarzania poza zatwierdzony zakres, staje się zagadnieniem konfiguracji i wymaga właściwej decyzji inżynierskiej. Dokumentacja naprawy nie może zastępować ECP tam, gdzie w istocie tworzona jest trwała alternatywa projektowa.

Terminy deviation i waiver bywają w programach rozdzielane według tego, czy zgodę uzyskuje się przed wykonaniem niezgodnego wyrobu, czy akceptuje istniejącą niezgodność. Nie jest to jednak bezpieczna definicja uniwersalna. Aktualny MIL-HDBK-61B stosuje nadrzędny termin request for variance — wniosek o zgodę na odstąpienie od definicji produktu dla wskazanej sztuki, liczby sztuk albo okresu bez zmiany samej definicji produktu.^{zks2b-mil-rfv} Program powinien więc jawnie zdefiniować lokalne użycie słów deviation i waiver, właściwy organ oraz wymagane formularze.

Niezależnie od nazwy zatwierdzone odstępstwo:

• nie zmienia automatycznie produktowego punktu bazowego;
• nie ustanawia zamienności;
• nie przenosi się na następną partię bez nowej podstawy;
• musi wskazywać dotkniętą populację, wymaganie, uzasadnienie i ograniczenia;
• pozostaje częścią zapisu as-built lub as-maintained;
• musi zostać uwzględnione przy ocenie ważności prób, obsługi i późniejszej modernizacji.

Powtarzające się wnioski o to samo odstępstwo są sygnałem, że problem przestał być zdarzeniem jednostkowym. Organ decyzyjny powinien wówczas rozstrzygnąć, czy należy poprawić proces, odrzucić populację, zmienić wymaganie albo uruchomić ECP. Utrwalanie alternatywnego projektu serią waiverów usuwałoby zmianę spod normalnej analizy wpływu.

DMSMS, zamienniki i modernizacja wieloletnia

DMSMS obejmuje utratę albo zbliżającą się utratę producentów i dostawców części, materiałów lub oprogramowania. DoD wymaga podejścia proaktywnego i opartego na ryzyku w całym cyklu życia, z oceną wpływu między innymi na harmonogram i gotowość oraz z wyborem i wdrożeniem rozwiązania.^zks2b-dmsms Problem nie zaczyna się więc w dniu wyczerpania magazynu. Powinien zostać wykryty wystarczająco wcześnie, aby zachować alternatywę między zakupem końcowym, naprawą, zmianą źródła, zastąpieniem elementu, odtworzeniem zdolności albo przeprojektowaniem.

„Zamiennik” nie jest własnością samego komponentu. Jest relacją między nowym elementem, jego zastosowaniem, interfejsami i dowodem. Część o lepszych parametrach katalogowych może mieć inną charakterystykę czasową, pobór energii, zachowanie podczas rozruchu, odpowiedź na diagnostykę albo inny profil starzenia. Ocena musi sięgać tak wysoko w strukturze systemu, jak wysoko może propagować się skutek różnicy.

Każdy przypadek DMSMS powinien zakończyć się kontrolowanym rekordem zawierającym wykryte zagrożenie, dotknięte pozycje konfiguracji i populacje, przewidywany termin wpływu, warianty rozwiązania, kryteria wyboru, koszt cyklu życia, potrzebne dane i prawa, plan kwalifikacji oraz zakres wdrożenia. Sam zakup zapasu może odsunąć termin, ale nie rozwiązuje problemu narzędzi, wiedzy, testerów ani zdolności naprawczych.

Modernizacja wieloletnia tworzy flotę mieszaną. Przez część okresu eksploatacji równolegle istnieją egzemplarze przed zmianą, po zmianie, oczekujące na retrofit, czasowo ograniczone i pozostające w naprawie. Ewidencja musi pozwalać określić nie tylko procent realizacji programu, lecz także zgodność każdego egzemplarza z wyrzutnią, ATE, częściami zamiennymi, dokumentacją i kwalifikacjami personelu. Dopiero taka informacja pozwala odróżnić wykonanie prac od odzyskania zdolności.

ATE, dokumentacja, szkolenie i gotowość jednostki

Automatyczne urządzenie testowe jest częścią toru dowodowego. Wynik zależy od sprzętu ATE, adaptera, programu testowego, limitów, kalibracji, symulowanych interfejsów oraz reguły interpretacji danych. Raport „PASS” bez identyfikacji tych składników nie dowodzi, że egzemplarz sprawdzono według kryteriów właściwych dla jego wariantu.

Zmiana produktu powinna więc prowadzić do jednej z trzech jawnych decyzji: istniejący ATE pozostaje właściwy i zachowano dowód tej równoważności; ATE wymaga kontrolowanej aktualizacji; albo dotychczasowa metoda nie jest już zdolna do wiarygodnego odbioru i trzeba ustanowić inną. Zaktualizowanie programu testowego bez zmiany instrukcji, danych szkoleniowych i macierzy zgodności pozostawia dwa sprzeczne źródła decyzji.

Dokumentacja eksploatacyjna ma własną konfigurację i zakres obowiązywania. Instrukcja dla nowego bloku nie może zostać po prostu oznaczona jako „aktualna”, jeżeli jednostka utrzymuje również starsze egzemplarze. Potrzebne są identyfikatory zastosowania, stan zmian, wykaz stron lub modułów dotkniętych aktualizacją, data wejścia w życie i mechanizm wycofania kopii nieobowiązujących.

Szkolenie jest składnikiem dowodu wtedy, gdy zmiana wpływa na rozpoznanie wariantu, wykonanie obsługi, interpretację wskazań albo decyzję o dopuszczeniu. Lista obecności potwierdza udział, nie kompetencję. Zapis powinien wiązać program szkolenia z konfiguracją, wymaganymi rolami, wynikiem sprawdzenia i okresem ważności uprawnienia.

Gotowość jednostki nie wynika z samej liczby sprawnych pocisków. Wymaga przecięcia co najmniej konfiguracji środków bojowych, wyrzutni, systemu dowodzenia, ATE, dokumentacji, części zamiennych, kwalifikacji personelu oraz aktualnych ograniczeń. MIL-HDBK-61B umieszcza w ewidencji fazy eksploatacyjnej konfiguracje sprzętu wsparcia, trenerów, materiałów szkoleniowych, instrukcji i oprogramowania potrzebnych w poszczególnych lokalizacjach.^{zks2b-mil-support} Jest to model informacji CM, nie uniwersalna metryka gotowości; decyzję operacyjną podejmuje właściwy organ według kryteriów użytkownika.

Pochodzenie buildu i zmiana awaryjna

Dowód pochodzenia buildu powinien łączyć zatwierdzone źródła, zależności, narzędzia, ustawienia, tożsamość wyniku, przeglądy, wynik testów i pakiet wydania. Skrót kryptograficzny pomaga potwierdzić identyczność artefaktu, lecz nie dowodzi, że artefakt jest bezpieczny albo dopuszczony. Podpis potwierdza związek z określonym kluczem i procesem, ale jego wartość zależy od ochrony klucza, zasad zatwierdzania i wiarygodności środowiska budowania.

NIST Secure Software Development Framework zaleca ochronę wszystkich postaci kodu przed nieuprawnionym dostępem i zmianą, archiwizowanie danych niezbędnych do pochodzenia wydań oraz weryfikowanie integralności informacji pochodzących od dostawców.^zks2b-ssdf Rządowe zalecenia dotyczące łańcucha dostaw oprogramowania wskazują ponadto potrzebę oceny komponentów zewnętrznych, znanego pochodzenia obrazów oraz utrzymywania artefaktów opisujących skład i proces rozwoju.^{zks2b-supply-chain} W systemie rakietowym zasady te trzeba połączyć z klasycznym CM: zatwierdzony cyfrowo plik musi nadal mieć zgodność z konkretnym urządzeniem, wariantem i zakresem kwalifikacji.

Zmiana awaryjna nie może oznaczać zmiany niekontrolowanej. Powinna korzystać z wcześniej ustanowionej ścieżki skróconej: określonego organu, ograniczonego zakresu, udokumentowanej analizy ryzyka, kontrolowanego buildu, minimalnego zestawu prób przed wdrożeniem, jednoznacznej populacji, monitorowania wyniku oraz obowiązkowego przeglądu po wdrożeniu. NIST SP 800-128 obejmuje zmianami konfiguracyjnymi również zmiany awaryjne i nieplanowane, wymagając oceny wpływu bezpieczeństwa także wtedy, gdy pełną analizę trzeba domknąć po pilnym wykonaniu.^{zks2b-nist-emergency}

Nie należy publikować szczegółów mechanizmów autoryzacji, kluczy, sekwencji serwisowych ani sposobów omijania kontroli. Dla dowodu CM wystarczy wykazać, że pakiet przeszedł właściwą ścieżkę, został dostarczony kanałem przewidzianym przez program, zainstalowano go na wskazanej populacji, a wynik potwierdzono. Pilność może skrócić czas decyzji; nie może wymazać tożsamości decyzji i artefaktów.

Przypadek anomalii: od objawu do potwierdzonej zdolności

Rozważmy neutralny przypadek fikcyjnego modułu interfejsowego, produkowanego przez wiele lat. Po zmianie źródła jednego z elementów elektronicznych część nowej partii przechodzi kontrolę stanowiskową, lecz podczas zintegrowanej próby środowiskowej pojawia się sporadyczne opóźnienie inicjalizacji. Nie opisuje ono rzeczywistego systemu ani parametrów umożliwiających identyfikację podatności; służy wyłącznie pokazaniu obiegu dowodu.

1. Rejestracja objawu. Raport anomalii identyfikuje numery seryjne modułów, partię, konfigurację badanego systemu, build oprogramowania, ATE, procedurę, warunki i surowe zapisy czasu. Pierwsza decyzja brzmi: zatrzymać wydanie wskazanej partii i nie rozszerzać wniosku na starszą populację bez danych. Artefaktem jest zatwierdzony raport problemu wraz z regułą zabezpieczenia materiału dowodowego.

2. Wyznaczenie populacji. Zapytanie do CSA łączy numery seryjne z partiami komponentu, datami produkcji, źródłami dostaw i wynikami wcześniejszych testów. Powstaje tymczasowa effectivity: moduły z określonych partii wyprodukowane po zmianie źródła. Decyzja organu konfiguracji utrzymuje blokadę tej populacji, pozostawiając inne egzemplarze w dotychczasowym statusie. Artefaktem jest podpisany wykaz populacji z datą i wersją zapytania.

3. Ustalenie przyczyny. Kontrolowane badanie porównawcze wykazuje, że nowy element spełnia własną kartę katalogową, lecz jego zachowanie przejściowe różni się od poprzedniego w obszarze, którego nie zapisano w specyfikacji zakupowej. Raport analizy przyczyny oddziela przyczynę fizyczną od przyczyny systemowej: różnica komponentu ujawniła niekontrolowane założenie interfejsowe, a proces zatwierdzania nowego źródła nie badał tej cechy. Decyzja techniczna odrzuca samo przywrócenie starego dostawcy jako pełne rozwiązanie, ponieważ pozostawiłoby wadę definicji produktu.

4. ECP. Propozycja zmiany ustanawia jawne wymaganie dla zachowania interfejsu, odpowiednią zmianę projektu oraz aktualizacje specyfikacji zakupowej, wykazu źródeł, metody odbioru, programu ATE, dokumentacji i szkolenia. Zawiera analizę wpływu na sąsiednie CI, oprogramowanie, dane i wcześniejsze dowody. CCB zatwierdza ECP warunkowo: wydanie produkcyjne może nastąpić dopiero po zamknięciu wskazanej kwalifikacji i kontroli pierwszego wyrobu. Artefaktami są ECP, protokół decyzji oraz macierz dotkniętych dokumentów.

5. Kwalifikacja zmiany. Plan kwalifikacji przypisuje każde zmienione lub potencjalnie naruszone wymaganie do testu, analizy albo inspekcji. Obejmuje reprezentatywny zakres warunków i próbę zintegrowaną, ale nie powtarza badań niezależnych od zmiany, jeśli analiza zachowała dla nich ważność. Raport kwalifikacyjny zapisuje konfigurację obiektu, ATE, buildy, odchylenia od planu i wyniki regresji. Organ techniczny kwalifikuje dokładnie wskazaną parę rewizji sprzętu i wydania oprogramowania; nie nadaje wyniku całej rodzinie modułów.

6. Wdrożenie produkcyjne. Zostają wydane nowe rewizje rysunków, wykazu materiałowego, instrukcji pracy, planu kontroli i specyfikacji dostawcy. FAI na pierwszym reprezentatywnym wyrobie potwierdza realizację cech definicji produktu i użycie zatwierdzonego procesu. Decyzja jakościowa zezwala na wznowienie produkcji od wskazanej partii, a CSA zapisuje rzeczywisty punkt rozpoczęcia zmiany. Artefaktami są raport FAI, rekordy procesu, świadectwa materiałowe i zatwierdzenie wydania produkcyjnego.

7. Decyzja dla istniejącej populacji. Analiza numerów seryjnych dzieli flotę na egzemplarze niewymagające działania, podlegające kontroli, przeznaczone do modyfikacji oraz czasowo ograniczone. Biuletyn modyfikacyjny określa effectivity i wymagane potwierdzenie po pracy. Organ eksploatacyjny zatwierdza kolejność realizacji na podstawie ryzyka i dostępności zestawów, nie zmieniając statusu egzemplarza przed otrzymaniem zapisu wykonania. Artefaktem jest kontrolowany plan populacyjny.

8. Regresja wsparcia. Zmieniony program ATE otrzymuje własny build, manifest, wyniki weryfikacji i zakres zgodności. Równolegle aktualizuje się instrukcje, dane szkoleniowe, części zamienne i macierz zgodności systemowej. Próba regresyjna potwierdza zarówno wykrywanie pierwotnej anomalii, jak i brak niezamierzonych zmian w innych kontrolowanych funkcjach. Decyzja o wydaniu pakietu wsparcia następuje dopiero po potwierdzeniu synchronizacji wszystkich składników.

9. Potwierdzenie egzemplarza i jednostki. Po modyfikacji każdy objęty egzemplarz otrzymuje zapis as-maintained, identyfikację zainstalowanych części i obrazu, wynik kontroli oraz podpisaną decyzję o przywróceniu do określonego statusu. Jednostka potwierdza dostępność zgodnego ATE, instrukcji i przeszkolonego personelu. Dopiero zbiorczy rekord gotowości pozwala właściwemu organowi uznać zdolność dla wskazanych egzemplarzy, lokalizacji i chwili.

Ten obieg dostarcza schematu, według którego można teraz badać programy rzeczywiste: wielodekadowe podtrzymywanie konfiguracji Minuteman III, systemową współzależność kolejnych konfiguracji Patriot i PAC-3 oraz podział odpowiedzialności między państwo, integratora i dostawców w programie CAMM/CAMM-ER.

Studium I. Minuteman III: wymiana zestawu prowadzenia bez utraty tożsamości systemu

Pytanie i granica studium Minuteman III

Pytanie brzmi: co należało wykazać, aby zastąpienie zestawu prowadzenia NS-20 zestawem NS-50 było modernizacją zachowującą zdolność Minutemana III, a nie tylko wymianą starego komputera na nowszy?

Granica systemu obejmuje zestaw prowadzenia pocisku, pozostawioną platformę stabilizowaną żyroskopowo, komputer i oprogramowanie, przetwarzanie sygnałów, zasilanie, interfejsy z pozostałymi członami pocisku, naziemną diagnostykę, dokumentację, części zamienne, wyposażenie baz oraz organizację obsługi. Nie obejmuje szczegółów wykonywania misji, danych celowania, logiki autoryzacji ani niejawnych parametrów dokładności.

Granica czasu zaczyna się od uruchomienia Guidance Replacement Program w 1999 r. i kończy na ogłoszonym przez 20th Air Force zakończeniu rozmieszczenia w styczniu 2008 r. Wcześniejsza konstrukcja służy jedynie do identyfikacji stanu zastępowanego, a późniejsza eksploatacja — do pokazania, że zakończenie instalacji nie kończy zarządzania konfiguracją.^zks3a-grp

Obiekty konfiguracji

Najważniejszym błędem byłoby potraktowanie nazw NS-20 i NS-50 jak numerów dwóch wymiennych komputerów. Publiczne dokumenty opisują je jako zestawy prowadzenia. W kontrolowanej strukturze produktu należałoby więc rozdzielić co najmniej:

• zestaw prowadzenia NS-20 jako konfigurację wyjściową;
• zestaw NS-50 jako konfigurację wprowadzoną przez GRP;
• zachowaną platformę stabilizowaną żyroskopowo i jej egzemplarzowy zapis stanu;
• nowy komputer prowadzenia;
• nowe oprogramowanie oraz właściwy dla niego obraz wykonywalny;
• przetworniki sygnałów i elementy dystrybucji zasilania objęte zakresem GRP;
• dane kalibracyjne i identyfikację platformy, do której się odnoszą;
• procedury instalacji, kontroli i powrotu do służby;
• naziemne wyposażenie diagnostyczne;
• dokumentację obsługową, części zamienne i pakiet szkoleniowy;
• zapis konfiguracji pocisku i stanowiska po wykonaniu modyfikacji.

Taki podział nie przesądza, które pozycje były formalnie ustanowionymi configuration items w dokumentacji programu. Jest bezpiecznym modelem analitycznym: każda wymieniona pozycja może zmienić wynik weryfikacji albo zakres stosowalności dowodu.

Linia dowodowa

Pierwsze ogniwo stanowi wymaganie systemowe. Raport DOT&E za rok budżetowy 2000 określał jako próg zachowanie ówczesnej zdolności prowadzenia. Jednocześnie wskazywał, że względy kosztowe wykluczyły wymianę jednostki inercyjnej, choć nowa IMU mogłaby poprawić dokładność, a szczególnie niezawodność i dostępność. Zakres GRP obejmował natomiast komputer, oprogramowanie, przetwarzanie sygnałów i elementy dystrybucji zasilania.^zks3a-dote Decyzja nie brzmiała zatem „wszystko nowe jest lepsze”, lecz „wymienić te części, których dalsze utrzymanie zagraża cyklowi życia, zachowując platformę i wykazując niepogorszenie wymaganej funkcji”.

Drugie ogniwo to kwalifikowana definicja projektu NS-50: rysunki, zestawienia materiałowe, interfejsy, źródła i wynik kompilacji oprogramowania, charakterystyki czasowe, procedury wytwarzania oraz kryteria przyjęcia. Publiczne dokumenty nie ujawniają tego pakietu. Jego istnienia jako kontrolowanej podstawy produktu nie należy więc przedstawiać jako bezpośrednio zaobserwowanego faktu; jest ono koniecznym elementem poprawnie prowadzonej zmiany według zasad CM.

Trzecie ogniwo łączy nową elektronikę z pozostawioną platformą. Zachowanie mechaniczno-sensorycznego rdzenia nie zachowuje automatycznie zachowania całego zestawu. Nowy komputer musi odbierać właściwe wielkości, interpretować ich skalowanie i znaki, dotrzymywać granic czasowych, sterować zasilaniem oraz reagować na stany nieprawidłowe w sposób zgodny z wymaganiami systemu. Szybsze obliczenie nie jest samo w sobie poprawą, jeśli zmienia moment wystawienia sygnału albo kolejność zdarzeń widzianą przez starszy podsystem. Potrzebny jest zatem dowód zgodności na granicy stara platforma–nowe przetwarzanie–nowy program, nie tylko świadectwo działania nowej płytki.

Czwarte ogniwo obejmuje wyniki weryfikacji i prób przypisane do dokładnie zidentyfikowanej konfiguracji. Nie wolno połączyć wyniku testu komputera, osobnego testu platformy i dawnej próby pocisku w fikcyjny dowód systemowy, jeżeli nie wykazano, że ich warunki oraz interfejsy reprezentują konfigurację przeznaczoną do wdrożenia. Dowód powinien prowadzić od wymagania przez konfigurację badaną, procedurę, wynik i odstępstwa do decyzji dopuszczającej wskazaną populację.

Piąte ogniwo stanowi instalacja w bazie. Komunikat 20th Air Force mówi o rozmieszczeniu 450 nowych zestawów w polach rakietowych Malmstrom, Minot i F.E. Warren, wymianie ostatniego NS-20 na NS-50 18 stycznia 2008 r. oraz zakończeniu GRP.^zks3a-grp Jest to mocny dowód wykonania programu rozmieszczenia w deklarowanym zakresie. Nie jest jednak pełnym, egzemplarzowym rejestrem konfiguracji każdej rakiety, każdego silosu i każdego urządzenia wsparcia.

Dlaczego zachowano platformę

Pozostawienie platformy ograniczało rozmiar zmiany, ale nie czyniło jej prostą. Zachowany element miał wcześniej zbudowaną charakterystykę, bazę doświadczeń obsługowych i dowody kwalifikacyjne. Wymiana całej IMU wprowadziłaby nową dynamikę czujników, nowe błędy, połączenia, wymagania środowiskowe, proces produkcji i zaplecze naprawcze. Z drugiej strony pozostawienie platformy oznaczało odziedziczenie jej starzenia, ograniczeń oraz zależności od dostępności części i kompetencji.

Była to decyzja o ponownym użyciu części istniejącego dowodu. Dawne wyniki dotyczące mechaniki i określonych własności platformy mogły zachować znaczenie tylko tam, gdzie zmiana ich nie naruszała. Nie mogły zastąpić ponownej weryfikacji interfejsu z nowym komputerem. CM powinno oznaczyć każdy odziedziczony dowód jako:

1. nadal reprezentatywny bez zmian;
2. reprezentatywny po analizie wpływu;
3. wymagający częściowego powtórzenia;
4. unieważniony przez zmianę.

Publiczne materiały nie podają, jak program sklasyfikował poszczególne raporty ani jakie dokładnie regresje wykonano. Wniosek o selektywnym ponownym użyciu dowodów jest modelem inżynierskim, nie rekonstrukcją niejawnego planu kwalifikacji.

Starzenie komponentów, narzędzi i wiedzy

Minuteman III pokazuje, że starzeje się nie tylko zainstalowana elektronika. Zanik źródeł produkcji i niedobory materiałowe — DMSMS — mogą dotyczyć części elektrycznej, elementu mechanicznego, materiału, procesu, aparatury, systemu operacyjnego testera albo kompetencji potrzebnej do odtworzenia wyniku. Oficjalny przewodnik SD-22 ujmuje DMSMS jako problem całego cyklu życia i zaleca działanie wyprzedzające, oceniane względem kosztu, harmonogramu i działania systemu.^zks3a-dmsms

Dla długowiecznego zestawu prowadzenia łańcuch odtwarzalności może zostać przerwany na kilku poziomach:

• producent podzespołu wycofuje część, choć zainstalowane egzemplarze nadal działają;
• zamiennik zachowuje nominalną funkcję, lecz zmienia pobór mocy, opóźnienie albo charakterystykę środowiskową;
• nie można już uruchomić kompilatora lub narzędzia w jego zatwierdzonym środowisku;
• program testowy działa, lecz współczesny przyrząd inaczej interpretuje graniczny pomiar;
• mechaniczna platforma pozostaje sprawna, ale zanika możliwość jej kalibracji lub naprawy;
• wiedza o nietypowym zachowaniu interfejsu istnieje tylko w doświadczeniu odchodzącego personelu;
• dokumentacja dostawcy nie wystarcza do odtworzenia części albo kontrolowanego buildu.

Zakup zapasu ostatnich dostępnych części może odsunąć problem, lecz nie zachowuje automatycznie zdolności pomiarowej, naprawczej i kwalifikacyjnej. Przeprojektowanie modułu rozwiązuje problem dostaw, ale otwiera nową zmianę konfiguracji. Emulacja starego interfejsu może ograniczyć zakres ingerencji, lecz sama staje się pozycją podlegającą identyfikacji, testowaniu i utrzymaniu. DMSMS nie jest więc osobnym procesem logistycznym: dostarcza przyczyn zmian do tego samego obiegu CM, który musi chronić znaczenie wcześniejszych dowodów.

Konflikt: niezawodność nowej elektroniki i starzenie pozostawionego rdzenia

W komunikacie zamykającym GRP podano poprawę średniego odstępu między sygnałami uszkodzenia zestawu prowadzenia z około 7 tys. do około 27 tys. godzin.^zks3a-grp Ten wskaźnik wspiera twierdzenie o poprawie niezawodności eksploatacyjnej w znaczeniu przyjętym przez program. Nie wolno przeliczać go wprost na prawdopodobieństwo powodzenia lotu ani rozciągać na całą rakietę. Może opisywać zgłoszenia wymagające reakcji obsługowej, podczas gdy misja ma inną długość i profil obciążeń.

Konflikt decyzyjny miał zatem dwie strony. Pozostawienie NS-20 zwiększało ryzyko dalszego starzenia elektroniki i zaplecza. Wymiana całej IMU mogła przynieść dodatkowe korzyści, ale rozszerzała koszt, harmonogram i zakres kwalifikacji. Wybrano nową elektronikę oraz oprogramowanie współpracujące z istniejącą platformą. Zdolność nie wynikała jednak ani z młodego wieku komputera, ani z historycznej kwalifikacji platformy. Powstawała dopiero w ich zweryfikowanym zestawieniu.

Projekt, baza i flota — trzy różne stany

Stan projektu oznacza, że NS-50 i związane z nim dane zostały zdefiniowane oraz zatwierdzone do określonego zastosowania. Nie mówi, czy zbudowano konkretny egzemplarz.

Stan wdrożenia w bazie oznacza, że zestaw dostarczono, zainstalowano, sprawdzono i przyjęto na wskazanym stanowisku. W jednej bazie mogą występować równocześnie egzemplarze przed modyfikacją, w trakcie pracy, po instalacji, lecz przed próbą odbiorczą, oraz przywrócone do służby.

Stan całej floty jest sumą rekordów egzemplarzowych, a nie nazwą najnowszego zatwierdzonego projektu. W czasie wieloletniego GRP flota musiała pozostawać mieszana: część stanowisk używała NS-20, część NS-50. Z ogłoszenia nowej konfiguracji nie wynikało, że wszystkie stanowiska już ją otrzymały. Z dostarczenia zestawu do bazy nie wynikało, że został zainstalowany. Z instalacji nie wynikało, że pocisk wrócił do dyżuru. Dopiero zamknięty rekord wykonania i akceptacji zmieniał stan egzemplarza.

Minimalny zapis statusu powinien rozdzielać: zmiana zatwierdzona → dane wydane → zestaw wyprodukowany → dostarczony do bazy → zainstalowany → sprawdzony → zaakceptowany → egzemplarz przywrócony do służby. Podczas przejścia oba warianty potrzebowały właściwych części, dokumentacji, testerów i personelu. Zamknięcie instalacji ostatniego NS-50 było kamieniem floty, nie datą powstania projektu ani początkiem kwalifikacji.

Decyzja i granica inferencji

Decyzję GRP można bezpiecznie streścić następująco: zastąpiono NS-20 zestawem NS-50, wymieniając komputer i oprogramowanie oraz zachowując istniejącą platformę stabilizowaną żyroskopowo; do stycznia 2008 r. rozmieszczono 450 nowych zestawów.^zks3a-grp Raport DOT&E pozwala dodać, że pozostawienie IMU było kompromisem kosztowym, a wymaganiem progowym pozostawało utrzymanie dotychczasowej zdolności.^zks3a-dote

Granica inferencji jest równie ważna. Jawne źródła nie pozwalają odtworzyć algorytmów, parametrów kalibracji, szczegółowych testów, pełnej struktury części NS-50 ani konfiguracji każdego stanowiska. Nie dowodzą też, że wszystkie starsze elementy były identyczne albo że zakończenie GRP usunęło późniejsze ryzyko DMSMS. Studium potwierdza mechanizm kontrolowanej sukcesji konfiguracji, nie publiczną rekonstrukcję zestawu prowadzenia.

Studium II. Patriot/PAC-3: zgodność efektora istnieje tylko w łańcuchu systemowym

Pytanie i granica studium Patriot

Pytanie brzmi: kiedy można powiedzieć, że jednostka Patriot rzeczywiście uzyskała zdolność z efektorem PAC-3 MSE, skoro wyprodukowanie albo dostarczenie pocisku nie dowodzi zgodności wyrzutni, radaru, oprogramowania, wyposażenia testowego i wyszkolenia obsługi?

Granica systemu obejmuje efektor, jego kontener, wyrzutnię wraz z elektroniką, radar, stanowisko i oprogramowanie kierowania walką, sieć oraz źródła danych potrzebne do prowadzenia przechwycenia, wyposażenie testowe, pakiet dokumentacji i szkolenia. Nie obejmuje współczesnych procedur bojowych, rozmieszczenia, czasów reakcji, niejawnych charakterystyk sensora ani analizy podatności.

Granica czasu obejmuje przejście od konfiguracji z oprogramowaniem PDB-7 i modernizacją wyrzutni do prób systemu z PDB-8, cyfrowym procesorem radaru i PAC-3 MSE w latach budżetowych 2012–2017. Daty te opisują amerykański program z tego okresu; nie są chronologią każdej konfiguracji eksportowej ani współczesnej polskiej Wisły.

Obiekty konfiguracji i znaczenie nazw

Nazwa „PAC-3” bywa używana dla efektora, segmentu pociskowego oraz kolejnych konfiguracji systemu. Oficjalna historia U.S. Army wskazuje, że PAC-3 Configuration 1 była konfiguracją sprzętu i oprogramowania Patriot, która nie obejmowała jeszcze efektora PAC-3/ERINT; efektor powiązano dopiero z Configuration 3.^{zks3a-pac3history} Numer konfiguracji systemowej nie jest zatem numerem pocisku.

Dla analizowanej zmiany trzeba prowadzić osobne rekordy co najmniej dla:

• PAC-3 MSE jako określonego efektora;
• kontenera i interfejsów pocisk–wyrzutnia;
• modernizacji elektroniki wyrzutni;
• radaru w konfiguracji objętej próbą;
• cyfrowego procesora radaru;
• stanowiska kierowania i odpowiedniego wydania PDB;
• danych konfiguracyjnych oraz interfejsów komunikacyjnych;
• urządzeń testowych i właściwych programów testowych;
• pomocy szkoleniowych, symulatorów i programu szkolenia;
• kwalifikacji personelu dla nowego zestawienia;
• egzemplarzowego stanu wyrzutni, radaru i stanowiska dowodzenia.

Efektor może być zdatny jako wyrób, a jednocześnie nie być dopuszczony na danej wyrzutni. Wyrzutnia może fizycznie przyjąć kontener, lecz nie mieć właściwej elektroniki lub oprogramowania. Radar może wykrywać i śledzić cele, ale nie dostarczać jakości albo zakresu wsparcia wymaganego dla wykorzystania całej zdolności nowego efektora. Lokalny BIT może zakończyć się poprawnie, choć systemowy łańcuch pozostaje niezgodny.

Linia dowodowa: od elementu do zdolności

Raport GAO z 2016 r., oparty na dokumentach i danych Army, rozdziela kilka zdarzeń. PDB-7 oraz nowy procesor stanowiska kierowania zostały wprowadzone wcześniej, natomiast modernizacja wyrzutni umożliwiająca obsługę PAC-3 MSE i sam efektor zaczęły być wdrażane w roku budżetowym 2016. Ograniczona próba użytkownika z 2012 r. badała zestawienie PDB-7, nowego procesora, PAC-3 MSE i zmodyfikowanej wyrzutni. Próby rozwojowe w roku budżetowym 2016 objęły system z PDB-8, cyfrowym procesorem radaru, modernizacją wyrzutni i PAC-3 MSE.^zks3a-gao

Nie jest to jeden niepodzielny „test Patriot”. Każde zdarzenie ma własny badany baseline. Wynik konfiguracji PDB-7 nie dowodzi wyniku PDB-8, a test pojedynczej modernizacji nie zastępuje próby systemowej. GAO wskazywało również, że ówczesny radar nie pozwalał wykorzystać całego zakresu możliwości PAC-3 MSE, a późniejsze zmiany radaru i oprogramowania miały tę granicę przesuwać.^zks3a-gao Jest to empiryczny przykład wspólnej tezy: dodatkowa zdolność efektora nie staje się zdolnością bojową systemu, dopóki pozostała część łańcucha nie potrafi jej wesprzeć.

W 2017 r. U.S. Army opisała próbę Missile Flight Test-B jako demonstrację zdolności końca-do-końca, kwalifikację zestawienia sprzętu i oprogramowania PDB-8 oraz użycie PAC-3 MSE. W próbie uczestniczył pododdział, który przygotowywał się przez 15 miesięcy; źródło podkreślało zarówno aktualizacje oprogramowania, jak i znaczenie doświadczenia operatorów.^zks3a-mftb Dowód nie kończył się zatem na locie efektora. Obejmował pracę systemu i reprezentatywnych użytkowników.

Bezpieczna przykładowa macierz zgodności

Poniższa macierz jest modelem CM, a nie ujawnioną tabelą Patriot. Litery L0/L1, R0/R1, S0/S1 i T0/T1 są umownymi identyfikatorami szkoleniowymi. Nie odpowiadają rzeczywistym numerom części, buildom ani jednostkom.

Efektor	wyrzutnia	radar i przetwarzanie	kierowanie walką	ATE/TPS	szkolenie	status dowodowy
starszy zatwierdzony efektor	L0	R0	S0	T0	pakiet TR-0	konfiguracja odziedziczona; jej ważność wymaga własnego rekordu
PAC-3 MSE	L0	dowolny	dowolne	dowolne	dowolne	niezgodne: brak potwierdzonej modernizacji wyrzutni
PAC-3 MSE	L1	R0	S0	T0	TR-0	możliwe fizyczne zestawienie nie jest dowodem zdolności systemowej
PAC-3 MSE	L1	R0	S1	T1	TR-1	dopuszczenie tylko w zakresie wykazanym próbą; nie oznacza pełnego wykorzystania efektora
PAC-3 MSE	L1	R1	S1	T1	TR-1	kandydat do zatwierdzonej konfiguracji po zamknięciu wymaganych dowodów systemowych
PAC-3 MSE	L1	R1	S1	T0	TR-1	niepełna linia utrzymania: tester lub program testowy nie reprezentuje nowej konfiguracji
PAC-3 MSE	L1	R1	S1	T1	TR-0	sprzęt może być sprawny, lecz jednostka nie ma wykazanej gotowości do eksploatacji nowej konfiguracji

ATE/TPS oznacza tu kontrolowane automatyczne wyposażenie testowe wraz z test program set, adapterami, limitami, kalibracją i procedurą. Jawne materiały wykorzystane w studium nie identyfikują konkretnego testera dla PAC-3 MSE. Umieszczenie go w macierzy jest wnioskiem z wymagań utrzymania konfiguracji: wynik testu ma wartość tylko wtedy, gdy tester rozpoznaje badany wariant, wystawia właściwe pobudzenia i stosuje zatwierdzone kryteria. Raport GAO potwierdza, że program finansował wspierające wyposażenie testowe, osobny pododdział testowy oraz sprzęt i oprogramowanie szkoleniowe, lecz nie daje podstaw do odtworzenia ich wewnętrznych konfiguracji.^zks3a-gao

Macierz nie odpowiada jednym polem „tak/nie” na pytanie o kompatybilność. Może istnieć zgodność mechaniczna bez funkcjonalnej, kwalifikacja ograniczonego trybu bez pełnej zdolności albo zgodność bojowa przy chwilowym braku właściwego zaplecza obsługowego. Dlatego każdy wiersz powinien mieć wskazane wymagania, raporty z prób, ograniczenia i okres obowiązywania.

Jedna zmiana: wprowadzenie obsługi PAC-3 MSE na część wyrzutni

Rozważmy kontrolowaną zmianę Z-PMSE: dopuszczenie PAC-3 MSE na zmodernizowanej wyrzutni wraz z wymaganym wydaniem oprogramowania i zapleczem. Jest to rekonstrukcja dydaktyczna oparta na jawnej informacji, że modernizacja wyrzutni była konieczna do ładowania i odpalania MSE oraz że kolejne próby obejmowały określone zestawienia wyrzutni, oprogramowania i radaru.^zks3a-gao Nie jest to rzeczywisty ECP ani instrukcja modyfikacji.

Potrzeba zmiany. Nowy efektor nie może zostać uznany za wymienny ze starszym tylko dlatego, że należy do rodziny Patriot. Analiza wpływu obejmuje kontener, obciążenia i interfejs wyrzutni, elektronikę sterującą, rozpoznanie wariantu przez oprogramowanie, wsparcie radaru, procedury testowe, części, dokumentację i szkolenie.

Effectivity produkcyjna. Nowe lub przebudowywane wyrzutnie mogą opuszczać zakład w stanie L1. Zapis nie powinien mówić jedynie „od teraz wszystkie wyrzutnie są L1”, lecz identyfikować zatwierdzone numery części, wykonane modyfikacje i egzemplarze zaakceptowane po badaniu.

Effectivity retrofit. Wyrzutnie L0 istniejące w jednostkach otrzymują osobną listę kwalifikującą do modyfikacji. Statusy muszą rozróżniać: zestaw modyfikacyjny przydzielony, praca rozpoczęta, praca wykonana, test po modyfikacji zaliczony oraz wyrzutnia przywrócona do eksploatacji.

Flota mieszana. Do czasu zakończenia retrofit część wyrzutni pozostaje L0, część jest czasowo niedostępna, a część osiąga L1. Magazyn nie może wydawać PAC-3 MSE wyłącznie na podstawie napisu „Patriot”. System dowodzenia, plan szkolenia i obsługa muszą znać rzeczywisty status każdej wyrzutni. Starsza wyrzutnia może zachować wcześniejszą funkcję, lecz nie otrzymuje nowej tylko przez sąsiedztwo z wyrzutnią zmodyfikowaną.

Równoległa zmiana oprogramowania. Jeżeli dopuszczenie zależy od określonego release’u, sam retrofit hardware’u nie zamyka zmiany. Rekord powinien powiązać wyrzutnię z właściwym oprogramowaniem stanowiska kierowania i elektroniki wyrzutni. Build opracowany i release zatwierdzony to inne stany niż release załadowany oraz zweryfikowany w jednostce.

ATE i dokumentacja. Tester T0 może nadal obsługiwać konfigurację odziedziczoną. Dla L1 potrzebny jest zatwierdzony zakres testu T1 albo formalny dowód, że dotychczasowy tester pozostaje ważny. Jeżeli modyfikacja zmienia identyfikację, sygnały lub limity, stary program testowy może dać wynik pozornie poprawny. Wdrożenie obejmuje więc także wydanie procedur, adapterów, danych limitów i potwierdzenie kalibracji.

Szkolenie. GAO odnotowało potrzebę rekonfigurowalnych środków szkoleniowych, a Army w opisie próby PDB-8 wskazała długie przygotowanie pododdziału oraz informację zwrotną operatorów.^{zks3a-gao,zks3a-mftb} Pakiet TR-1 powinien być związany z wariantem sprzętu i oprogramowania. Ukończenie kursu dla wcześniejszej konfiguracji nie jest automatycznie dowodem zdolności obsługi zmienionego systemu.

Zamknięcie zmiany. Zdolność jednostki powstaje dopiero wtedy, gdy wskazana wyrzutnia ma potwierdzony stan L1, przydzielony efektor jest objęty dopuszczeniem, współpracujące radar i oprogramowanie odpowiadają zatwierdzonemu wierszowi macierzy, wyposażenie testowe może podtrzymać ten stan, personel ukończył właściwe szkolenie, a wyniki odbioru zostały przypisane do egzemplarzy. Dopiero suma tych zapisów pozwala zmienić stan z „modyfikacja dostępna” na „konfiguracja wdrożona i przyjęta”.

Konflikt i decyzja

Ryzyko programu ma charakter systemowy. Można szybciej wdrożyć efektor i zmodyfikowaną wyrzutnię, uzyskując ograniczony zakres użycia, albo czekać na pełniejszą modernizację radaru i oprogramowania. Pierwsze rozwiązanie wcześniej dostarcza część wartości, lecz tworzy flotę mieszaną i wymaga jawnych ograniczeń. Drugie opóźnia wdrożenie i zwiększa zakres jednorazowej zmiany. Dokumenty z badanego okresu pokazują podejście przyrostowe: PAC-3 MSE i modernizacja wyrzutni weszły wcześniej, a PDB-8 oraz cyfrowy procesor radaru były badane w kolejnym zestawieniu systemowym.^zks3a-gao

Nie wolno opisać tego jako prostego „odblokowania pełnego zasięgu” ani przenosić wyników jednej próby na każdą późniejszą baterię. Poprawna decyzja CM wskazuje dokładnie, jaki wiersz macierzy dopuszczono, dla jakich egzemplarzy, do jakiego zastosowania i na podstawie którego pakietu dowodowego.

Granica inferencji i przejście do Narwi

Jawne źródła potwierdzają zależność PAC-3 MSE od modernizacji wyrzutni, radaru, oprogramowania i prób systemowych oraz znaczenie sprzętu szkoleniowego i reprezentatywnych użytkowników. Nie ujawniają kompletnej macierzy kompatybilności, rzeczywistych identyfikatorów ATE, pełnych wersji wszystkich komponentów ani konfiguracji współczesnych jednostek. Przykładowej macierzy nie wolno używać do planowania eksploatacji; pokazuje ona strukturę decyzji, nie treść wojskowej dokumentacji.

Minuteman skupiał odpowiedzialność wokół państwowego operatora, integratora strategicznego i długowiecznego krajowego zaplecza. Patriot pokazuje już trudniejszy układ wielu programów, efektorów i kolejnych pakietów modernizacyjnych. W Narwi problem przesuwa się jeszcze dalej: trzeba ustalić, kto — państwo, integrator krajowy czy zagraniczny dostawca — jest właścicielem punktu bazowego, interfejsu, dowodu kwalifikacyjnego i decyzji o zmianie, zwłaszcza gdy produkcja, oprogramowanie, urządzenia testowe oraz odpowiedzialność za późniejszy retrofit są rozdzielone między kilka organizacji.

Studium przypadku: CAMM i CAMM-ER w programie Narew

Pytanie, granica czasu i granica systemu

Pytanie rozstrzygające brzmi: jak państwo może wykazać, że określona jednostka ogniowa Narwi, w określonym dniu, zachowuje zdolność przypisaną zatwierdzonej konfiguracji, jeżeli efektor, wyrzutnia, sensory, dowodzenie, pojazdy, oprogramowanie i zaplecze produkcyjne powstają pod odpowiedzialnością różnych podmiotów?

Granica analizy nie kończy się na pocisku. Obejmuje efektor CAMM albo CAMM-ER, wyrzutnię, polskie nośniki, wskazane sensory, urządzenia dowodzenia, oprogramowanie i dane integracyjne, system nadrzędny, urządzenia testowe, pakiet logistyczny i szkoleniowy oraz procesy produkcji i obsługi. Włączenie wszystkich tych elementów nie oznacza, że tworzą jeden wyrób ani że jeden podmiot jest właścicielem całej dokumentacji. Oznacza jedynie, że ich zgodność może wpływać na wynik systemowy.

Granica czasu wymaga rozdzielenia Małej Narwi z CAMM od docelowej Narwi z CAMM-ER. Umowa wykonawcza z 14 kwietnia 2022 r. dotyczyła dwóch jednostek ogniowych przyspieszonego rozwiązania. Agencja Uzbrojenia wskazała w nim radar SOŁA, polskie urządzenia kierowania uzbrojeniem, pojazdy, trzy wyrzutnie iLauncher oraz pociski CAMM, a zarazem zastrzegła, że nie jest to ostateczna konfiguracja Narwi.^{zks3b-mala-umowa} We wrześniu 2022 r. MBDA informowała o trwającej integracji fizycznej i funkcjonalnej oraz próbach przed przekazaniem sprzętu.^{zks3b-mala-integracja} Pod koniec tego miesiąca Agencja Uzbrojenia odnotowała wprowadzenie pierwszych egzemplarzy systemu opartego na CAMM na wyposażenie Sił Zbrojnych RP.^{zks3b-mala-dostawa}

Dostawa nie zamykała jednak linii dowodowej. W czerwcu 2023 r. MON poinformowało o strzelaniu bojowo-doświadczalnym Małej Narwi i zapowiedziało rozpoczęcie dyżurów przez przygotowany pododdział.^{zks3b-mala-strzelanie} We wrześniu 2023 r. drugi użytkownik otrzymał sprzęt; komunikat mówił o przeszkolonych załogach i wykonanych strzelaniach, lecz wejście tego pododdziału do systemu dyżurów nadal przedstawiał jako zdarzenie przyszłe.^{zks3b-mala-druga} Są to różne dowody: przekazanie dokumentuje dostawę, strzelanie — zachowanie badanego zestawienia w konkretnej próbie, a komunikat o dyżurach — zamiar albo rozpoczęcie określonej formy wykorzystania. Żaden z nich osobno nie dowodzi nieprzerwanej gotowości każdego egzemplarza.

Dla docelowej Narwi właściwa jest następna gałąź osi czasu. MBDA podała, że po umowach wykonawczych przyznanych konsorcjum PGZ-NAREW przez Agencję Uzbrojenia we wrześniu 2023 r. zawarła 7 listopada umowę z PGZ. Według producenta umożliwia ona wytwarzanie w Polsce ponad tysiąca pocisków CAMM-ER i ponad stu wyrzutni oraz obejmuje transfer kluczowych technologii i wiedzy.^{zks3b-narew-mbda} Jest to mocny dowód zawarcia porozumienia przez MBDA i PGZ oraz publicznie zadeklarowanego zakresu przemysłowego. Nie jest to dowód zakończonego transferu, kwalifikacji polskiej linii, dostawy seryjnego CAMM-ER do wojska ani gotowości zestawów docelowych.

W lutym 2024 r. MON zawarło z rządem Stanów Zjednoczonych umowę na IBCS dla drugiej fazy Wisły i 23 zestawów Narew. Oficjalny zakres obejmuje między innymi prace nad oprogramowaniem, integrację radarów i wyrzutni oraz pointegracyjne testy poligonowe.^zks3b-ibcs Umowa potwierdza zobowiązanie i przewidziany proces integracji, ale nie potwierdza jego zakończenia.

Tak samo należy odczytywać inwestycje produkcyjne. Ministerstwo Aktywów Państwowych podało pod koniec 2025 r., że projekty WZE, MESKO i OBR CTM mają rozwinąć produkcję, montaż, serwis i integrację, przy czym zakończenie projektu WZE planowano na 2028 r., a przedsięwzięcia MESKO dotyczącego zdolności do produkcji silnika i głowicy — na lata 2025–2030.^{zks3b-inwestycje} Umowa inwestycyjna ogłoszona przez MON 1 kwietnia 2026 r. również dotyczyła ustanowienia takich zdolności i przyszłego montażu kompletnych rakiet w Polsce.^zks3b-mesko Publiczny status na 8 września 2026 r. można więc zapisać następująco:

Obiekt lub zdarzenie	Status potwierdzony publicznie	Czego ten status nie dowodzi
Mała Narew z CAMM	umowa, integracja, pierwsze dostawy, strzelanie, wykorzystanie przez wskazanych użytkowników	zgodności z docelową Narwią albo CAMM-ER
Docelowa Narew z CAMM-ER	umowy wykonawcze i porozumienie przemysłowe, zakontraktowany transfer technologii	zakończonej produkcji, kwalifikacji i gotowości operacyjnej
IBCS dla Narwi	umowa i określony zakres przyszłej integracji oraz prób	ukończenia integracji wszystkich elementów
Polskie zdolności produkcyjne CAMM-ER	finansowanie, inwestycje i publicznie określone cele	odbioru linii, kwalifikacji procesu ani przyjęcia seryjnego wyrobu
Polskie elementy pocisku	zamiar produkcji wskazanych klas podzespołów	ich dokładnej konfiguracji, zatwierdzonej dokumentacji i zakresu kwalifikacji

Obiekty CI i własność baseline’u

Na potrzeby CM nie wystarcza pozycja konfiguracji nazwana „Narew”. Minimalna dekompozycja rozdziela:

• konfigurację jednostki ogniowej i jej systemowy manifest;
• efektor CAMM oraz efektor CAMM-ER jako odrębne produkty;
• wyrzutnię, nośnik i ich zestawienie;
• każdy sensor wraz z właściwym wydaniem oprogramowania i danych;
• elementy dowodzenia, łączności i integracji z IBCS;
• oprogramowanie wyrzutni, sterowania uzbrojeniem i interfejsów;
• dane konfiguracyjne, parametryzacyjne i kalibracyjne;
• wyposażenie testowe, jego programy, adaptery i limity;
• dokumentację obsługi, szkolenia i dopuszczonych zestawień;
• polskie procesy produkcyjne, oprzyrządowanie i stanowiska odbiorcze;
• partie, numery seryjne, odstępstwa i zapis stanu po obsłudze.

Publiczne komunikaty nie ujawniają, kto jest właścicielem poszczególnych baseline’ów ani jakie prawa do danych, kodu i narzędzi przyznają umowy. Nie można zatem stwierdzić, że PGZ, państwo albo MBDA posiada pełną władzę nad całą definicją produktu. Poprawny model powinien zamiast jednego „właściciela Narwi” ustanawiać władzę zatwierdzającą dla każdego poziomu.

Państwo powinno kontrolować baseline wymagań systemowych, warunki dopuszczenia, konfigurację akceptowaną przez użytkownika oraz decyzję o przyjęciu ryzyka. Integrator powinien utrzymywać baseline integracyjny: wykaz dopuszczonych CI, kontrolowane interfejsy, manifest zgodności, wyniki prób systemowych i zakres obowiązywania zmian. Dostawca produktu zachowuje odpowiedzialność za kontrolowaną definicję swojego wyrobu, jego zweryfikowane wydania oraz zgłaszanie zmian mogących wpływać na integrację. Taki podział jest modelem wymaganym do zachowania spójności dowodu, a nie rekonstrukcją niejawnych postanowień umów.

Kluczowym obiektem wspólnym jest baseline interfejsów. Nie oznacza on przekazania jednej stronie całego projektu drugiej strony. Musi jednak określać tyle, aby można było jednoznacznie ocenić zgodność obu końców połączenia: identyfikatory wydań, znaczenie wymienianych informacji, wymagane zachowanie, ograniczenia czasowe i środowiskowe, metody weryfikacji oraz sposób zawiadamiania o zmianie. Mechaniczne osadzenie wyrzutni na pojeździe nie dowodzi poprawności zasilania, łączności, oprogramowania, danych ani sekwencji systemowych.

Transfer produkcji, kwalifikacja i prawa do narzędzi

Transfer dokumentacji nie jest równoznaczny z odtworzeniem procesu. Produkcja w drugim zakładzie może wymagać kwalifikacji personelu, materiałów, dostawców, oprzyrządowania, procesów specjalnych, metod kontroli, stanowisk testowych i źródeł danych. Dopiero wynik dotyczący wskazanej konfiguracji linii i wyrobu pozwala rozstrzygnąć, czy część dowodów pierwotnego producenta można zachować przez analizę podobieństwa, a które próby należy wykonać ponownie.

Kwalifikacja polskiego elementu powinna pozostawić linię:

wymaganie → zatwierdzona definicja elementu → proces i jego parametry kontrolowane → egzemplarz lub partia reprezentatywna → konfiguracja stanowiska → wynik → niezgodności i ich zamknięcie → zatwierdzenie zakresu stosowania

Pozytywny wynik pojedynczego komponentu nie kwalifikuje automatycznie kompletnego pocisku. Z kolei próba systemowa nie zastępuje wszystkich dowodów procesowych, ponieważ może nie ujawnić rozrzutu produkcji ani skutków długiego przechowywania. Potrzebne są oba rodzaje argumentu, połączone z konkretnymi numerami części, rewizjami, partiami i datami.

Osobnym zagadnieniem są prawa do narzędzi. Hasło „transfer technologii” nie rozstrzyga, czy odbiorca może samodzielnie używać, modyfikować, odtwarzać lub zastępować:

• środowiska budowania oprogramowania i obrazów programowalnej logiki;
• programatory, urządzenia ładujące i pakiety testowe;
• modele, biblioteki, skrypty oraz dane kalibracyjne;
• dokumentację procesów i kryteria odbioru;
• klucze, zależności od usług producenta i dostępność niezbędnych narzędzi;
• dane konieczne do analizy wpływu późniejszej zmiany.

Dojrzała umowa rozdziela własność od prawa użycia, prawo produkcji od prawa modyfikacji oraz dostęp eksploatacyjny od możliwości odtworzenia narzędzia po zakończeniu wsparcia. Publicznie dostępne materiały Narwi nie pozwalają ustalić tych praw. Granica inferencji jest zatem jednoznaczna: ogłoszony transfer i lokalna produkcja nie dowodzą pełnej autonomii w zmianie projektu ani samodzielnego odtworzenia każdego artefaktu.

Linia dowodowa, konflikt i decyzja

Dla docelowej Narwi argument zdolności powinien być budowany od konkretnej jednostki ogniowej, a nie od nazwy programu. Jego skrócona postać ma następującą strukturę:

1. państwo zatwierdziło wymagania i kryteria przyjęcia;
2. integrator ustanowił kontrolowany baseline systemowy i interfejsowy;
3. dostawcy wydali jednoznacznie zidentyfikowane CI;
4. zapisy produkcyjne potwierdziły konfigurację zbudowaną;
5. manifest połączył sprzęt, oprogramowanie, dane i wyposażenie testowe;
6. kwalifikacja i weryfikacja objęły tę konfigurację albo formalnie wykazano ważność wcześniejszych wyników;
7. dostawa i odbiór przypisały egzemplarze określonemu użytkownikowi;
8. zapis obsługowy potwierdza wszystkie późniejsze wymiany i aktualizacje;
9. właściwy organ wojskowy potwierdził spełnienie dodatkowych warunków gotowości.

Najpoważniejszy konflikt odpowiedzialności pojawia się wtedy, gdy każdy uczestnik może poprawnie wykazać zgodność własnego wyrobu, lecz nikt nie posiada kompletnego dowodu zgodności systemu. Dostawca może potwierdzić pocisk, integrator — wyrzutnię i wymianę danych, a użytkownik — wykonanie obsługi. Jeżeli nie istnieje kontrolowany manifest łączący te dowody, pozytywne oceny pozostają równoległe i nie składają się w argument zdolności.

Decyzja CM powinna ustanowić jeden organ zatwierdzający konfigurację systemową, przy zachowaniu władz projektowych dostawców nad ich CI. Organ ten nie musi posiadać wszystkich danych konstrukcyjnych, ale musi otrzymywać informację wystarczającą do oceny wpływu, identyfikacji wydania i sprawdzenia ważności dowodów. Zmiana dostawcy nie może wejść do systemu wyłącznie dlatego, że zachowano katalogową funkcję produktu. Zmiana integratora nie może zostać zatwierdzona bez oceny efektu na wyroby dostawców. Państwo nie powinno przyjmować ryzyka, którego zakresu nie da się przypisać do populacji i czasu.

Diagnostyka rozbieżności konfiguracji

Rozbieżność należy traktować jako problem identyfikacji stanu, a nie jako konkurs wiarygodności między etykietą, bazą i człowiekiem. Rozumowanie rozpoczyna się od oddzielenia czterech pytań:

1. co fizycznie zaobserwowano;
2. jaki stan miał obowiązywać;
3. jaki stan zarejestrowano;
4. jaki dowód łączy te trzy odpowiedzi.

Załóżmy, że oznaczenie na wymiennym module wskazuje rewizję R2, manifest systemowy R3, a dokument obsługowy dopuszcza obie rewizje, lecz dla różnych wydań oprogramowania. Nie wolno wybrać R3 tylko dlatego, że manifest jest nowszy. Oznaczenie jest obserwacją fizyczną, lecz mogło zostać wymienione lub naniesione błędnie; manifest jest kontrolowanym zapisem, lecz może odnosić się do planowanej, a nie zainstalowanej konfiguracji. Należy więc ustalić tożsamość egzemplarza, historię ostatniej czynności, dokument stanowiący podstawę zmiany i wynik testu po jej wykonaniu. Dopiero zgodny łańcuch dowodzi stanu.

Jeżeli manifest zawiera inny obraz oprogramowania niż identyfikator odczytany przez zatwierdzone urządzenie obsługowe, pierwsze pytanie dotyczy semantyki pól. Jedno może oznaczać zatwierdzony release, drugie konkretny build, a trzecie pakiet dystrybucyjny. Równość nazw nie jest wymagana, jeżeli istnieje kontrolowane odwzorowanie; podobieństwo nazw nie wystarcza, jeżeli takiego odwzorowania brak. Rozstrzygnięcie powinno oprzeć się na identyfikatorze artefaktu, skrócie integralności, rekordzie instalacji, zgodności sprzętowej i zakresie zatwierdzenia. Sam pozytywny BIT potwierdza tylko wykonane testy, nie pełną zgodność systemową.

Brak rekordu nie jest dowodem braku modyfikacji. Jeżeli część znajduje się fizycznie w systemie, ale nie ma zapisu instalacji, nie należy dopisywać historii na podstawie obecnego wyglądu. Tworzy się rekord rekonstrukcyjny, który oddziela fakty zaobserwowane od wniosków: identyfikację części, datę oględzin, dostępne ślady wcześniejszego stanu, zakres nierozstrzygnięty oraz decyzję osoby uprawnionej. Ograniczenie użycia, dalsza diagnostyka albo przywrócenie znanej konfiguracji są decyzjami właściwego organu technicznego; CM dostarcza mu obraz niepewności, ale go nie zastępuje.

Sprzeczność między PLM a systemem obsługowym często jest sprzecznością pozorną. PLM może być źródłem obowiązującej definicji projektu, a system obsługowy — źródłem stanu konkretnego egzemplarza. Gdy PLM zawiera rewizję R3, a zapis eksploatacyjny R2, trzeba ustalić zakres obowiązywania zmiany: czy R3 jest tylko zatwierdzona, wydana do produkcji, obowiązkowa dla nowych wyrobów, czy również nakazana jako retrofit. Dopiero ostatni przypadek, po upływie terminu i dla objętego nim egzemplarza, tworzy rzeczywistą niezgodność. Automatyczne przepisanie R3 do systemu obsługowego zniszczyłoby informację o stanie fizycznym.

Jeżeli oba systemy twierdzą, że są źródłem nadrzędnym dla tego samego pola i chwili, analizuje się pochodzenie transakcji: kto dokonał wpisu, na podstawie jakiego dokumentu, jaki był czas skuteczności zmiany i czy wystąpił potwierdzony odbiór. Rozbieżność zamyka dopiero korekta rekordu błędnego albo udokumentowana zmiana stanu fizycznego. Samo uzgodnienie baz bez sprawdzenia egzemplarza może jedynie usunąć widoczny alarm.

Minimalny pakiet odtworzenia konfiguracji i dowodu zdolności

Minimalność nie oznacza najmniejszej liczby plików. Oznacza zbiór, bez którego nie da się odpowiedzieć, co było zainstalowane, dlaczego było dopuszczone i do jakich wyników można się odwołać.

Warstwa	Minimalna zawartość
Tożsamość	system, jednostka ogniowa, CI, numery części i seryjne, partie, rewizje, stan modyfikacji, użytkownik i data
Stan projektowy	zatwierdzony baseline wymagań, produktu i interfejsów wraz z organem zatwierdzającym
Stan zbudowany	wykaz materiałowy, pochodzenie części, użyte procesy, odstępstwa, naprawy i wyniki odbioru
Stan cyfrowy	wydania i buildy oprogramowania, firmware’u, obrazów FPGA oraz danych; skróty, zależności i środowisko wytworzenia
Stan zainstalowany	manifest konkretnego zestawienia, historia instalacji i usunięć oraz potwierdzenie po czynności
Zgodność	macierz dopuszczonych zestawień sprzętu, kodu, danych, sensorów, wyrzutni, C2 i wyposażenia testowego
Zmiany	wniosek, analiza wpływu, decyzja, zakres obowiązywania, plan wdrożenia i potwierdzenie wykonania
Dowody techniczne	wymagania, przypadki testowe, konfiguracja badanego obiektu i stanowiska, wyniki, anomalie oraz ich zamknięcie
Kwalifikacja produkcji	identyfikacja linii, narzędzi, procesów, materiałów, personelu i reprezentatywnej partii
Obsługa	zapis stanu przed i po pracy, instrukcja właściwa dla konfiguracji, użyty tester, kalibracja i wynik
Ciągłość odtworzenia	dostępność danych i narzędzi, zależności od dostawcy, archiwum oraz plan odtworzenia
Dopuszczenie	formalna decyzja o przyjęciu, ograniczenia, termin ważności i organ odpowiedzialny za status gotowości

Pakiet nie musi znajdować się w jednej bazie. Musi natomiast mieć jednoznaczne źródło nadrzędne dla każdego pola, stabilne identyfikatory i zachowaną historię. Odnośnik do „najnowszej wersji” nie odtwarza stanu historycznego.

Dojrzałość CM mierzona artefaktami

Dojrzałości nie należy oceniać liczbą procedur ani nazwą systemu informatycznego. Jej miarą jest zdolność do uzyskania powtarzalnej odpowiedzi z niezależnie dobranej próbki.

Poziom	Obserwowalne artefakty	Próba audytowa i oczekiwany wynik
0 — stan nieustalony	rozproszone listy i lokalne pliki, brak właścicieli danych	dwa zespoły odtwarzają różne konfiguracje tego samego egzemplarza
1 — identyfikacja dokumentowa	rejestr CI, numery rewizji, podstawowy obieg zatwierdzeń	można wskazać projekt obowiązujący, lecz nie zawsze stan fizyczny i cyfrowy egzemplarza
2 — kontrola egzemplarza	manifesty, historia obsługi, effectivity, zapisy odstępstw	losowa próbka egzemplarzy zgadza się z ewidencją albo każda różnica ma otwarty, śledzony rekord
3 — dowód systemowy	macierz zgodności, śledzenie wymagań, powtarzalne buildy, konfiguracje stanowisk testowych	dla próbki zmian można przejść od wymagania przez decyzję i wdrożenie do wyniku kwalifikacji
4 — odporność cyklu życia	odtwarzalne środowiska, kontrola dostawców, archiwum, próby odtworzeniowe i plan zaniku źródeł	organizacja odtwarza wybrane wydanie, wykazuje ważność dowodów po zmianie i identyfikuje populację zagrożoną utratą wsparcia

Próbka powinna obejmować różne partie, użytkowników, dostawców, ostatnie zmiany, egzemplarze po naprawie i co najmniej jeden przypadek zarejestrowanej rozbieżności. Wynikiem audytu nie jest samo „zgodne/niezgodne”, lecz także odsetek rekordów kompletnych przy pierwszym odczycie, czas rozstrzygnięcia rozbieżności, liczba zmian bez potwierdzonego wdrożenia, udział buildów możliwych do odtworzenia oraz liczba wyników testów, których nie można jednoznacznie przypisać konfiguracji. MIL-HDBK-61B ujmuje identyfikację, kontrolę zmian, ewidencję stanu i audyty jako powiązane funkcje; sam podręcznik jest jednak wskazówką, a nie automatycznie obowiązującym wymaganiem kontraktowym.^zks3b-mil61

Granica odpowiedzialności

Podmiot	Odpowiada co najmniej za	Nie może samodzielnie dowieść
Państwo i użytkownik wojskowy	wymagania operacyjne, warunki przyjęcia, wskazanie organów zatwierdzających, akceptację ryzyka, ewidencję wojskową i decyzję o gotowości	poprawności nieudostępnionej definicji dostawcy ani zgodności systemowej bez wyników integratora
Integrator systemu	baseline integracyjny, interfejsy, manifest zgodności, analizę wpływu między CI, próby systemowe i konfigurację dostarczonego zestawienia	wewnętrznej zgodności produktu dostawcy poza zakresem otrzymanych danych i zapewnień
Dostawca produktu lub technologii	definicję i wydanie własnego CI, kwalifikację w zadeklarowanym zakresie, identyfikację dostawy, notyfikację zmian i wsparcie analizy wpływu	zdolności całego łańcucha po połączeniu z elementami pozostającymi poza jego kontrolą
Krajowy wykonawca produkcyjny	zgodność wykonania z przekazaną definicją, kontrolę procesu, identyfikowalność partii i zapis lokalnych odstępstw	ważności pierwotnych dowodów po zmianie procesu bez uzgodnionej analizy i kwalifikacji
Organ kwalifikujący lub odbiorczy	ocenę dowodów wobec ustalonych kryteriów oraz zapis zakresu zatwierdzenia	gotowości operacyjnej jednostki, jeżeli poza próbą pozostają szkolenie, logistyka, obsada lub integracja nadrzędna

Granice muszą spotykać się na kontrolowanych interfejsach. Luka odpowiedzialności powstaje wtedy, gdy dwie strony zakładają, że druga analizuje wpływ; nakładanie się odpowiedzialności — gdy obie mogą niezależnie zatwierdzić to samo pole. Pierwszy przypadek pozostawia zmianę bez właściciela, drugi dopuszcza dwa konkurencyjne baseline’y.

Synteza dla Sił Zbrojnych RP

CM może udowodnić, że konkretny egzemplarz lub zestawienie odpowiada zidentyfikowanemu stanowi, że zmiany przeszły właściwą ścieżkę zatwierdzania, że użyto zgodnych wydań sprzętu, kodu i danych oraz że przywołane wyniki badań dotyczą tej konfiguracji. Pozwala także wykazać zakres niepewności: nieznaną historię części, brak potwierdzenia wdrożenia, wygasłą kalibrację albo wynik próby odnoszący się do innego wariantu.

CM nie dowodzi sam przez się skuteczności bojowej, bezpieczeństwa, niezawodności, odporności środowiskowej, wyszkolenia obsady, dostępności logistycznej ani gotowości dowódcy do wykonania zadania. Dla tych tez potrzebne są odpowiednio: wyniki weryfikacji i walidacji, kwalifikacja, próby odbiorcze i systemowe, analizy bezpieczeństwa, dane niezawodnościowe, certyfikacja personelu, sprawdzenie zapasów i wsparcia oraz formalna decyzja właściwego organu wojskowego.

W Narwi rozróżnienie to ma znaczenie zasadnicze. Publiczne dowody pozwalają opisać dostarczoną, badaną i używaną Małą Narew z CAMM oraz zakontraktowaną, integrowaną i uprzemysławianą docelową Narew z CAMM-ER. Nie pozwalają połączyć tych dwóch gałęzi w twierdzenie, że kwalifikacja Małej Narwi automatycznie obejmuje CAMM-ER, IBCS, przyszłe polskie procesy produkcyjne i wszystkie docelowe sensory. Każde takie rozszerzenie wymaga osobnego mostu dowodowego.

Ostatecznym produktem CM nie jest więc uporządkowane archiwum, lecz odtwarzalna odpowiedź: jaka konfiguracja stoi przed użytkownikiem, jaki zakres zdolności został dla niej wykazany, które dowody pozostają ważne i kto ponosi odpowiedzialność za nierozstrzygniętą część ryzyka. Dopiero po dołączeniu dowodów technicznych, logistycznych, szkoleniowych i operacyjnych odpowiedź ta może stać się podstawą decyzji o gotowości.