Przejdź do treści
CamoBook — Strona główna CamoBook

Resursy i CAMO

Silnik resursów: terminy liczone z faktów, nie z pamięci

Punkty „due” powstają wyłącznie ze zdarzeń — wykonania zadania, rewizji programu obsługi, zabudowy komponentu. To, ile zostało i jaki jest status, liczy się dopiero przy odczycie, z bieżących liczników i dzisiejszej daty. Dlatego nic nie zależy od nocnego zadania, które mogłoby się nie uruchomić.

  • Cztery typy limitu, status = najgorsza oś
  • Tolerancja nie przesuwa następnego terminu
  • Prognoza z ostrożniejszego z dwóch okien nalotu
  • LLP i AD: tolerancja zero, bez wyjątków

Skąd biorą się liczby

Jeden łańcuch: podpis → licznik → resurs

Podpisanie wpisu PDT księguje przyrosty na licznikach statku i zamontowanych komponentów. Punkty „due” zmieniają tylko cztery zdarzenia: rejestracja wykonania zadania, aktywacja nowej rewizji programu obsługi, zabudowa lub demontaż komponentu oraz korekta licznika. Wszystko dzieje się w jednej transakcji z podpisem — nie ma stanu „przeliczy się za chwilę”.

Silnik jest czystą funkcją i ma testy złote (znane przypadki z realnych programów obsługi) oraz testy własnościowe, które losowo generują historie wykonań i sprawdzają niezmienniki — na przykład że przeliczenie przyrostowe daje dokładnie ten sam wynik co przeliczenie całości od zera.

Resursy · due-lista floty 2 statki · 5 zadań
Zadanie Statek Limit Termin Pozostało Postęp Status
100H-PLAT Przegląd 100 h płatowca SP-GDM Nalot (block) przy 450:00 37:42 FH wkrótce
ARC Przegląd zdatności do lotu (ARC) SP-GDM Kalendarz 14.09.2026 50 dni wkrótce
LLP-MR Łopata wirnika nośnego — resurs SP-GDM Nalot (block) przy 2200:00 1787:42 FH dopuszczony
AD-SILNIK Dyrektywa zdatności — zespół napędowy SP-DGM Kalendarz 02.08.2026 7 dni w tolerancji
12M-WYP Przegląd 12-miesięczny wyposażenia SP-DGM — — — brak danych
Makieta układu ekranu aplikacji — odwzorowanie realnego widoku, nie zrzut ekranu.

Limity

Cztery typy limitu i jeden status

Zadanie ma tyle osi, ile realnie wynika z programu obsługi. Osie liczy się osobno, a statusem zadania jest ta najgorsza — nie średnia i nie pierwsza z listy.

Typ Oś Pozostało Przykład
Kalendarzowy Miesiące albo dni Termin minus dzisiejsza data Przegląd 12-miesięczny, ważność ARC
Godzinowy Nalot w minutach Termin minus bieżący nalot Przegląd 100 h, wymiana oleju
Cyklowy Lądowania albo uruchomienia Termin minus bieżąca liczba cykli Element z resursem cyklowym
Mieszany Dwie albo trzy osie naraz Osobno na każdej osi; status = najgorsza, termin = najwcześniejszy „100 h albo 12 miesięcy — co nastąpi wcześniej”

  • Godziny w minutach całkowitych

    Cały silnik liczy na liczbach całkowitych: minuty i cykle. Godziny dziesiętne to najprostszy sposób na to, żeby po roku brakowało kilkunastu minut.

  • Reguła „co nastąpi wcześniej” i „co nastąpi później”

    Obie występują w realnych programach obsługi, więc obie są w silniku. Zadanie zna swoją regułę, a nie zgaduje jej z układu limitów.

  • Koniec miesiąca

    Zadania kalendarzowe mogą używać konwencji końca miesiąca — przegląd wykonany 3 marca ma termin na 31 marca następnego roku, tak jak w programie obsługi.

Tolerancje

Tolerancja, która nie przesuwa harmonogramu

Wykorzystanie tolerancji nie może przesuwać całego cyklu do przodu — inaczej po kilku latach przegląd „100 h” wypada realnie co 115 godzin. Dlatego kotwicą kolejnego terminu jest wcześniejsze z dwóch: faktyczne wykonanie albo termin planowany. Wykonanie przed terminem liczy się od wykonania, wykonanie w oknie tolerancji — od terminu planowanego.

Żeby to działało niezależnie od kolejności przeliczeń, termin planowany jest zapisywany jako migawka w momencie rejestracji wykonania. Wynik nie zależy od tego, kiedy i w jakiej kolejności silnik liczył cokolwiek później — dwa razy ta sama historia daje ten sam termin.

Tryb kumulatywny (tolerancja doliczana do następnego terminu) istnieje, ale włącza się go świadomie na zadaniu, gdy tak stanowi program obsługi. Domyślnie tolerancja jest niekumulatywna.

Zadania bez tolerancji

Części o ograniczonej żywotności (LLP) i zadania wynikające z dyrektyw zdatności mają tolerancję zero — wymusza to sama baza danych. Przekroczenie oznacza od razu status „przekroczone”, bez fazy przejściowej.

Statusy

Pięć stanów, które widzi CAMO

Statusy są takie same na due-liście floty, na karcie statku i na ekranie pilota przed lotem. Jeden słownik, żeby nikt nie tłumaczył sobie kolorów po swojemu.

  1. Dopuszczony

    Zapas większy niż próg ostrzegania ustawiony na zadaniu.

  2. Wkrótce

    Zapas w progu ostrzegania — czas planować wizytę, jeszcze bez presji.

  3. W tolerancji

    Termin planowany minął, zapas mieści się w oknie tolerancji zadania.

  4. Przekroczony

    Poza tolerancją. Zadanie przekroczone oznacza, że statek nie lata do czasu wykonania.

  5. Brak danych

    Zadanie bez historii wykonania i bez przyjętej polityki kotwiczenia. System pokazuje brak danych zamiast wymyślać termin — to pozycja do uzupełnienia przez CAMO, a nie zielony haczyk.

Progi ostrzegania są własnością zadania (osobno dla dni, godzin i cykli), więc przegląd 100 h i ważność ARC nie muszą zapalać się w tym samym momencie.

Prognoza

Kiedy statek stanie

Prognoza terminu bierze tempo wykorzystania z dwóch okien: 30 i 90 dni, i wybiera większe z nich. Okno 90-dniowe wygładza sezon, 30-dniowe łapie statek, który właśnie wrócił do intensywnego latania. Wybór większego tempa jest świadomy: prognoza ma wypadać wcześniej niż rzeczywistość, nigdy później.

Statek, który stoi, nie dostaje prognozy godzinowej. Zamiast daty „za cztery tysiące dni” pojawia się znacznik braku wykorzystania i termin z osi kalendarzowej — jedynej, która biegnie także w hangarze. Dla nowego statku bez historii podstawą jest deklarowane roczne wykorzystanie, wyraźnie oznaczone jako szacunek.

Horyzont dłuższy niż dwa lata prezentujemy jako „ponad dwa lata”, a nie jako konkretną datę. Precyzja, której nie ma w danych, w planowaniu obsługi szkodzi bardziej niż jej brak.

Zależności

Zadania, które resetują inne zadania

W programach obsługi przegląd większy zwykle zawiera mniejszy: wykonanie 100 h zeruje 50 h. Silnik obsługuje takie pary, ale wyłącznie wtedy, gdy krawędź jest jawnie zapisana w programie obsługi. Jeżeli 100 h ma resetować i 50 h, i 25 h — obie zależności muszą być wpisane. Brak przechodniości jest decyzją: nikt nie odkrywa po fakcie, że coś wyzerowało się „samo”.

Zależność działa w jedną stronę. Wykonanie zadania podrzędnego nigdy nie resetuje nadrzędnego — wynika to z konstrukcji zapisu, nie z reguły, którą trzeba pamiętać.

Program obsługi

Co się dzieje przy rewizji AMP

Zadania łączą się między rewizjami po kodzie, więc historia wykonań nie ginie przy zmianie programu. Zmieniony interwał liczy się od tej samej kotwicy, a zadanie usunięte znika z due-listy bez kasowania historii.

Zadanie nowe dostaje jawną politykę pierwszego terminu: od produkcji statku (domyślna, najostrożniejsza), od daty wejścia rewizji albo z wykonania bazowego wpisanego ręcznie przez CAMO — na przykład na podstawie dokumentacji poprzedniego właściciela.

Gdyby rewizja uczyniła zadanie zaległym wstecz, statek nie zostaje uziemiony automatycznie. Pozycja trafia do raportu pomostowego i czeka na decyzję CAMO — rewizja programu to praca biurowa, nie zdarzenie operacyjne.

Komponenty

Komponenty i historia zabudowy

Silnik, przekładnia, śmigło, łopaty, elementy z resursem — każdy ma własne liczniki i własne zadania.

  • Licznik komponentu liczy się sam

    Stan komponentu to jego stan w chwili zabudowy plus przyrost płatowca od tego momentu. Nie ma drugiego licznika do ręcznego pilnowania.

  • Przeniesienie zabiera osprzęt

    Przeniesienie silnika na inny statek zabiera ze sobą całe poddrzewo zabudowanego osprzętu, a przy demontażu zapisywany jest stan liczników.

  • Historia jest nieusuwalna

    Zapisy zabudowy i demontażu wyłącznie się dopisuje. To one są dowodem przy przeglądzie zdatności i przy sprzedaży statku.

  • LLP bez tolerancji

    Część o ograniczonej żywotności ma twardy limit — silnik nie zna dla niej okna przekroczenia.

Dokumenty

ARC, CEN, polisa, AFM

Dokumenty statku mają terminy ważności i wchodzą do tej samej logiki, co zadania obsługowe: widać je na karcie statku, na due-liście i w paczce dla urzędu. Alert e-mail wychodzi na 60 i na 30 dni przed terminem, a potem po jego przekroczeniu.

Dokumentu nie usuwa się — wycofanie z obiegu polega na archiwizacji. Stary ARC zostaje widoczny w historii, bo przy przeglądzie zdatności to on jest dowodem ciągłości.

Alerty

Co przychodzi e-mailem

Alerty są dobowe i zdeduplikowane — ten sam powód nie przychodzi codziennie od nowa. Skrzynka, która krzyczy, przestaje być czytana.

  • Zadanie zbliżające się do terminu: zapas poniżej progu godzinowego albo kalendarzowego.
  • Zadanie w tolerancji i zadanie przekroczone — osobno, bo to dwie różne decyzje.
  • ARC i CEN: 60 dni, 30 dni i po terminie.
  • Kwalifikacje załogi i usterki odroczone zbliżające się do terminu usunięcia.

FAQ

Najczęstsze pytania

Skąd system wie, ile zostało do przeglądu, skoro nikt nic nie wpisuje?

Bo zapas to nie zapisana liczba, tylko wynik odejmowania: termin zadania minus bieżący stan licznika albo dzisiejsza data. Termin bierze się z ostatniego wykonania i interwału z programu obsługi, a licznik rośnie przy podpisie wpisu PDT. Nikt nie musi „odświeżać” due-listy, bo nie ma czego odświeżać — liczba powstaje w momencie, w którym na nią patrzysz.

Co z zadaniem, które ma limit godzinowy i kalendarzowy naraz?

Obie osie są liczone niezależnie. Statusem zadania jest gorsza z nich, a terminem — wcześniejszy z terminów. Dzięki temu statek intensywnie latający wpadnie w oś godzinową, a stojący w kalendarzową, i w obu przypadkach zobaczysz właściwy powód. Na due-liście widać, która oś decyduje.

Czy da się wprowadzić program obsługi, którego nie ma w żadnym katalogu?

Tak — zadania wprowadza się z limitami, tolerancjami, progami ostrzegania i regułą „co nastąpi wcześniej / później”, więc program obsługi operatora nie musi pasować do żadnego szablonu. Przy starcie zwykle robi się to bilansem otwarcia z trzech plików CSV (liczniki, zadania, ostatnie wykonania), z wersją próbną bez zapisu i zatwierdzeniem pod podpisem mechanika.

Czy system sam wystawi CRS po wykonaniu zadania?

Nie. Poświadczenie obsługi powstaje poza systemem, a przy rejestracji wykonania wpisuje się jego numer, datę prac, stan liczników na moment wykonania i osobę wykonującą; skan trafia do dokumentacji statku. Zlecenia obsługowe i wystawianie CRS to zakres kolejnej fazy — dopóki go nie ma, piszemy o tym wprost.

Dalej

Najbliższe tematy — na stronie i w bazie wiedzy.

Na stronie

  • Elektroniczny PDT

    Wpis per lot, podpis elektroniczny, niemutowalność i praca bez zasięgu.

  • Biuletyny i dyrektywy

    Zasysanie SB, SL i dyrektyw AD, przegląd i odhaczanie, ścieżka ręczna.

  • Dla kogo

    Aeroklub, ATO/DTO, operator śmigłowcowy, właściciel i CAMO — dzień pracy każdego z nich.

W bazie wiedzy

Zobacz CamoBook na swojej flocie

Trzydzieści minut na żywo: wpis PDT z podpisem, due-lista Twojego typu statku i paczka dla urzędu. Bez prezentacji handlowej — rozmawiamy o Twoim programie obsługi.

Umów demo

albo napisz na pawel@mamcarz.com