Elektroniczny PDT a Part-ML: co musi umieć system zapisów

Pytanie, które pada najczęściej, brzmi: „czy w ogóle wolno prowadzić pokładowy dziennik techniczny elektronicznie?”. Przepis nie mówi „papier”. Mówi: system zapisów ciągłej zdatności. Papier jest jedną z możliwych implementacji tego systemu, a nie wymaganiem samym w sobie.

To nie znaczy, że dowolna aplikacja wystarczy. Poniżej jest lista tego, co realnie trzeba mieć, zanim rozmowa z nadzorem stanie się rozmową o terminie, a nie o zasadzie.

Co wymaga ML.A.305

Zapisy ciągłej zdatności obejmują cztery grupy informacji i wszystkie muszą być spójne między sobą:

• zapis każdego lotu — czasy, lądowania i cykle, stan liczników,
• zapis wykonanej obsługi z odniesieniem do poświadczenia (CRS),
• aktualny status programu obsługi, dyrektyw zdatności i części o ograniczonej żywotności,
• zapisy dokładne i aktualne, zabezpieczone przed zmianą, przechowywane przez wymagany okres i przekazywane razem ze statkiem przy zmianie właściciela.

Najczęstsza słabość obiegu papierowo-arkuszowego nie leży w żadnym z tych punktów z osobna. Leży pomiędzy nimi: PDT zostaje w kabinie, program obsługi żyje w arkuszu w biurze, a spina je człowiek przepisujący godziny. Każde przepisanie to nowa okazja do rozjazdu, którego nikt nie zauważy do czasu kontroli albo przekroczonego resursu.

Dlatego w systemie elektronicznym najważniejsze jest nie to, że „jest w komputerze”, tylko że istnieje jeden łańcuch danych: lot → licznik → resurs → obsługa → poświadczenie → status zdatności widoczny z powrotem u pilota. Jeżeli aplikacja wymaga, żeby ktoś przepisał nalot z jednego ekranu do drugiego, powiela dokładnie ten sam problem, tylko szybciej.

Co dokłada AMC1 ML.A.305 dla systemu skomputeryzowanego

Materiał akceptowalnych sposobów spełnienia wymagań opisuje warunki dla systemu skomputeryzowanego wprost. W praktyce operator musi umieć odpowiedzieć na pięć pytań:

Pytanie inspektora	Czego dotyczy
Kiedy ostatnio wykonano kopię zapasową?	Kopia aktualizowana w ciągu 24 godzin od nowego wpisu
Gdzie ta kopia leży?	Nośnik odrębny od danych roboczych, kopia okresowa poza środowiskiem produkcyjnym
Czy zapisy da się odczytać za trzy lata?	Czytelność przez cały okres przechowywania — wydruk A4, PDF, format otwarty (CSV)
Kto mógł zmienić ten wpis?	Ochrona przed nieautoryzowaną zmianą i kontrola dostępu
Co robicie, gdy system nie działa?	Udokumentowana procedura awaryjna i odtworzenia zapisów

Warto zauważyć, na co te pytania nie są nastawione. Nie na to, czy interfejs jest ładny i czy istnieje aplikacja mobilna, tylko na to, czy zapis, który dziś wygląda poprawnie, będzie tak samo wiarygodny za trzy lata i czy da się wykazać, że nikt go po drodze nie poprawił.

Jak wykazać niezmienność, a nie tylko ją zadeklarować

Deklaracja „nasz system nie pozwala edytować wpisów” jest warta tyle, ile mechanizm, który za nią stoi. Do wykazania nadają się trzy rzeczy, najlepiej razem:

1. Zapisy przyrostowe zamiast nadpisywanych. Stan licznika nie jest polem, które się nadpisuje, tylko sumą strumienia odczytów. Wartość bieżąca powstaje z historii, więc „poprawienie licznika” bez śladu jest niemożliwe z definicji.
2. Blokada w warstwie bazy danych, nie w aplikacji. Jeżeli niemutowalność jest tylko w kodzie interfejsu, to znaczy, że administrator bazy może zmienić wpis. Blokada powinna zadziałać także wtedy, gdy ktoś ominie aplikację.
3. Rejestr zdarzeń spięty łańcuchem skrótów. Każdy wiersz zawiera skrót obejmujący skrót wiersza poprzedniego. Usunięcie, wstawienie albo podmiana dowolnego wiersza zrywa łańcuch — i jest wykrywalna narzędziem, które można uruchomić przy inspektorze.

Do tego dochodzi rzecz, którą operatorzy odkrywają dopiero w praktyce: korekta musi być przewidziana z góry. Skoro podpisanego wpisu nie wolno edytować, potrzebny jest mechanizm storna — zapisu odwrotnego z przyrostami kompensującymi i obowiązkowym uzasadnieniem, po którym wprowadza się wpis poprawny. W rejestrze zostają oba. To jest dokładnie ta sama logika co przekreślenie w dzienniku papierowym z parafką, tylko bez możliwości „poprawienia korektorem”.

Podpis elektroniczny: co warto ustalić z nadzorem

Sam podpis jest zwykle najkrótszą częścią rozmowy, jeżeli przygotujesz cztery elementy:

• tożsamość — podpisującym jest wyłącznie osoba zalogowana; nie istnieje pole „w czyim imieniu”,
• potwierdzenie woli — ponowne podanie hasła bezpośrednio przed złożeniem podpisu,
• czas — znacznik serwera, nigdy zegar urządzenia pilota,
• treść objęta podpisem — zamknięta lista pól i jej skrót kryptograficzny zapisany razem z wpisem.

Ostatni punkt bywa pomijany, a jest kluczowy: bez jawnie zdefiniowanego zakresu podpisu nie da się później powiedzieć, co dokładnie zostało podpisane. Jeżeli do wpisu dołoży się kiedyś nowe pole, trzeba świadomie zdecydować, czy wchodzi ono do zakresu skrótu — dołożenie go po cichu unieważnia dowód niezmienności wcześniejszych wpisów.

Dual-run, czyli jak to wygląda w praktyce

Nawet komplet mechanizmów nie zwalnia z procedury. Praktyczna ścieżka — rozpisana szerzej w opracowaniu o przejściu z papieru na system elektroniczny — wygląda tak:

1. Przygotuj opis systemu dla nadzoru: skąd biorą się dane, kto je zatwierdza, jak wykazujesz integralność, jak wygląda procedura awaryjna.
2. Wprowadź bilans otwarcia — stan startowy z dziennika papierowego, pod podpisem mechanika, z widocznym wykazem przyjętych założeń.
3. Prowadź dual-run: przez uzgodniony okres dziennik papierowy i elektroniczny równolegle, z jasną regułą, który rozstrzyga w razie rozbieżności.
4. Zbierz listę punktów do potwierdzenia przez nadzór — wykładnia okresów przechowywania, zgodność wzoru wydruku wpisu, uznanie podpisu elektronicznego, zakres i data zakończenia dual-runu.

Ten ostatni punkt to nie formalność. To jest lista, na której kończy się „system spełnia wymagania” w wersji marketingowej, a zaczyna się to, co faktycznie jest uzgodnione z konkretnym nadzorem.

Podsumowanie

Elektroniczny dziennik pokładowy jest dopuszczalny, o ile jest systemem zapisów, a nie ładniejszym arkuszem. Sprawdzian jest prosty i można go zrobić na każdej aplikacji w piętnaście minut: zapytaj, co się stanie po podpisaniu wpisu z błędem, kto i jak wykrywa zmianę wiersza w bazie oraz co dokładnie ląduje w paczce dla inspektora. Odpowiedzi na te trzy pytania mówią o systemie więcej niż cała lista funkcji.