Wspólna nazwa rodziny uzbrojenia jest użytecznym skrótem, ale nie identyfikuje konfiguracji. Pod jednym oznaczeniem mogą występować pociski różniące się głowicą naprowadzającą, komputerem, oprogramowaniem, napędem, interfejsem wyrzutni, zakresem dopuszczonych nosicieli albo wyposażeniem testowym. Jeżeli cechę udokumentowaną dla jednego z tych wyrobów przypisze się całej rodzinie, powstaje opis obiektu, który nigdy nie istniał.

To nie jest drobiazg terminologiczny. Błąd konfiguracji może prowadzić do fałszywej oceny zasięgu, odporności, sposobu naprowadzania lub zgodności z platformą. W eksploatacji ten sam błąd przyjmuje postać niewłaściwego pakietu danych, niezgodnego urządzenia testowego albo dokumentacji odnoszącej się do innego stanu modyfikacji. Dlatego jednostką wiedzy encyklopedycznej nie jest „fakt o rodzinie”, lecz twierdzenie powiązane z jednoznacznie opisanym obiektem, zakresem obowiązywania, czasem i źródłem.

Teza tej monografii brzmi: wiarygodna informacja techniczna jest kontrolowaną relacją między twierdzeniem, obiektem systemowym, konfiguracją sprzętu i oprogramowania, zakresem obowiązywania oraz dowodem źródłowym. Utrata któregokolwiek z tych powiązań zmienia wiedzę w domysł, nawet gdy sama liczba lub nazwa została poprawnie przepisana. Takie ujęcie rozwija klasyczne funkcje identyfikacji, kontroli zmian, ewidencji stanu i audytu konfiguracji, ale stosuje je do jednostkowych twierdzeń encyklopedycznych.1,4

1. Nazwa nie jest konfiguracją

Nazwa rodziny odpowiada na pytanie „do jakiej linii rozwojowej należy wyrób?”. Konfiguracja odpowiada na znacznie węższe pytanie: „z jakich zatwierdzonych elementów i danych składał się ten egzemplarz lub ta populacja w określonej chwili?”. Rodzina porządkuje historię. Konfiguracja pozwala rozstrzygać zdolność, zgodność i znaczenie wyniku próby.

Najprostszy błąd polega na przeniesieniu cechy nowszego wariantu wstecz. Jeżeli późniejszy pocisk otrzymał nową głowicę naprowadzającą, nie wynika z tego, że wcześniejsze egzemplarze tej samej rodziny mogły korzystać z jej trybów pracy. Błąd odwrotny jest równie groźny: ograniczenie opisane w starej instrukcji bywa przypisywane wersji po modernizacji, choć zmieniono sprzęt, kod i urządzenia obsługowe.

Drugi błąd powstaje wtedy, gdy nazwa programu zostaje utożsamiona z nazwą produktu. Program może obejmować kilka efektorów, sensory, stanowiska dowodzenia, wyrzutnie i kolejne wydania oprogramowania. Zdolność ogłaszana dla programu nie musi istnieć w każdym zestawie dostarczonym użytkownikowi. Trzeba znać konfigurację całego łańcucha, nie tylko symbol pocisku.

Trzeci błąd dotyczy czasu. Prawdziwe zdanie może stać się fałszywe, jeśli usunie się datę. Konfiguracja planowana, zakwalifikowana, dostarczona i utrzymywana to cztery różne stany. Informacja prasowa o pomyślnej próbie nie dowodzi, że wszystkie wcześniejsze egzemplarze otrzymały badaną zmianę. Z kolei wycofanie jednego bloku nie oznacza wycofania rodziny.

2. Jednostki opisu

Poprawny rekord zaczyna się od wyboru obiektu. W technice rakietowej kilka poziomów łatwo zlać w jedną nazwę:

Poziom Co opisuje Typowy błąd
program przedsięwzięcie rozwojowe i zakupowe przypisanie deklaracji programu gotowemu wyrobowi
system uzbrojenia współdziałający łańcuch sensorów, dowodzenia, wyrzutni, efektorów i wsparcia utożsamienie parametrów radaru z parametrami pocisku
zestaw określona konfiguracja elementów systemu u użytkownika założenie, że każdy zestaw ma tę samą wersję oprogramowania
rodzina produktu linia genealogiczna wyrobów przenoszenie cech między generacjami
typ lub wariant pocisku wyrób o rozpoznawalnym zestawie cech pominięcie odmiany eksportowej albo użytkownika
blok lub stan modyfikacji kontrolowany etap rozwoju wariantu traktowanie modernizacji jako zmiany samej nazwy
partia populacja związana z określonym przebiegiem produkcji zastąpienie partii samą datą
egzemplarz pojedynczy wyrób o własnej historii wnioskowanie o nim z konfiguracji nominalnej

Poziomy te nie tworzą jednej prostej drabiny. System uzbrojenia zawiera elementy wielu rodzin, a konkretny pocisk może być zgodny z kilkoma konfiguracjami wyrzutni. Partia przecina wariant i czas produkcji, natomiast modyfikacja eksploatacyjna może objąć tylko część egzemplarzy z tej samej partii.

Dlatego model danych powinien rozdzielać hierarchię produktu od osi klasyfikacyjnych. Hierarchia mówi, co jest częścią czego. Osie mówią, w jakim wariancie, czasie, stanie modyfikacji, u jakiego użytkownika i z jakim poziomem pewności dana relacja obowiązuje.

SYSTEM UZBROJENIA
├── sensor i źródła danych
├── dowodzenie i kierowanie walką
├── wyrzutnia lub platforma
│   └── interfejs pocisku
├── pocisk
│   ├── płatowiec i napęd
│   ├── naprowadzanie i sterowanie
│   ├── zasilanie i łączność
│   └── ładunek użyteczny
└── wsparcie
    ├── urządzenia testowe
    ├── oprogramowanie i dane
    ├── dokumentacja
    └── szkolenie

To drzewo jest tylko szkieletem. Nie dowodzi, że każdy element jest oddzielną pozycją konfiguracji. Pokazuje natomiast, gdzie należy przypisać twierdzenie. Zasięg obserwacji należy do sensora i warunków jego użycia; zasięg kinematyczny należy do konkretnego efektora i profilu; zdolność systemowa wynika z ich współdziałania. Umieszczenie wszystkich trzech wartości w jednym rekordzie bez wskazania właściciela tworzy pozorną precyzję.

3. Hierarchia produktu i osie ortogonalne

Hierarchia produktu odpowiada na pytanie o dekompozycję. Wariantowość jest problemem wielowymiarowym. Ten sam element może mieć jednocześnie:

  • numer części identyfikujący projekt lub zamienność;
  • rewizję dokumentacji;
  • numer seryjny identyfikujący egzemplarz;
  • partię materiałową lub produkcyjną;
  • stan modyfikacji;
  • wydanie oprogramowania;
  • obraz firmware'u albo FPGA;
  • komplet danych kalibracyjnych;
  • zakres dopuszczonych platform;
  • status kwalifikacji obowiązujący w określonym czasie.

Nie wolno zamieniać tej siatki w listę „coraz dokładniejszych nazw”. Rewizja rysunku nie jest poziomem poniżej numeru seryjnego, a wydanie programu nie jest podtypem partii. Są to odmienne osie, które spotykają się dopiero w rekordzie rzeczywistego egzemplarza albo kontrolowanej konfiguracji odniesienia.

Pytanie Wymiar danych Przykładowa odpowiedź
co to jest? encja i miejsce w strukturze produktu komputer pokładowy określonego wariantu
jaki projekt? numer części, model, blok projekt po zatwierdzonej zmianie
który egzemplarz? numer seryjny pojedynczy komputer w konkretnym pocisku
z jakiej populacji? partia i okres produkcji seria objęta wspólnym procesem
co zainstalowano? konfiguracja wykonana sprzęt, kod i dane zapisane w as-built
co obowiązuje dziś? stan utrzymywany konfiguracja po naprawach i aktualizacjach
gdzie wolno użyć? zgodność i ograniczenia lista dopuszczonych platform i interfejsów
skąd to wiadomo? źródło i poziom pewności dokument odbiorczy, instrukcja albo ostrożna rekonstrukcja

Zaletą rozdzielenia osi jest możliwość przedstawienia niepełnej wiedzy bez jej fałszowania. Źródło może jednoznacznie wskazywać wariant, ale nie partię. Inne może dokumentować partię, lecz nie wersję kodu. Rekord zachowuje obie informacje i pozostawia jawne luki. Nie skleja ich w „najbardziej prawdopodobną” superkonfigurację.

4. Słownik tożsamości konfiguracji

Rodzina grupuje produkty o wspólnym pochodzeniu konstrukcyjnym lub programowym. Nie gwarantuje wspólnych interfejsów ani osiągów.

Model lub typ jest formalnym albo zwyczajowym oznaczeniem wyrobu. Jego znaczenie trzeba odczytywać z dokumentacji danego programu, ponieważ ta sama kultura oznaczeń nie obowiązuje wszędzie.

Wariant oznacza rozpoznawalną odmianę produktu. Może wynikać z innego użytkownika, przeznaczenia, wyposażenia lub ograniczeń eksportowych. Wariant nie zawsze oznacza nowszą generację.

Blok jest kontrolowanym etapem rozwoju, często grupującym zestaw zmian. Nie należy zakładać, że numeracja bloków jest ciągła ani że każda zmiana bloku obejmuje wszystkie podsystemy.

Modyfikacja zmienia zatwierdzony stan produktu. Może dotyczyć projektu, egzemplarza, dokumentacji, oprogramowania albo danych. Samo zatwierdzenie modyfikacji nie dowodzi jej fizycznego wdrożenia.

Rewizja identyfikuje zmianę dokumentu, projektu lub elementu według reguł właściciela danych. Symbol „C” bez numeru dokumentu i jego typu nie jest pełnym identyfikatorem.

Wydanie opisuje zatwierdzony pakiet oprogramowania lub danych przeznaczony do określonego użycia. Build wskazuje konkretny wynik procesu budowania. Dwa buildy z tych samych źródeł mogą nie być równoważne, jeżeli różniły się narzędzia, biblioteki, opcje albo wygenerowane dane.

Partia wiąże populację z określonym przebiegiem produkcji, materiałem lub kontrolą procesu. Data jest tylko jednym z jej atrybutów.

Numer seryjny identyfikuje pojedynczy egzemplarz. Nie mówi samodzielnie, jaki projekt i jakie zmiany w nim zastosowano.

Punkt bazowy konfiguracji (configuration baseline) jest zatwierdzonym opisem służącym jako odniesienie dla dalszych zmian. Nie jest synonimem katalogu części ani kopii repozytorium.1

Zakres obowiązywania (effectivity) wskazuje populację, której dotyczy zmiana, dokument, ograniczenie albo dowód. Może być opisany wariantem, blokiem, partią, przedziałem numerów seryjnych, datą, użytkownikiem lub ich kombinacją.1

Najważniejszą zasadą słownika jest lokalność znaczenia. Oznaczenia są danymi programu, nie prawami natury. Jeżeli producent używa słowa „mod” inaczej niż użytkownik wojskowy, rekord powinien zachować oba terminy, wskazać właściciela i zmapować relację zamiast narzucać jedną pozornie uniwersalną definicję.

5. Kręgosłup normatywny i pojęcia CM

Standardy zarządzania konfiguracją nie ustanawiają jednego natowskiego numeru firmware'u. Porządkują odpowiedzialność, identyfikację, kontrolę zmian, ewidencję stanu i audyty, natomiast schemat oznaczeń pozostaje częścią konkretnego programu i kontraktu.

STANAG 4427 tworzy wspólne ramy NATO dla zarządzania konfiguracją w cyklu życia i wskazuje publikacje ACMP-2000, ACMP-2009 oraz ACMP-2100.8 Rodzina ACMP rozwija tę ramę na różnych poziomach: ACMP-2000 opisuje politykę,14 ACMP-2009 dostarcza wskazówek stosowania,10 a ACMP-2100 formułuje wymagania kontraktowe.11 AQAP-2110 dotyczy zapewnienia jakości podczas projektowania, rozwoju i produkcji,12 natomiast AQAP-2210 uzupełnia wymagania jakościowe w odniesieniu do oprogramowania.13 Dokumenty te trzeba stosować według ich statusu, wydania oraz przywołania w umowie; sama obecność skrótu w bibliografii nie czyni wszystkich postanowień obowiązującymi.

SAE/EIA-649 porządkuje zasady zarządzania konfiguracją niezależnie od jednego resortu lub rodzaju produktu. MIL-HDBK-61B jest z kolei podręcznikiem DoD: objaśnia praktyki, terminologię i dobór środków CM, lecz nie jest samodzielnym wymaganiem kontraktowym. Wymaganie powstaje dopiero przez właściwy dokument zamówienia, standard albo zapis umowy.1,9

Pozycja konfiguracji (configuration item, CI) jest wybranym elementem produktu podlegającym odrębnej identyfikacji i kontroli. Nie musi być pojedynczą częścią; może obejmować podsystem, urządzenie, program albo pakiet danych.

Pozycja konfiguracji oprogramowania (computer software configuration item, CSCI) jest kontrolowanym składnikiem oprogramowania, dla którego ustanawia się własne wymagania, wersje, dowody i odpowiedzialność. Nie każde repozytorium ani moduł kodu musi być CSCI.

Pozycja firmware'u obejmuje kod lub dane trwale związane z urządzeniem, ale jej granice muszą zostać zdefiniowane lokalnie. W praktyce trzeba rozdzielić źródła, narzędzia, obraz wynikowy, programowalny element i manifest instalacji. Nazwanie wszystkiego „firmware” bez tych relacji ukrywa konfigurację.

Klasyczne punkty bazowe opisują inne poziomy dojrzałości:

  • funkcjonalny punkt bazowy (functional baseline, FBL) utrwala zatwierdzone funkcje i wymagania systemu;
  • przydzielony punkt bazowy (allocated baseline, ABL) wiąże wymagania z pozycjami konfiguracji oraz interfejsami;
  • produktowy punkt bazowy (product baseline, PBL) opisuje wyrób wystarczająco dokładnie, by go wytwarzać, testować i utrzymywać.

Rekord egzemplarza zbudowanego albo utrzymywanego nie powinien automatycznie otrzymywać nazwy czwartego rodzaju baseline'u. Może być kontrolowanym opisem as-built lub as-maintained powiązanym z PBL, odstępstwami i historią modyfikacji. Terminologię programu trzeba zachować, ale nie wolno zacierać różnicy między normatywnym opisem produktu a zapisem jego rzeczywistego stanu.1

Propozycja zmiany inżynierskiej (engineering change proposal, ECP) opisuje potrzebę, treść, zakres, wpływ i sposób wdrożenia trwałej zmiany. Ewidencja stanu konfiguracji (configuration status accounting, CSA) odpowiada na pytanie, jakie konfiguracje, zmiany, odstępstwa i statusy dotyczą poszczególnych wyrobów. ECP steruje zmianą; CSA nie zatwierdza jej, lecz utrzymuje możliwy do audytu obraz decyzji i wykonania.

Audyt funkcjonalny konfiguracji (functional configuration audit, FCA) sprawdza, czy zweryfikowane funkcje odpowiadają zatwierdzonym wymaganiom. Audyt fizyczny konfiguracji (physical configuration audit, PCA) porównuje reprezentatywny produkt z dokumentacją produktowego punktu bazowego. Żaden z nich nie zastępuje inspekcji każdego egzemplarza ani pełnego odbioru partii.

6. Sprzęt, kod, firmware i dane

Konfiguracja nie kończy się na wykazie części. Funkcja współczesnego podsystemu powstaje z połączenia sprzętu, oprogramowania, firmware'u i danych. Zgodny mechanicznie komputer może wykonywać kod przeznaczony dla innej rewizji wejść/wyjść. Poprawny kod może korzystać z niewłaściwych stałych kalibracyjnych. Zgodny obraz FPGA może zostać zbudowany inną wersją narzędzia i nie odpowiadać artefaktowi użytemu w kwalifikacji.

Minimalny model rozdziela cztery warstwy:

  1. sprzęt — części, zespoły, interfejsy, materiały i procesy;
  2. oprogramowanie — źródła, zależności, ustawienia budowania i obraz wykonywalny;
  3. firmware oraz logika programowalna — kod źródłowy, własność intelektualna, ograniczenia czasowe, narzędzia i wynikowy obraz;
  4. dane — kalibracje, tablice zgodności, parametry, schematy wiadomości, dane testowe i pakiety ładowalne.

Warstwy łączy manifest konfiguracji. Powinien pozwalać przejść od wyniku próby do dokładnego zestawu artefaktów oraz od egzemplarza do dowodu, który pozostaje dla niego ważny. Suma poprawnych identyfikatorów nie wystarcza: trzeba jeszcze znać regułę zgodności. Dwa elementy mogą być osobno dopuszczone, a mimo to nie tworzyć zakwalifikowanej pary.

Szczególnie ważne są dane, ponieważ często zmieniają zachowanie bez zmiany programu wykonywalnego. Tablica kalibracyjna, mapa zgodności wyrzutnia–pocisk, opis układu współrzędnych albo parametry urządzenia testowego mogą zdecydować, czy identyczne bity kodu wykonują właściwą funkcję. Dane muszą więc mieć właściciela, schemat, wersję, sumę kontrolną, zakres obowiązywania i ślad zatwierdzenia.

7. Granica systemu i macierz zgodności

Konfiguracja pocisku jest konieczna, lecz niewystarczająca do opisania zdolności systemu. Efektor działa w łańcuchu, którego elementy wymieniają energię, informacje, komendy i dowody stanu. Granica analizy powinna obejmować przynajmniej te elementy, których niezgodność może zmienić wynik misji albo ocenę gotowości.

Praktycznym narzędziem jest macierz zgodności. Jej wiersze opisują konkretne konfiguracje pocisku, a kolumny — wyrzutnie, platformy, wydania systemu dowodzenia, sensory, urządzenia testowe, pakiety danych i dokumentację. Komórka nie zawiera prostego „tak/nie”, lecz status oraz podstawę:

Status Znaczenie
potwierdzona zgodność wykazana dla wskazanych konfiguracji i warunków
ograniczona zgodność istnieje z jawnym ograniczeniem zakresu
planowana integracja zapowiedziana, lecz jeszcze niewykazana
niezgodna znana sprzeczność interfejsu albo dopuszczenia
brak danych nie odnaleziono podstawy do rozstrzygnięcia
nieujawniona wiadomo, że informacja istnieje, lecz nie jest publiczna
spór źródłowy wiarygodne źródła prowadzą do różnych wniosków
nie dotyczy relacja nie ma sensu dla danych encji

Puste pole nie jest żadnym z tych stanów. Pustka usuwa informację o tym, czy autor nie szukał, nie znalazł, nie może opublikować, czy dana relacja w ogóle nie istnieje. W encyklopedii technicznej każda komórka ważna dla wniosku powinna mieć jawny status.

Macierz chroni też przed myleniem poziomów. Informacja, że program zintegrowano z nowym systemem dowodzenia, nie dowodzi zgodności każdego starszego pocisku. Informacja, że wyrzutnia może mechanicznie pomieścić dany kontener, nie dowodzi zgodności elektrycznej, logicznej, proceduralnej ani kwalifikacyjnej. Zdolność należy przypisać dopiero przecięciu wszystkich wymaganych konfiguracji.

W tym miejscu kończy się opis statycznej tożsamości. Kolejny krok jest trudniejszy: konfiguracja zmienia się w czasie. Trzeba więc odróżnić stan projektowany, zbudowany, dostarczony i utrzymywany, a następnie zachować pochodzenie każdej zmiany oraz ważność dowodów, które na niej zależą.

8. Cztery konfiguracje jednego wyrobu

W dokumentacji programu występuje przynajmniej kilka prawdziwych, ale różnych odpowiedzi na pytanie „jaka jest konfiguracja?”.

Konfiguracja projektowana opisuje stan przewidziany w zatwierdzonych wymaganiach, rysunkach, kodzie źródłowym i danych. Jest odpowiedzią normatywną: tak wyrób powinien wyglądać.

Konfiguracja zbudowana zapisuje rzeczywisty egzemplarz lub partię. Obejmuje numery seryjne, partie części, wyniki procesów specjalnych, zainstalowane obrazy, kalibracje oraz zaakceptowane odstępstwa. Nie każda różnica względem projektu jest błędem; może być zatwierdzonym odchyleniem. Musi jednak pozostać widoczna.

Konfiguracja dostarczona uwzględnia komplet przekazany użytkownikowi: wyrób, dokumentację, urządzenia testowe, oprogramowanie, dane, części zamienne i ograniczenia. Można dostarczyć poprawny pocisk wraz z nieaktualnym pakietem wsparcia, a wtedy zdolność całego zestawu pozostaje niepełna.

Konfiguracja utrzymywana jest aktualnym stanem po naprawach, wymianach, aktualizacjach i ograniczeniach. Stanowi konieczne wejście do oceny dzisiejszej gotowości konkretnego egzemplarza, lecz sam jej nie dowodzi: potrzebne są także dane o stanie technicznym, resursie, wykonanej obsłudze, wynikach kontroli i aktualnych niesprawnościach. Nie wolno jej wyprowadzać wyłącznie z dokumentacji projektu ani z daty produkcji. MIL-HDBK-61B rozdziela konfigurację bieżącą, zapis produktu i kolejne punkty bazowe, co pozwala powiązać stan rzeczywisty z normatywnym opisem bez uznawania ich za synonimy.1

Rozdzielenie tych stanów wyjaśnia pozorny paradoks: dwa prawdziwe dokumenty mogą opisywać różne konfiguracje tego samego numeru seryjnego. Protokół odbioru zapisuje stan dostawy, a późniejszy rekord obsługowy — stan po modyfikacji. Sprzeczność pojawia się dopiero wtedy, gdy oba źródła zostaną przedstawione jako równoczesny opis.

9. Zmiana, zakres obowiązywania i ważność dowodu

Zmiana zaczyna się od potrzeby: anomalii, nowego wymagania, braku części, poprawy niezawodności albo integracji z innym elementem systemu. Następnie trzeba określić dotknięte pozycje konfiguracji, interfejsy, dokumenty, kod, dane, urządzenia testowe i szkolenie. Dopiero po analizie wpływu można zdecydować, czy istniejący dowód kwalifikacyjny pozostaje ważny.2

Pełny łańcuch ma postać:

potrzeba lub anomalia
        ↓
identyfikacja przyczyny i dotkniętych konfiguracji
        ↓
propozycja zmiany oraz warianty rozwiązania
        ↓
analiza wpływu na funkcje, interfejsy i dowody
        ↓
zatwierdzenie i nowy punkt bazowy
        ↓
kwalifikacja zmienionego zakresu
        ↓
wdrożenie produkcyjne i/lub modernizacja istniejących egzemplarzy
        ↓
aktualizacja dokumentacji, ATE, danych i szkolenia
        ↓
potwierdzenie konfiguracji utrzymywanej

Zakres obowiązywania zmiany nie jest tym samym co jej status. „Zatwierdzona” oznacza decyzję. „Wydana” oznacza dostępność pakietu. „Wbudowana” oznacza fizyczne lub programowe zastosowanie. „Zweryfikowana po wdrożeniu” oznacza potwierdzenie rezultatu. Zastąpienie tych stanów jednym polem „wdrożono” uniemożliwia ocenę floty mieszanej.

Podobnie trzeba kontrolować ważność dowodu. Wynik próby odnosi się do konfiguracji badanego obiektu, aparatury, oprogramowania redukcji danych i warunków. Zmiana nie zawsze unieważnia cały dowód, ale zawsze wymaga oceny. Jeżeli zmieniono tylko oznaczenie dokumentu bez wpływu na produkt, wystarczy wykazać równoważność. Jeżeli zmieniono czas odpowiedzi interfejsu, powtórnego rozpatrzenia wymaga cały łańcuch zależny od opóźnienia.

10. Twierdzenie jako podstawowa jednostka wiedzy

Artykuł encyklopedyczny jest zbiorem twierdzeń, a nie zbiorem dokumentów. Jeden dokument może wspierać wiele tez; jedna teza może wymagać kilku niezależnych źródeł. Dlatego rekord źródła i rekord twierdzenia powinny być rozdzielone.

Minimalny rekord twierdzenia obejmuje:

Pole Pytanie kontrolne
treść co dokładnie stwierdzamy?
podmiot do jakiej encji systemu odnosi się zdanie?
wariant jaki model, blok lub odmiana jest objęta?
czas w jakim okresie zdanie obowiązuje?
zakres czy dotyczy projektu, partii, egzemplarza czy całej populacji?
status fakt źródłowy, rekonstrukcja, spór czy brak danych?
źródło jaki dokument i lokalizator stanowi podstawę?
pochodzenie czy źródła są rzeczywiście niezależne?
niepewność jakiego rodzaju i jak wpływa na wniosek?
bezpieczeństwo czy poziom szczegółowości jest właściwy do publikacji?

Przykładowe zdanie „wariant X ma łącze danych” jest niekompletne. Trzeba ustalić, czy chodzi o łącze pocisk–platforma, wyrzutnia–pocisk przed startem, czy połączenie elementów systemu naziemnego. Należy wskazać kierunek przepływu, fazę użycia, wariant oraz dokument. Bez tego dwie różne funkcje mogą zostać złączone w jedną pozorną zdolność.

Rozbicie tekstu na twierdzenia nie oznacza pisania telegraficznego. Jest narzędziem zaplecza redakcyjnego. Gotowy artykuł powinien mieć płynną narrację, lecz każde istotne zdanie musi dać się odtworzyć jako relacja twierdzenie–obiekt–zakres–dowód.

11. Stany wiedzy zamiast pustych pól

Brak wartości liczbowej nie jest jedną sytuacją. Co najmniej sześć stanów prowadzi do innych wniosków:

  1. brak danych — poszukiwanie nie dało wiarygodnej podstawy;
  2. nieujawnione — istnienie cechy lub dokumentu jest znane, lecz szczegół nie jest publiczny;
  3. niezweryfikowane — informacja istnieje, ale jej podstawa jest zbyt słaba;
  4. spór źródłowy — wiarygodne źródła są niezgodne;
  5. nie dotyczy — pole nie ma znaczenia dla tej konfiguracji;
  6. nie występuje — wiarygodne źródło potwierdza brak cechy.

„Brak danych” nie dowodzi, że cecha nie występuje. „Nieujawnione” nie upoważnia do oszacowania wartości z podobnego wariantu. „Nie dotyczy” nie jest zerem. „Spór źródłowy” wymaga pokazania granic obu stanowisk, a nie wybrania wygodniejszej liczby.

W tabeli porównawczej status powinien być czytelny bez zaglądania do przypisu. Jeżeli wartość jest rekonstrukcją, trzeba pokazać metodę i przedział, a nie tylko gwiazdkę. Jeżeli źródło nie identyfikuje wariantu, rekord może pozostać na poziomie rodziny — pod warunkiem, że tekst nie przeniesie go niżej.

12. Pochodzenie źródeł i pozorna niezależność

Trzy publikacje powtarzające tę samą tabelę nie są trzema dowodami. Niezależność ocenia się przez pochodzenie informacji, nie liczbę adresów internetowych. Artykuł prasowy może cytować producenta, raport analityczny może przepisać artykuł, a encyklopedia — raport. Wszystkie trzy tworzą jeden łańcuch zależny od pierwotnej deklaracji.

Rekord źródła powinien zachowywać tytuł, instytucję, datę, wersję, lokalizator strony lub rysunku, adres, datę dostępu oraz obiekt i wariant, którego dokument dotyczy. Dla plików warto rejestrować sumę kryptograficzną, ponieważ dokument pod tym samym adresem może zostać zastąpiony nowszą wersją.

Rodzaj źródła wpływa na zakres tezy. Karta producenta dobrze dokumentuje deklarowaną cechę produktu oferowanego w danym czasie. Nie dowodzi samodzielnie wyniku odbioru, dostawy wszystkim użytkownikom ani zachowania w warunkach niewymienionych w karcie. Raport próby dokumentuje badaną konfigurację; nie przenosi automatycznie wyniku na całą rodzinę. Instrukcja eksploatacyjna dobrze opisuje konfigurację objętą wydaniem dokumentu, lecz może nie obejmować wcześniejszych i późniejszych modyfikacji.

13. Model relacyjny rekordu encyklopedycznego

Płaska tabela z jedną kolumną „wariant” szybko przestaje wystarczać. Minimalny model relacyjny powinien rozdzielać:

  • encje produktu i relacje część–całość;
  • identyfikatory wraz z właścicielem systemu oznaczeń;
  • konfiguracje jako kontrolowane zbiory wersji i danych;
  • zakresy obowiązywania odnoszące konfigurację do populacji i czasu;
  • twierdzenia wraz z poziomem pewności;
  • źródła i dokładne lokalizatory;
  • relacje dowodowe mówiące, co dane źródło rzeczywiście wspiera;
  • zdarzenia zmian oraz ich wpływ na konfiguracje;
  • macierze zgodności między elementami systemu.

W takim modelu twierdzenie nie przechowuje dowolnego tekstu „o systemie”. Wskazuje konkretną encję i zakres. Źródło nie jest przypisem do całego akapitu, lecz dowodem określonej relacji. Zmiana nie nadpisuje wcześniejszego stanu; tworzy nową konfigurację z datą i powiązaniem do poprzedniej.

Przykładowo modernizacja komputera pokładowego może utworzyć nowy wariant części, wymagać nowego wydania programu i zmienić zgodność z urządzeniem testowym. Model zapisuje trzy zależności i ich wspólną decyzję, zamiast wpisywać w polu „uwagi” zdanie „zmodernizowano elektronikę”.

Wartość takiego schematu ujawnia się podczas aktualizacji artykułu. Gdy pojawia się nowe źródło, redaktor może wskazać dotknięte twierdzenia i warianty. Nie musi przeszukiwać całej narracji w nadziei, że znajdzie wszystkie miejsca, w których dawna informacja została powtórzona.

14. Studium pierwsze: S-200WE i 5W28E

Rodzina S-200 dobrze pokazuje różnicę między systemem uzbrojenia a pociskiem. Oznaczenie systemu obejmuje elementy wykrywania i wskazywania celu, kanał kierowania ogniem, wyrzutnie, urządzenia przygotowania oraz efektor. Oznaczenie 5W28E odnosi się do konkretnego eksportowego wariantu pocisku. Parametr należący do jednego z tych obiektów nie może zostać bezpośrednio wpisany do rekordu drugiego.

Prawidłowa analiza zaczyna się od dwóch drzew. Pierwsze jest funkcjonalne:

zewnętrzna informacja o sytuacji
        ↓
wybór i przekazanie celu
        ↓
kanał radiolokacyjny i kierowanie ogniem
        ↓
wyrzutnia oraz przygotowany pocisk
        ↓
lot efektora i terminalny kanał naprowadzania

Drugie drzewo jest genealogiczne i rozdziela generacje systemu, odmiany użytkowników oraz odpowiadające im pociski. Dopiero przecięcie obu drzew pozwala sformułować twierdzenie o konfiguracji S-200WE używanej w Polsce. Jeżeli źródło opisuje ogólnie „S-200”, jego informacja pozostaje na poziomie rodziny, dopóki inne dokumenty nie potwierdzą zakresu.

Oficjalny rekord Muzeum Sił Powietrznych nazywa eksponat „przeciwlotniczym zestawem rakietowym S-200WE Wega”, wskazuje wyrzutnię SP-72WE i identyfikuje prezentowany pocisk jako 5W28E.5 Ten jeden rekord wystarcza do potwierdzenia relacji między trzema oznaczeniami w konfiguracji eksponatu. Nie wystarcza natomiast do przypisania wszystkim systemom S-200 wyposażenia polskiego zestawu ani do dowodzenia aktualnego stanu operacyjnego.

Pole rekordu Wartość z dowodu Status i wniosek
system S-200WE Wega potwierdzone dla opisanego eksponatu
wyrzutnia SP-72WE potwierdzona relacja ekspozycyjna z systemem
pocisk 5W28E potwierdzony wariant na wyrzutni
użytkownik i okres polski obiekt muzealny; historia opisana w rekordzie nie należy utożsamiać z bieżącą gotowością
inne odmiany S-200 poza zakresem rekordu brak podstawy do dziedziczenia cech

Przykładowa macierz twierdzeń powinna rozdzielać:

Twierdzenie Właściwy podmiot Warunek publikacji
sposób naprowadzania konkretny wariant pocisku i kanału systemu źródło identyfikuje oba elementy albo jawnie ograniczamy wniosek
liczba kanałów ogniowych konfiguracja stanowiska i okres nie przenosimy między modernizacjami
masa lub wymiary konkretny pocisk nie przypisujemy do całego zestawu
zasięg obserwacji radar w określonych warunkach nie nazywamy go zasięgiem pocisku
status w służbie użytkownik, jednostka i data oddzielamy decyzję, dostawę i gotowość

Najważniejsza lekcja nie dotyczy samego S-200. Nazwa systemu jest węzłem nawigacyjnym, nie pojemnikiem na wszystkie dane. Dobry artykuł może opisać zależności między radarem, wyrzutnią i pociskiem, ale każda liczba oraz cecha musi pozostać przypisana do swojego właściciela.

15. Studium drugie: rodzina AIM-9

Sidewinder zachował nazwę rodziny przez wiele generacji, mimo głębokich zmian głowic naprowadzających, elektroniki, sterowania, interfejsów i integracji z nosicielem. Jest więc dobrym testem odporności bazy wiedzy na dziedziczenie cech.

Najpierw tworzy się oś genealogiczną, która nie zakłada, że każda litera oznacza prostą kolejną generację. Rozdziela się warianty główne, odmiany szkolne, eksportowe, modernizacje i konfiguracje użytkowników. Następnie dla każdego twierdzenia buduje się osobny zakres:

Dziedzina Pytanie
głowica naprowadzająca dla którego wariantu potwierdzono typ sensora i sposób przetwarzania?
elektronika czy źródło opisuje rzeczywisty komputer, czy tylko ogólną funkcję?
oprogramowanie czy informacja dotyczy wariantu, wydania czy całej linii rozwojowej?
łącze danych jaki interfejs, kierunek i faza użycia są udokumentowane?
platforma czy zgodność została wykazana dla konkretnego nosiciela i jego oprogramowania?
osiągi jakie warunki, konfigurację i definicję wielkości podaje źródło?

Załóżmy, że oficjalna karta późnego wariantu potwierdza określoną funkcję cyfrową. Rekord faktu wskazuje ten wariant i datę karty. Nie wolno wypełnić analogiczną wartością kolumn wcześniejszych odmian. Puste pola otrzymują status „brak danych” albo „nie dotyczy”, zależnie od sensu funkcji.

Nie musi to pozostać hipotezą. Oficjalna strona NAVAIR rozdziela AIM-9X Block I i Block II oraz przypisuje Block II łącze danych umożliwiające zdolność lock-on-after-launch.6 Poprawny rekord nie brzmi więc „AIM-9 ma łącze danych”, lecz wiąże funkcję z AIM-9X Block II i zakresem dokumentu.

Twierdzenie Podmiot Dowód Decyzja redakcyjna
istnieją odmiany Block I i Block II AIM-9X oficjalna strona NAVAIR nie przenosić podziału bloków na całą rodzinę AIM-9
Block II korzysta z łącza danych dla wskazanej funkcji AIM-9X Block II ten sam rekord programu nie przypisywać funkcji Block I ani wcześniejszym AIM-9 bez osobnego źródła
wcześniejsze warianty nie mają tej funkcji każda wcześniejsza odmiana osobno brak dowodu w tym rekordzie pozostawić „brak danych”, nie wpisywać „nie występuje”

Następnie pojawia się źródło historyczne opisujące wcześniejszy wariant. Nie zastępuje ono rekordu całej rodziny; tworzy drugi zakres. Dopiero porównanie obu kontrolowanych rekordów pozwala opisać ewolucję. Artykuł nie mówi wtedy „Sidewinder ma cechę X”, lecz „w udokumentowanym wariancie i okresie wprowadzono X, podczas gdy wcześniejsza konfiguracja realizowała funkcję inaczej”.

Ta konstrukcja zapobiega superkonfiguracji: pociskowi z sensorem późnego wariantu, elektroniką pośredniej generacji, zasięgiem z materiału marketingowego i interfejsem nosiciela opisanym w innym programie. Każda z tych informacji może być prawdziwa osobno, ale ich suma jest fałszywym obiektem.

16. Studium trzecie: Patriot, PAC-2 i PAC-3

System systemów ujawnia ograniczenia artykułu zbudowanego wokół jednej nazwy. Patriot może oznaczać program, rodzinę konfiguracji naziemnych albo potoczne określenie całej zdolności obrony powietrznej. PAC-2 i PAC-3 nie są wyłącznie kolejnymi numerami tego samego pocisku. Z tego powodu zdanie „Patriot współpracuje z X” wymaga wskazania konfiguracji, okresu i zakresu wykazanej zgodności.

Historia opublikowana przez U.S. Army pokazuje konkretną pułapkę nazewniczą: „PAC-3 Configuration 1” oznaczało konfigurację sprzętu i oprogramowania systemu, ale — wbrew temu, co sugeruje nazwa — nie obejmowało jeszcze interceptora PAC-3/ERINT. Według źródła efektor pojawił się dopiero w Configuration 3, natomiast Configuration 1 skupiała się na elektronice i optyce systemu współpracującego z PAC-2.7 Rekord konfiguracji systemowej i rekord efektora muszą więc pozostać oddzielne.

Wyrażenie źródłowe Encja Co wolno wywnioskować Czego nie wolno wywnioskować
PAC-3 Configuration 1 konfiguracja systemu Patriot istniał kontrolowany pakiet zmian sprzętu i oprogramowania że nazwa dowodzi obecności interceptora PAC-3
PAC-3 missile/interceptor efektor źródło rozdziela efektor od Configuration 1 i wiąże jego wdrożenie z Configuration 3 że sam pocisk zawiera wszystkie zmiany konfiguracji systemowej
first unit equipped jednostka i zdarzenie w czasie osiągnięto opisany etap wyposażenia że cała flota otrzymała zmianę w tej samej chwili

Model analityczny powinien rozdzielić co najmniej:

  • konfigurację stanowiska dowodzenia i kierowania walką;
  • sensory oraz ich oprogramowanie;
  • wyrzutnie i interfejsy;
  • rodziny efektorów;
  • pakiety danych i zasady identyfikacji;
  • urządzenia testowe i obsługowe;
  • konfigurację dostarczoną konkretnemu użytkownikowi;
  • konfigurację badaną podczas wskazanej próby.

Jeżeli komunikat programu informuje o przechwyceniu podczas próby, wynik dowodzi działania badanego łańcucha w zadeklarowanych warunkach. Nie dowodzi automatycznie, że każda wcześniejsza bateria, każdy efektor i każde wydanie oprogramowania mają tę samą zdolność. Należy zarejestrować konfigurację próby, a potem osobno sprawdzić zakres wdrożenia.

Praktyczna macierz może zawierać wiersze odpowiadające efektorom, a kolumny — wyrzutniom, wydaniom systemu dowodzenia, źródłom śladu, urządzeniom testowym i użytkownikom. Każda komórka wskazuje dowód, ograniczenie i datę. Taka macierz nie ujawnia niejawnych parametrów. Chroni natomiast przed dużo częstszym błędem: myleniem deklarowanej architektury programu ze stanem konkretnego zestawu.

17. Procedura pracy analityka

Metoda powinna być wystarczająco ścisła, by dwóch redaktorów doszło do porównywalnego wyniku.

Krok 1: sformułuj twierdzenie

Zapisz jedno zdanie bez ozdobników. Jeżeli zawiera dwa fakty o różnych obiektach, rozdziel je. Wskaż, czy jest to własność, zdarzenie, relacja zgodności, wynik próby czy status programu.

Krok 2: wybierz podmiot

Przypisz zdanie do programu, systemu, zestawu, pocisku, podsystemu, konfiguracji albo egzemplarza. Jeżeli wybór nie jest jednoznaczny, twierdzenie jest zbyt szerokie.

Krok 3: ustal zakres

Zapisz wariant, blok, użytkownika, okres i populację. Nie wymuszaj danych, których źródło nie podaje. Szerszy, uczciwy zakres jest lepszy niż pozornie precyzyjna rekonstrukcja.

Krok 4: odczytaj rzeczywisty dowód

Ustal, czy źródło opisuje projekt, ofertę, próbę, dostawę czy eksploatację. Zapisz dokładny lokalizator. Sprawdź, czy kolejne publikacje nie pochodzą z tego samego materiału.

Krok 5: nadaj status wiedzy

Rozdziel fakt źródłowy, rekonstrukcję, spór i brak danych. Dla rekonstrukcji podaj przesłanki oraz granice. Nie używaj liczby bez jednostki, definicji i warunków.

Krok 6: sprawdź zgodność systemową

Jeżeli twierdzenie dotyczy zdolności, sprawdź zależne konfiguracje: platformę, wyrzutnię, sensor, oprogramowanie, dane i wsparcie. Zgodność jednego interfejsu nie dowodzi zgodności całego łańcucha.

Krok 7: oceń bezpieczeństwo publikacji

Jawność nie jest jedynym kryterium. Należy uwzględnić ryzyko agregacji oraz ustaloną politykę szczegółowości. Celowe pominięcie powinno mieć jednoznaczny powód, a nie udawać brak wiedzy.

Krok 8: zapisz zmianę bez kasowania historii

Nowe źródło może zawęzić lub rozszerzyć zakres, rozwiązać spór albo ujawnić nowy wariant. Aktualizacja tworzy nową wersję rekordu; poprzednia pozostaje możliwa do odtworzenia. Dzięki temu można wyjaśnić, dlaczego artykuł zmienił się w określonym dniu.

18. Kontrola jakości tabel i schematów

Tabela porównawcza jest modelem, nie dekoracją. Każda kolumna musi odpowiadać jawnie nazwanej konfiguracji, a każdy wiersz — jednej porównywalnej wielkości lub funkcji. Wartości z różnych definicji nie powinny znaleźć się w tym samym wierszu bez objaśnienia.

Przed publikacją tabeli należy sprawdzić:

  1. czy nagłówki identyfikują wariant i okres;
  2. czy jednostki oraz definicje są wspólne;
  3. czy każde istotne pole ma status;
  4. czy przypis znajduje się przy wspieranej wartości;
  5. czy wartość szacowana ma metodę i niepewność;
  6. czy cecha systemu nie została przypisana pociskowi;
  7. czy źródło eksportowe nie zostało przeniesione na wariant krajowy;
  8. czy nowszy materiał nie opisuje jedynie konfiguracji planowanej.

Schemat powinien dodatkowo oznaczać granicę systemu, kierunek przepływu energii i informacji, charakter rekonstrukcji oraz wariant, którego dotyczy. Schemat funkcjonalny nie może udawać fizycznego przekroju. Jeżeli układ jest modelem klasy, podpis musi powiedzieć to wprost.

19. Synteza: jak nie stworzyć systemu, którego nie było

Najpoważniejszym błędem encyklopedii technicznej nie zawsze jest fałszywa liczba. Częściej jest nim prawdziwa liczba przypisana niewłaściwemu wariantowi, prawdziwa funkcja przeniesiona na całą rodzinę albo prawdziwy wynik próby potraktowany jako dowód wdrożenia w całej flocie.

Ochronę zapewniają cztery rozdzielenia:

  1. obiekt od nazwy — najpierw identyfikujemy encję, potem używamy oznaczenia;
  2. hierarchię od osi konfiguracji — część–całość nie zastępuje wariantu, partii i czasu;
  3. stan projektu od stanu egzemplarza — dokumentacja nominalna nie jest as-built ani as-maintained;
  4. twierdzenie od źródła — dokument wspiera określony zakres, nie cały artykuł.

Dobra baza danych nie usuwa niepewności. Rejestruje ją w formie, która nie zmienia się po przeniesieniu do tabeli lub narracji. „Brak danych”, „nieujawnione”, „spór” i „nie dotyczy” są informacją, a nie niedokończoną redakcją.

Wspólna nazwa rodziny pozostaje użyteczna, jeśli prowadzi do kontrolowanej genealogii. Wariant pozostaje użyteczny, jeśli nie ukrywa różnic partii i oprogramowania. Konfiguracja pozostaje wiarygodna, jeśli można odtworzyć jej skład, zakres obowiązywania i dowód. Dopiero wtedy artykuł opisuje rzeczywisty system w określonym czasie, zamiast składać idealny pocisk z najlepszych cech kilku generacji.

Bibliografia i rejestr źródeł