WSP.54.81631°N 21.36988°E
HEX0x1d97ba::881f
STATUS SYSTEMUOPTYMALNY

Baza wiedzy

Logika i stany systemu

O systemie JULIA

Źródło: dokumentacja Julia AI v1.0 oraz JULIA SYSTEM ARCHITECTURE (PL) — stany, wątki, potoki danych lotniczych, kontekst AI i moduły szkoleniowe.

Architektura wielowątkowości (concurrency)Rozwiń / zwiń

Celem jest płynność symulatora (np. 60 FPS) i brak zamrażania interfejsu. Julia stosuje wielowątkowość (nie „wszystko w jednej pętli GUI”).

Wątki (model z dokumentacji)

  1. Wątek główny (UI) — wyłącznie mainloop() CustomTkinter, tooltipy; bez ciężkich obliczeń.
  2. Wątek SimConnect (Data Thread) — pętla odczytu telemetrii; w jednym z opisów odświeżanie co 500 ms (pozycja, paliwo, pogoda powiązana z symulatorem).
  3. Wątek Audio / AI (Interaction Thread) — tworzony przy PTT: nagrywanie → Whisper → Gemini → odpowiedź; TTS w osobnych wątkach (mow), aby nie blokować UI.

SimConnect — zakres danych

Python-SimConnect łączy kod z jądrem MSFS. W dokumentacji: odczyt ponad 1000 parametrów (telemetria silnika, sterów, GPS, systemy elektryczne itd.) — podstawa decyzji typu konfiguracja podwozia, ostrzeżenia termiczne silnika itp.

Wątek SimConnect używa try/except — przy utracie połączenia z MSFS nie blokuje reszty programu; przejście w oczekiwanie na re-inicjalizację.

Race conditions i PTT

  • Globalna flaga PTT_ACTIVE działa jak semafor — zapobiega nakładaniu się nagrywania i równoległym procesom mowy.
  • Jeśli pilot aktywuje PTT, gdy Julia mówi — stop_julia_mowy i priorytet człowieka.

Wątek inicjatywy

julia_inicjuje_kontakt — praca w tle; decyzja, kiedy asystent sam zabiera głos (np. powitanie po starcie).

Potok PTT (krok po kroku — architektura PL)Rozwiń / zwiń
  1. Aktywacja PTT (klawiatura / kontroler).
  2. Nagranie wypowiedzi do pliku wejściowego.
  3. Zwolnienie PTT → start rozpoznawania.
  4. Whisper → tekst → klasyfikacja intencji.
  5. Dobór danych: METAR / kontekst trasy + plan / moduł obliczeniowy / tryb nauki.
  6. SimBrief w tle — DEP/ARR, spójność z OFP.
  7. METAR z CheckWX — raport do panelu ZULU + „twarde fakty” dla modelu.
  8. Gemini — odpowiedź w języku i stylu z ustawień + dołączony kontekst operacyjny.
  9. TTS — wypowiedź z kontrolą kolejności komunikatów.
  10. Aktualizacja GUI — panel ZULU, log, kafelki trasy (gdy dotyczy).
Interpretacja intencji (przykłady)Rozwiń / zwiń
  • pogoda → logika METAR,
  • nawigacja → kontekst trasy i pozycji,
  • wyliczenia → moduł kalkulacyjny,
  • procedury → tryb wsparcia nauki (Teacher Mode).
METAR jako źródło faktówRozwiń / zwiń
  • CheckWX — profesjonalny dostawca METAR po kodzie ICAO.
  • Panel ZULUsurowy raport + czytelne wyróżnienia istotnych fragmentów; pilot nie polega wyłącznie na jednym zdaniu z LLM.

System kolorowania depeszy — nanies_kolorowanie_depeszy

Funkcja wykorzystuje wyrażenia regularne do identyfikacji segmentów:

  • Zielony — warunki VFR / stabilne parametry,
  • Czerwony — niebezpieczne zjawiska (TS — burze, FG — mgła itd.),
  • Niebieski — m.in. QNH / temperatura.

Algorytm priorytetyzacji zagrożeń

Wykrycie słów kluczowych (TS, FG, WS — windshear) → podniesienie priorytetu komunikatu głosowego przed trudnymi warunkami na lotnisku docelowym.

QNH / altimeter

Automatyczne rozpoznanie formatu ciśnienia (hPa vs InHg) w oparciu o kontekst ICAO i konwersja tak, aby instrukcja ustawienia wysokościomierza była spójna z SOP (w połączeniu z wgranymi dokumentami).

Dobór lotniska dla METAR bez podania koduRozwiń / zwiń
  1. Jeśli pilot poda kod ICAO (lub jednoznaczne wskazanie) — użycie tego wskazania.
  2. Jeśli nie — wybór kontekstowy:
    • porównanie DEP/ARR z SimBrief,
    • pozycja samolotu z SimConnect,
    • wybór lotniska najbardziej prawdopodobnego operacyjnie dla bieżącej fazy lotu.

System nie traktuje przypadkowych czteroliterowych ciągów jako kodów lotnisk — priorytet ma kontekst planu i pozycji.

SimBrief i OFP (Operational Flight Plan)Rozwiń / zwiń
  • Pobranie XML/JSON z SimBrief; parsowanie do struktur wewnętrznych.
  • Wyciąganie m.in.: numer lotu, lotniska zapasowe, poziom przelotowy.
  • Mapowanie jednostek (LBS vs KG) zależnie od profilu samolotu.
Silnik danych lotniczych — paliwo i masaRozwiń / zwiń

Analiza paliwowa (fuel monitoring)

  • Parametr FUEL TOTAL QUANTITY (SimConnect) vs plan SimBrief.
  • Jeśli tempo zużycia odbiega od planu o więcej niż 5%alert techniczny (wartość z dokumentacji).

Weryfikacja ładunku

  • Porównanie ZFW (Zero Fuel Weight) z planu z rzeczywistym załadowaniem w symulatorze — podstawa dla spójności wyliczeń V-speeds przekazywanych przez asystenta.
Dynamiczne promptowanie (context injection)Rozwiń / zwiń

Zanim zapytanie trafi do Gemini, budowany jest wielowarstwowy kontekst (State Snapshot):

  1. Warstwa statyczna — plan lotu (skąd, dokąd, alternatywy, callsign).
  2. Warstwa dynamiczna — GPS, wysokość, prędkość (IAS/GS), faza lotu (climb/cruise/descent).
  3. Warstwa środowiskowaMETAR dla odlotu, docelowego i zapasowych.

Efekt: pytania w stylu „czy damy radę wylądować?” są rozpatrywane w kontekście wiatru bocznego i limitów typu — z dokumentacji przykład o 25 kt crosswind vs limit 20 kt dla typu statku.

Moduł obliczeń operacyjnych (performance engine)Rozwiń / zwiń

Mass & Balance

  • Analiza CG, payload, paliwa z SimConnect.
  • Przekroczenie MTOW / MLW względem specyfikacji → ostrzeżenie głosowe.
  • Raport Weight & Balance na żądanie głosowe.

Kalkulatory

  • V-speeds (V1, VR, V2) z masą, temperaturą, nawierzchnią pasa (z METAR).
  • Top of Descent (TOD) / profil zniżania — rekomendacje w stylu operacyjnym (przykład z dokumentacji: rekomendacja zniżania z dystansem i profilem ).
  • Fuel to Destination, Reserve at Destination z uwzględnieniem wiatru z systemów samolotu.

Cross-check (spójność danych)

  • Porównanie planu (SimBrief/PDF) ze stanem w symulatorze.
  • Niespójność QNH na wysokościomierzu vs METAR → możliwa sugestia korekty.
  • Pas startowy krótszy niż wymagany przy aktualnej masie (z Mass & Balance) → błąd konfiguracji.

Obliczenia „w locie” (on-the-fly)

  • Pytanie głosowe z automatyczną ekstrakcją SimConnect + SimBrief — redukcja błędów ręcznego wpisywania (fat-finger).
VUI — optymalizacja latencjiRozwiń / zwiń
  • Nagrywanie chunkowe (pyaudio).
  • Multi-TTS / SAPI5 — wybór profilu o niższym obciążeniu CPU, by uniknąć przycięć przy obciążonym symulatorze.
NOTAM — filtracja i alertowanie (wizja produktowa)Rozwiń / zwiń

Dokumentacja opisuje moduł interpretacji NOTAM dla lotnisk operacyjnych:

  • Dekodyzacja surowych bloków; wyłuskanie przeszkód, aktywności w przestrzeni, zamknięć dróg kołowania, NAVAID U/S.
  • Just-in-time — briefing przed kołowaniem; dynamiczne ostrzeżenia przy dolocie; język naturalny zamiast samych skrótów (przykład: „oświetlenie przeszkody niesprawne na maszcie przy ścieżce podejścia”).
  • Wartość edukacyjna — priorytetyzacja: co krytyczne, co informacyjne; wsparcie świadomości sytuacyjnej (SA).
Tryby szkoleniowe — interwały i quizRozwiń / zwiń

Tryb przekazywania wiedzy (passive)

  • Suwak częstotliwości — np. niski: fakt co 15–20 min; wysoki: intensywne wyjaśnianie fazy lotu.
  • Zakres: m.in. 11 działów teoretycznych PPL(A)/LAPL (prawo, meteorologia, nawigacja, procedury, zasady lotu itd. — wg opisu PDF).

Tryb odpytywania (quiz / active)

  • Interwał pytań ustawialny (np. co 5 minut lub intensywny tryb).
  • Pytanie głosowe → odpowiedź głosowa ucznia → analiza przez AI; błąd → natychmiastowa korekta + wpis do logów „czarnej skrzynki” na debriefing z instruktorem.

Cel dydaktyczny

Nauka pod obciążeniem — podzielność uwagi jak przy egzaminie / locie; redukcja nudy na długich przelotach.

METAR — metoda „Dual-View” (edukacja)Rozwiń / zwiń
  1. Raw — depesza w oryginalnym kodzie (jak na profesjonalnym czytniku).
  2. Decoded — rozkodowanie segmentów pod spodem.
  3. Efekt — skojarzenie skrótów (BKN, FEW…) ze znaczeniem; wsparcie TEM dzięki kolorom z sekcji kolorowania.
„Black Box” i debriefing (wizja operacyjna)Rozwiń / zwiń
  • Log chronologiczny — korelacja telemetrii, decyzji, komunikacji (w planach integracja z rozpoznawaniem intencji ATC, np. SayIntentions).
  • Fuel Management Audit — porównanie tankowania z planem SimBrief.
  • Energy Management — punkty utraty parametrów (SimConnect) dla analizy LOC-I / profilu energii.
  • Firebase — przechowywanie logów dla krzywej uczenia się szkoły.
Kafelki trasy (logika wizualna)Rozwiń / zwiń
  • Zielony — punkt najbliższy operacyjnie,
  • Błękitny — kolejny istotny,
  • Pomarańczowy — dalsze,
  • TOC/TOD — osobne wyróżnienie profilu pionowego.

Wyróżnienia zmieniają się dynamicznie w czasie lotu w oparciu o pozycję.

Stany wysokiego poziomu (abstrakcja operacyjna)Rozwiń / zwiń

Dla audytu można opisać pracę jako przejścia między:

  • INIT — start, walidacja konfiguracji, HWID, połączenia,
  • ONLINE — SimConnect aktywny / w pętli odpytywania, UI responsywne,
  • DEGRADED — utrata części usług (np. chmura LLM), lokalny STT/TTS nadal dostępne w modelu hybrydowym,
  • RECOVERY — procedura awaryjna przy błędzie audio/sieci (patrz Bezpieczeństwo).
Idempotencja i duplikatyRozwiń / zwiń

W warstwach sieciowych i kolejkach zdarzeń handlery powinny tolerować powtórzenia żądań (retry HTTP, ponowne pobranie METAR) — klucze naturalne: identyfikator żądania, znacznik czasu, seq przy zapisach do chmury.

Logika a warstwa UI (Hangar)Rozwiń / zwiń

Pilot Hangar prezentuje stan z Firestore / portalu — może być opóźniony względem aplikacji desktopowej Julii; „prawda” operacyjna w locie leży w procesie Julii + MSFS, nie w przeglądarce.

© 2026 Julia System. Wszelkie prawa zastrzeżone. Zaprojektowane dla wszystkich pilotów.