Журнал змін

Усі помітні зміни в Kshana задокументовано тут.

Формат ґрунтується на Keep a Changelog, а цей проєкт дотримується Semantic Versioning. Поки проєкт має версію до 1.0, публічна схема сценаріїв і результатів може змінюватися; зміни, що порушують сумісність, виділяються явно.

Не випущено#

[0.40.0] - 2026-10-29#

0,40 додає ланцюг місії класу Artemis і його місячний сегмент, позначку доказів на кожній величині та таблиці, що їх записує прогін, прийом і підгонку виміряних годинників, перевірку подань партнерів з даними, оцінену область випромінювача за повідомленнями ADS-B або AIS, повторну кампанію бенчмарка 0,40, а також командний рядок, звіти й Studio сімнадцятьма мовами поряд з англійською (машинні документи лишаються англійською). Матриця верифікації зростає з 388 до 401 рядків: 176 VALIDATED (без змін), 221 MODELLED (було 208) і 4 PARTNER. Жоден рядок не підвищено до VALIDATED. Типи сценаріїв зростають з 87 до 92. Кожен поріг, якого не досягло попередньо зареєстроване порівняння, зазначено нижче, і він лишається закріпленим; жодного не послаблено. Консультативне застереження не змінилося: Kshana — це консультативне програмне забезпечення, не навігаційне обладнання із затвердженням типу і не сертифікація; відповідальність лишається на операторі.

Відомі обмеження#

• Прогони іншими мовами тривають приблизно вдвічі довше, бо сценарій виконується двічі (один раз англійською для машинних файлів, один раз обраною мовою для людини).
• Деякі речення Studio складаються з фрагментів і можуть не мати артиклів у мовах із граматичним родом.
• Переклади є машинними, і жоден носій мови їх не перевіряв; еталоном є англійська версія.

Додано#

• Сімнадцять мов поряд з англійською для людського тексту рушія, сайту та Studio: nl, pl, pt-BR, pt-PT, fi, sv, da, nb, cs, uk, ru, de, fr, es, et, ja, zh-Hans (--lang, KSHANA_LANG, змінні локалі; lang у викликах бібліотеки, Python, WebAssembly і MCP). Повідомлення й помилки командного рядка, підсумки прогонів, текст діаграм, report.html, описи типів і консультативні застереження перекладено; машинні документи (JSON, CSV, коди помилок, матриця верифікації) лишаються англійськими, а прогін іншою мовою виконує сценарій один раз англійською для машинних файлів і один раз обраною мовою для людини (docs/i18n.md). Переклади є машинними, не перевіреними носіями мови; еталоном є англійська версія; REVIEW.md кожної мови перелічує, що рецензент має перевірити першим, а сторінки сайту несуть застереження про це. Слова вердиктів, рівні доказів і обсяг консультативного застереження («не із затвердженням типу», «не сертифікація», «відповідальність лишається на операторі») збережено в кожній мові.
• kshana interference-map locate: оцінена область випромінювача за повідомленнями ADS-B або AIS. Апостеріорний розподіл того, де може перебувати джерело спотворених повідомлень про положення (радіолінія прямої видимості за радіусом Землі 4/3, висота антени випромінювача та потужність маргіналізовані, уражені літаки тягнуть, а неуражені літаки з прямою видимістю штовхають назад), записаний як області на рівнях 50, 90 і 95%, центроїд з еліпсом невизначеності (ніколи не окрема точка), сесії в часі (початок, кінець, тривалість, уражена площа, різні літаки вище мінімуму для публікації), добовий профіль і години на добу, з необов'язковим злиттям фікса TDOA з geolocation. Вихідні дані: GeoJSON, підсумок JSON, CSV сесій і рисунок SVG, кожен з ліцензією, зазначенням авторства, ідентифікатором методу, припущеннями, обмеженнями та власною позначкою доказів. Бібліотека interference_map::api::emitter_regions_from_*, Python і WebAssembly interference_emitter_regions. MODELLED (рядок реєстру VM-bc70cb57; тепер матриця має 401 рядків, 176 VALIDATED, 221 MODELLED, 4 PARTNER); відкалібровано лише на синтетичних даних, а порівняння з місцями передавачів Jammertest 2025 попередньо зареєстровано й виконано один раз: ADS-B та AIS обидва NOT ASSESSABLE (замало запланованих сесій у відкритих даних), тож рядок лишається MODELLED (docs/emitter-region/RESULTS.md). Нейтральне формулювання, лише сукупно; публікація областей випромінювачів у публічній обсерваторії лишається вимкненою. Синтетичний приклад є в examples/emitter-region/ (docs/INTERFERENCE-MAP.md).
• Виміряні журнали годинників. src/clock_log.rs читає виміряний журнал годинника в один ряд фази: вісім форматів (RINEX clock, TimeLab, TICC, linuxptp ptp4l, phc2sys і ts2phc, відстеження й статистика chrony), кожен є задокументованою підмножиною; усе поза нею відхиляється з помилкою, що називає знайдене. Його використовують telecom-timing ([series.clock_log]) і тип clock ([clock_log], що додає блок measured із SHA-256 журналу та перекритими ADEV, TDEV і MTIE), із вбудованим сценарієм clock-measured-log (docs/CLOCK-LOG-FORMATS.md). Порівняно з allantools на справжніх публічних даних за попередньо зареєстрованими порогами: перший прогін не досяг B1 (5 з 11 випадків, усі позначки часу TICC зберігалися як f64), B2, B3 (7 з 24 випадків) і B4 (версію заголовка не перевірено); після виправлень B1, B3 і B4 досягнуто, а B2 досягнуто, крім однієї пари MTIE, яка закріплена й не є вадою рушія (allantools 2024,6 вилучає середню частоту перед інтегруванням; проти його MTIE в режимі фази рушій збігається з точністю 1e-10). Рядок лишається MODELLED (tests/fixtures/clock_log_real/RESULTS.md).
• Holdover, керований підігнаним виміряним рядом: [clock_fit] типу clock підганяє шум виміряного ряду й керує holdover за ним (src/clock_fit.rs, вбудований сценарій clock-fitted-log). Попередньо зареєстроване порівняння: F1(b), F3 і F4 досягнуто; F1(a) (відновлення зареєстрованого FM випадкового блукання) NOT MET на записах C3 (неідентифіковне за побудовою) і на двох із трьох записів C4 (FM випадкового блукання поглинене flicker FM і дрейфом); F2 (ідентифікація шуму проти allantools) досягнуто на одинадцяти з дванадцяти записів і D3 та NOT MET на D2 так, як зареєстровано (досягнуто за рівних умов). Усі невиконані пороги закріплено (tests/clock_fit_known_noise.rs); блок fitted і holdover, що ним керується, лишаються MODELLED (tests/fixtures/clock_fit/RESULTS.md).
• Повторна кампанія бенчмарка 0,40, попередньо зареєстрована із затвердженням власника до будь-якого прогону: A3 (EXPLORATORY, AUC за бутстрепом із кластеризацією за теками для agc_k_sigma, квантиль 2,5 % — 0,8502 проти 0,80), D3 (EXPLORATORY, три з п'яти детекторів перевищують розрив оптимізму 0,05 за масштабу 0,25), R3 (AUC 1,0) і R4 (P_fa 0,0, P_d 1,0): усі MET, усі MODELLED. A2, D1 і R1 не зачеплено, і вони лишаються NOT MET; ніщо тут їх не закриває (xval/bench/RESULTS-0.40.md, Bench).
• kshana partner check <submission.toml>: перевіряє формат і метадані подання партнера з даними (kshana.partner-submission/1: пристрій, файл даних і SHA-256, як їх отримано, рядки MODELLED, відносно яких вони пропонуються, ліцензія, заяви) і читає дані власними читачами журналів годинників чи IMU рушія. Він нічого не оцінює й нічого не перевіряє на відповідність незалежному еталону. Синтетичний приклад є в examples/partner-submission/.
• docs/PARTNER-DATA.md: які рядки реєстру (ledger) MODELLED могли б підвищити виміряні дані, які формати приймаються, як подання перевіряється, оцінюється за попередньо зареєстрованим порогом і зараховується, і що означають PARTNER та VALIDATED; чернетка листа-запрошення для власника в docs/drafts/PARTNER-OUTREACH.md (нічого не надсилається).
• Другі кампанії для невиконаних порогів gnss-ssv і lunar-infrastructure, проведені як попередньо зареєстровано (xval/gnss-ssv/PREREGISTRATION-v2.md, xval/lunar-infra/PREREGISTRATION-v2.md; затверджено до будь-якого прогону). Кожен первісний промах лишається NOT MET і закріпленим. gnss-ssv: контроль відтворює прогін 1 комірка в комірку; п'ять абляцій за одним показанням повертають 2 з 78 невиконаних комірок у межі допуску (EXPLORATORY, без порога); новий поріг S7b (форма передавання зі спадом і підлогою, підігнана на панелях Classic IIR) NOT MET на панелях IIR-M за 3,83–3,95 дБ проти 3 дБ; кампанія з утримуваним опублікованим прийомом не проводилася (джерело не закріплено) (xval/gnss-ssv/RESULTS-v2.md). lunar-infrastructure: нові пороги C3a, C3b (межа виявлення близько 3e-9 м/с2), Q3a, Q3b (точна нормальна CDF усуває різницю 1.7e-6) і G3'' досягнуто як власні пороги, а G3' з ілюстративними апріорними значеннями досягнуто й позначено EXPLORATORY (xval/lunar-infra/RESULTS-v2.md). Усе лишається MODELLED. Нові публічні елементи: kshana::lambda::{erfc_accurate, normal_cdf_accurate, bootstrap_success_rate_accurate}.
• Позначка доказів на кожній величині та таблиці, що їх записує прогін. JSON результату має ключ evidence, SVG діаграми — елемент метаданих і рядок під графіком, а таблиця CSV — рядки коментарів # evidence:: рівень (VALIDATED, MODELLED або PARTNER, найслабший з рядків) та ідентифікатори рядків матриці верифікації, на яких ґрунтується прогін. Рядки та стани прочитано з матриці, а не вписано вручну; ідентифікатори стабільні (VM- і вісім шістнадцяткових цифр, новий стовпець ID у docs/VERIFICATION-MATRIX.md, заморожений список у tests/fixtures/evidence_ids.txt). Також для receiver-trust, jammertest score, iq acquire/sweep/track/monitor, звіту про експозицію маршруту та, у підписаному config.json, для кожного пакета доказів (config_version 1,1; kshana evidence verify повідомляє рівень; пакети, створені до 0,40, перевіряються без змін). tests/evidence_labels_doc_sync.rs завершується невдачею, якщо величина не має позначки, позначка розходиться з матрицею або новий записувач файлів не позначений і не внесений у список із причиною. Вихідні дані, що не несуть жодної, перелічено в docs/SURFACES.md. Три демонстраційні діаграми README перерендерено з позначкою (її зняття повертає старі байти; docs/revisions/STUDIO15-evidence-label-0.40.md). Жодне твердження не змінилося.
• Тип сценарію mission-thread (scenarios/mission-thread-artemis-class.toml, docs/MISSION-THREAD.md): бюджет похибок навігації та часу ланцюга фаз від запуску до входу в атмосферу, кожне число MODELLED, а кожен вхід заданий. Вісім типів фаз: launch-ascent, leo-rendezvous (відносна коваріація Clohessy-Wiltshire за ділянками датчиків, вікно стикування), tli-and-cruise (пропагація Ковелла з матрицею переходу стану за скінченними різницями, похибка імпульсу, оновлення gnss-ssv і наземного відстеження, Місяць із необов'язкового зрізу ядра DE440), entry (сигма кута нахилу траєкторії, ймовірність коридору, пікове уповільнення на краях коридору, область посадки) і чотири місячні типи. Правила передачі (carry, inflate, reacquire), перетворення систем відліку та шкал часу як власні рядки бюджету, необов'язкова накладка наземної мережі, що задає шкалу відстеження кожної фази, запас відносно заданих вимог і найслабша ланка. Приклад повторює послідовність публічної презентації концепції операцій NASA з ILLUSTRATIVE числами: наскрізний приклад класу Artemis на 11 фазах, земний і місячний сегменти. Цисмісячну пропагацію порівняно з публічною траєкторією Artemis I на дузі 72 год проти порога, зафіксованого в xval/mission-thread/PREREGISTRATION.md до прогону: NOT MET (45,3 км і 0,25 м/с проти 5 км і 0,05 м/с). Діагностика відносить промах до п'яти малих імпульсних подій в еталоні; між ними силова модель відтворює погодинні стани з медіаною 0,4 м. Рядок лишається MODELLED (xval/mission-thread/RESULTS.md).
• Місячний сегмент ланцюга місії класу Artemis: чотири типи сценаріїв, кожен також є типом фази інтерфейсу mission-thread (src/mission_thread/lunar/), і кожен MODELLED.
  • lunar-orbit-rendezvous: відносна навігація до стикування на 100 км круговій полярній орбіті або на еліптичній полярній 100 км на 3000 км (scenarios/lunar-orbit-rendezvous.toml, ...-elfo.toml). Пакетна оцінка Гаусса–Ньютона на дузі зливає абсолютний фікс на апарат з ілюстративного набору ретрансляторів класу LCNS, стійку похибку сигналу в просторі (спільну для обох апаратів і незалежну) та дальність міжлінії за місячною силовою моделлю крейта. Вона повідомляє відносне положення та швидкість в локальних осях цілі, доступність фіксів, середню нормалізовану квадратичну похибку оцінки проти її очікуваного значення, ціну ігнорування гравітаційних гармонік, моделі кінцевих відносних датчиків поряд з показником лише за сигналами та передану далі коваріацію 6x6.
  • lunar-descent: бюджет розсіювання посадки в південно-полярному місці (scenarios/lunar-descent.toml; lunar-descent-lola.toml читає цифрову модель LOLA з робочої копії): п'ятистанова інерційна модель похибок за віссю, фікс AFS (автономний або диференціальний, із залишком каналу корекції з lunar-differential-pnt), фікс за рельєфом (зіставлювач terrain-nav на його синтетичному рельєфі або межа Крамера–Рао зіставлення цифрової моделі LOLA) і місячний час через годинник апарата (lunar-time-offset). Він повідомляє 3-сигмовий еліпс посадки, кожну комбінацію допоміжних засобів і калібрування еліпса за Монте-Карло.
  • lunar-surface: доступність позиціонування та часу за місцем і порою року (scenarios/lunar-surface.toml; lunar-surface-terrain.toml додає прослідкований променями обрій LOLA): показник позиціонування для одного місця дорівнює показникові moonlight-service-volume до біта; зі сезоном змінюється видимість Землі та Сонця за аналітичними ефемеридами.
  • lunar-ascent: виведення на орбіту зустрічі та коваріація положення–швидкості, перенесена назад на орбіту (scenarios/lunar-ascent.toml), з розсіюванням при відсічці двигуна, повідомленим поряд.
  • docs/MISSION-THREAD-LUNAR.md; попередня реєстрація, її поправки та кожен результат, зокрема промахи, — у xval/mission-thread-lunar/.

Докази#

• Попередньо зареєстровано в xval/mission-thread-lunar/PREREGISTRATION.md до будь-якого прогону, із шістьма датованими поправками (кожну зроблено до отримання даних, крім поправки 6, що виправляє арифметичну помилку в кількості станів після отримання та до будь-якого результату A2; кожну поправку розкрито у файлі). Жодного порога не послаблено.
• A1 (пропагатор проти відновленої траєкторії LRO з JPL Horizons, 24 год): MET, максимальна 3-D різниця 33 м проти порога 500 м і радіальна RMS-різниця 2,4 м проти 60 м.
• A2 (той самий пропагатор проти NRHO CAPSTONE за один оберт тривалістю 6.5 доби): NOT MET, різниця кінцевого положення 136,8 км проти порога 25 км і різниця радіуса оскулюючого періапсиду 28,4 км проти 10 км. Рядок лишається MODELLED, а промах закріплено tests/mission_thread_lunar_oracles.rs.
• B1 (узгодженість оцінки зустрічі з власною моделлю) MET для четвертого проєкту оцінювача, середня NEES від 5,85 до 5,93 проти смуги [5,2, 6,8]; три попередні проєкти, розширений фільтр Калмана в трьох варіантах, її не досягли. П'ята зміна, зроблена після того, як виявилося, що поставлений сценарій на 2 год відправляє 4 з 50 випробувань у локальний мінімум (середня NEES 1e9), виконує підгонку Гаусса–Ньютона на дузі, що росте, із поділом кроку навпіл; B1 від неї не змінюється, а поставлені сценарії дають 6,51 і 6,33. Історію наведено в xval/mission-thread-lunar/RESULTS.md.
• Ніщо тут не є VALIDATED: рядки оракулів перевіряють спільний пропагатор, а не навігаційний фільтр, сигнал чи бюджет.

[0.39.0] - 2026-10-22#

Жодних нових можливостей: одне виправлення командного рядка, оновлення залежностей в інструментах перехресної перевірки та документація. Результати рушія не змінилися порівняно з 0.38.0.

Виправлено#

• Командний рядок тихо завершується зі статусом 141, коли його стандартний вивід закривається (kshana kinds | head), замість аварійного завершення з повідомленням «failed printing to stdout: Broken pipe». 141 — це 128 плюс SIGPIPE, статус, який оболонка повідомляє для yes | head. Обробляється лише закритий канал: переповнений диск або будь-яка інша помилка запису, як і раніше, повідомляє про себе, а живий потік, що пише в закритий сокет, і далі отримує свою помилку запису. tests/cli_closed_pipe.rs закриває читача до запуску програми, тому перший запис завершується помилкою в кожному прогоні.

Безпека#

Одне оновлення залежності в поставленій бібліотеці (перший запис), решта в інструментах перехресної перевірки (xval/).

• p256, p384 і p521 з 0,13 до 0,14 (разом з elliptic-curve 0.14.3, ecdsa 0.17.0 і crypto-bigint з 0.5.5 до 0.7.10; також пряма залежність crypto-bigint, тепер 0,7) усувають попередження RUSTSEC-2026-0387, мінливість часу виконання в crypto-bigint 0.5.5. Kshana використовує ці крейти лише для перевірки відкритих підписів (кореневий ключ Galileo OSNMA і позначки часу RFC 3161) і підписує лише в тестах одноразовими ключами, тому практична вразливість була нульовою; оновлення усуває попередження без запису про ігнорування. Файли блокування бібліотеки та MCP змінюються обидва; жоден результат перевірки не змінюється (тести векторів OSNMA і позначок часу проходять без змін).
• Мінімальна підтримувана версія Rust тепер 1,88 (її вимагає виправлення RUSTSEC-2026-0387).
• memmap2 з 0.9.10 до 0.9.11 (RUSTSEC-2026-0186) у блокуваннях перехресної перевірки ANISE (xval/anise-lunar-od, xval/anise-mars-od); блокування також повторно синхронізують залежність за шляхом kshana у самому репозиторії.
• pillow з 12.3.0 до 13.0.0 і certifi з 2026.7.22 до 2026.10.19 у закріпленнях середовища оракулів (xval/oracles/requirements.lock, requirements.frozen.txt): виправлені випуски для восьми попереджень безпеки pillow і одного попередження certifi.

Документація#

• docs/BENCH.md, README і цей файл перелічують кожен поріг kshana-bench, який NOT MET, як записано в xval/bench/RESULTS-v2.md: A2 (agc_k_sigma AUC 0,766 проти щонайменше 0,80 на тестовому розбитті), D1 (найбільша розбіжність 0,0301) і завдання (b) R1 (перенесено, не запущено повторно). Жодного порогу не послаблено.
• Прохід за повнотою README: зміст; види сценаріїв, розкладені за родинами, кожен зі сторінкою в docs/kinds/by-kind/ (опис і поля від рушія, входи та результати прикладного прогону, рядки реєстру й оракули, обмеження, про які говорить звіт прогону, і діаграма, яку записує рушій), контактний аркуш для кожної родини, усе індексовано в docs/KINDS.md; кожна команда в docs/COMMANDS.md; кожна поверхня, команда плагіна, навичка та сторінка Studio в docs/ALL-SURFACES.md; кожна область можливостей у docs/CAPABILITY-DOMAINS.md; вбудовані діаграми Mermaid (огляд системи, поверхні, внутрішній цикл, довіра до приймача, лабораторне коло, Studio, потік тестування та випуску, карта модулів, розповсюдження). Записано за допомогою tools/gen_kinds_index.py, tools/gen_readme_blocks.py і tools/gen_figures_038.py; перевірено tools/readme_audit.py; захищено tests/readme_completeness_doc_sync.rs, який також прив'язує опис і поля кожного запису до рушія.
• tools/render-diagram-chromium.sh: відтворює діаграму Mermaid у SVG і PNG на Linux та оновлює запис про відтворення.
• README: рисунки для космічних користувачів і Місяця використовували шляхи відносно docs/, тому не завантажувалися з README; одне посилання вказувало на ../../docs/JAMMERTEST.md.
• Вилучено два застарілі файли діаграм, скопійовані вручну (docs/assets/clock-ensemble-band.svg, sweep-clock-stability.svg), які жодна сторінка не використовувала і які більше не відповідали рушію; docs/KINDS.md містить поточні діаграми.

[0.38.0] - 2026-10-19#

Додано#

• ГНСС за межами орбітального угруповання (gnss-ssv). Новий вид сценарію для космічних апаратів над орбітами ГНСС, навколо них і за їхніми межами (docs/SSV.md): доступність одного й чотирьох сигналів, тривалість перерв, C/N0, DOP і зв'язки головної та бічних пелюсток для GPS, ГЛОНАСС, Galileo, BDS, QZSS і NavIC на оболонці або вздовж траєкторій LEO, MEO, GEO, HEO та місячного переходу; буклетні, параметричні або надані користувачем діаграми випромінювання; модель іоносфери, плазмосфери та атмосфери за променем біля лімба; конструкція приймача слабких сигналів; бортовий розширений фільтр Калмана ГНСС для HEO і місячного переходу; та відносна навігація формації. Порівняно з буклетом ICG Space Service Volume за попередньою реєстрацією, зафіксованою до прогону: константи мінімальної випромінюваної потужності та місячний поріг збігаються, інші пороги не виконано за попередньо зареєстрованого прочитання (майже всі через неузгоджений кут променя ГЛОНАСС у буклеті), а параметричний замінник бічних пелюсток не відтворює виміряні діаграми панелей GPS. Усе залишається MODELLED (xval/gnss-ssv/RESULTS.md).
• Місячна орбіта та поверхня як навігаційна й геодезична інфраструктура (lunar-infrastructure). Новий вид сценарію з п'ятьма дослідженнями, що вибираються через study (docs/LUNAR-INFRASTRUCTURE.md): узгодженість бортового визначення орбіти за Earth-GNSS на майже прямолінійній гало-орбіті з незалежним наземним визначенням за дальністю та швидкістю зміни дальності; спільна подвійно-різницева фаза несівної поверхневої станції та орбітального апарата із цілочисельною фіксацією LAMBDA; інформація Фішера семипараметричного місячного датума із зв'язками орбітальний апарат — поверхня та без них; міжтехнологічні зміщення GNSS, VLBI і лазерної дальнометрії щодо локального прив'язування; і чутливість до h2, k2, l2 та фізичної лібрації. MODELLED, із ILLUSTRATIVE входами: числові методи перевірено незалежними програмами numpy і scipy, і нічого не порівнюється з вимірюванням місячної величини. Пороги зафіксовано в xval/lunar-infra/PREREGISTRATION.md та двох розкритих поправках. Три NOT MET, і кожен закріплено тестом, що стверджує промах: C3 (введена похибка сили не виявляється із зареєстрованою заздалегідь частотою), Q3 (частота успіху за бутстрепом відрізняється від оракула numpy на 1.7e-6 проти порога 1e-9 через наближення нормального розподілу в LAMBDA) і трасувальна половина G3 (додавання сімейства вимірювань дальності не завжди знижує слід псевдооберненої матриці). Решту виконано (xval/lunar-infra/RESULTS.md).
• Шоста стаття в таблиці досліджень. «Цисмісячна навігація — це проблема спостережуваності: пороги довжини дуги, обумовленість граміана та важіль Доплера» (arXiv:2610,23871, eess.SP) показує, що геометричний чинник DOP (погіршення точності) не визначений для цисмісячного стеження лише за дальністю, і натомість використовує граміан спостережуваності на чотирьох планарних далеких ретроградних орбітах: лише за дальністю ранг 2 із 4 у знімку й потрібна дуга приблизно в 2,09 год, швидкість зміни дальності (Доплер) дає ранг 4 миттєво, а спільне оцінювання станції зі станами та годинниками супутників залишається з дефіцитом рангу на одиницю без зовнішньої інтерферометричної величини. Її числа відтворює вид cislunar-observability (kshana scenarios/cislunar-observability.toml); cislunar-arc-recovery перевіряє поріг незалежним оцінювачем. Це є на картці досліджень у README, у README для crates, npm і PyPI та в генераторі.
• Нейтральний арбітр, який можна виміряти. kshana jammertest import читає опублікований каталог випробувань NPRA Jammertest і план передавання як заплановану істину (ідентифікатори каталогу збережено), а kshana jammertest score оцінює журнал приймача відносно нього за кожним випробуванням (затримка виявлення, пропущені тривоги, хибні тривоги, час відновлення), за бажанням як підписаний пакет доказів (docs/JAMMERTEST.md). Пороги оцінювання попередньо зареєстровано до будь-якого оціненого прогону (xval/jammertest-score/). На наборі даних JammerTest 2024 (завантажений, ніколи не включений до репозиторію) попередньо зареєстроване правило мінімуму даних не виконано ні в першому прогоні, ні в редакції обробки даних, тому жоден поріг не можна оцінити й нічого не заявляється; обидва прогони записано й закріплено. MODELLED: розклад — це залоговані вікна набору даних, а не записані часи фактичного випромінювання. Набір SimulaMet NMEA 2025 не адаптовано (на його сторінці ліцензію не вказано).
• Власні прапорці приймача поряд із прапорцями Kshana. UBX-NAV-STATUS spoofDetState і UBX-SEC-SIG зчитуються в self_report на кожній епосі, а порівняння receiver_self_report у результаті зіставляє їх із моніторами Kshana (обидва, лише приймач, лише Kshana, жоден); воно не підіймає тривоги й не змінює жодної оцінки. До них додаються зчитувач Septentrio SBF (PVTGeodetic, MeasEpoch, RFStatus, лише читання, на крейті sbf-tools під ліцензією MIT) і receiver-trust live --serial (потік NMEA через послідовний порт або USB, лише читання; він ніколи нічого не записує в приймач).
• Синхронізація часу та апаратна безпека (docs/TIMING-HIL.md, docs/HARDWARE-SAFETY.md). Вид сценарію holdover-test оцінює випробування holdover системи синхронізації часу (ГНСС вилучено оператором, holdover, відновлення) за виміряним записом похибки часу порівняно з масками ITU-T із публічних таблиць. clock_log читає журнали linuxptp (ptp4l, phc2sys, ts2phc) і chrony (tracking, statistics). iq scene --format sdrx записує метадані ION GNSS SDR, а iq monitor --follow стежить за записом SigMF, поки він зростає (лише прийом). compliance-report отримує профіль NIST IR 8323r1 Foundational PNT Profile (15 переказаних рядків, підтримує докази для (supports evidence for)). Пакет доказів може записати lab-attestation оператора у свій підписаний маніфест, ніколи не перевіряючи його; апаратні етапи від 0 до 4 і юридичні примітки наведено в HARDWARE-SAFETY.md (очікує юридичного розгляду). Жодного тракту передавання будь-якого виду немає.
• kshana-bench v1 (kshana bench, bench/SPEC.md, docs/BENCH.md): фіксовані завдання, розбиття та метрики для виявлення завад ГНСС на журналах приймача (JammerTest 2024) і IQ, прогнозування holdover синхронізації часу (годинники IGS) і розриву оптимізму поза розподілом; маніфести розбиття із закріпленими хешами та скрипти завантаження (дані не включено до репозиторію), запечатаний holdout за схемою коміт і розкриття, схема файлу результату та статична сторінка таблиці лідерів. Базові рівні за порогами, попередньо зареєстрованими в xval/bench/PREREGISTRATION.md: пороги оцінювача виконано, C1–C3 виконано, D2 виконано; A2 NOT MET (agc_k_sigma AUC 0,766 проти щонайменше 0,80 на тестовому розбитті), D1 NOT MET (найбільша розбіжність 0,0301) і завдання (b) R1 NOT MET (перенесено, не запущено повторно), кожен закріплено (xval/bench/RESULTS-v2.md). Кожна оцінка — MODELLED. Python bench_score, bench_leaderboard; WebAssembly те саме; MCP score_benchmark, render_leaderboard.
• Обсерваторія завад (kshana interference-map daily, sensitivity, docs/observatory/METHOD.md): відтворюваний щоденний GeoJSON, PNG і JSON звіту про інциденти з трьома станами (погіршено, не погіршено, не спостерігалося), мінімальною затримкою 24 год, комірками 0,5 градуса або грубшими, без приписування причини та з відмовою від даних OpenSky; дослідження чутливості попередньо зареєстрованих параметрів; 30-денний балтійський ретроспективний каталог з adsb.lol.
• Машинні та сенсорні входи для receiver-trust (docs/MACHINE-INPUTS.md). Нові значення [log] format, усі лише для читання, MODELLED, із самостійно написаними фікстурами та без включених даних: rtklib-pos (файли розв'язків RTKLIB .pos), novatel (OEM7 ASCII та двійкові BESTPOS, RANGE C/No та RXSTATUS; прапорець глушника приймача стає self_report епохи, зіставленим із тривогами Kshana порівнянням receiver-self-report), rtcm3 (C/N0 MSM4 і MSM7 для GPS, ГЛОНАСС, Galileo, SBAS, QZSS, BeiDou і NavIC; розкладки з таблиць pyrtcm під ліцензією BSD, чиє повідомлення міститься в NOTICE, а не зі стандарту RTCM) і gnss-sdr (повідомлення GNSS-SDR Monitor і PVT-монітора як рядки JSON, ретрансльовані integrations/gnss-sdr/relay.py).
• Журнали IMU як другий сенсор. [log.imu] (csv або euroc) інтегрує швидкість рискання гіроскопа в курс, який читає монітор heading-course; вбудовано на кожній поверхні та передається через пакети доказів. kshana imu-fit (Python imu_fit, WebAssembly imu_fit, MCP fit_imu_log, плагін /kshana-fit-imu, дія JetBrains) підганяє параметри акселерометра та гіроскопа сценаріїв hybrid і fusion за нерухомим журналом через девіацію Аллана та виводить таблицю [accel_classical] із SHA-256 журналу в її походженні.
• Інтеграції: пакет ROS 2 (integrations/ros2/kshana_trust: NavSatFix і ublox_ubx_msgs на вході, теми довіри на виході; його міст без ROS перевірено на реальному рушії, а сам вузол на живому графі ROS не запускали), міст gnss_lib_py (integrations/gnss_lib_py, залежність MIT, необов'язкова) і ретранслятор GNSS-SDR.
• Експортер Home Assistant MQTT для телеметрії довіри: kshana trust-telemetry --print-mqtt і --mqtt-tcp <host:port> (повідомлення виявлення та документ стану JSON; лише публікація, без облікових даних і TLS) і format = "mqtt" як текст у Python, WebAssembly і MCP.
• Сім рядків реєстру рівня MODELLED для наведеного вище. Нічого тут не має рівня VALIDATED: жодного запису від реального приймача, базової станції, IMU, прогону GNSS-SDR, графа ROS чи брокера MQTT не читали.
• Запас оптичного каналу в часі. Вид optical-atmosphere приймає необов'язкову таблицю [timeseries] (duration_h, step_s, seed) і тоді також записує для кожної ділянки одну реалізацію із зерном заявленої моделі ділянки в часі: епізоди хмарності, стовп рідкої води для кожного епізоду, один відлік гамма-гамма мерехтіння на крок, а з них запас каналу, завмирання від хмар і мерехтінь і прапорець працездатності каналу, із реалізованими доступністю, часткою хмарності, кількістю перерв і найдовшою перервою. MODELLED (один розіграш із моделі, а не клімат; без зовнішнього оракула). Без таблиці результат — документ 0,37. Два вбудовані оптичні сценарії містять таблицю (336 год, 600 с, зерно 37). Пороги попередньо зареєстровано в xval/optical-atmosphere/PREREGISTRATION-timeseries.md до першого прогону.
• Специфікація умов випробування та лабораторне коло. kshana.test-conditions/1 опубліковано як docs/spec/TEST-CONDITIONS.md зі схемою JSON і додано recording.kind = "receiver-log". kshana bench-export також записує <base>.conditions.json. kshana evidence round-trip будує підписаний пакет, що пов'язує хеш сценарію, хеш заявлених умов, хеш журналу приймача та оцінку щодо заявлених подій, і відмовляє в умовах, які не збігаються з подіями оцінювання. Робочий приклад із gps-sdr-sim, що лише записує файл; відтворення — відповідальність оператора і ніколи не автоматизується. Python evidence_round_trip, MCP create_round_trip_pack, плагін /kshana-evidence-pack.
• Пакети стандартів (kshana standards-pack, standards/): тестові профілі рамки DHS Resilient PNT для рівнів від 1 до 4, рівні точності IMO MSC.1/Circ.1575 та оцінювання цілісності, а також ICAO Doc 9849, додаток F, — моніторинг, оцінювання та пом'якшення, кожен як набір сценаріїв, оцінених за порогами, заявленими до прогону, з рядками compliance-report, для яких вони підтримують докази (supports evidence for). Промахи записано й закріплено: DHS L4-T1 і чотири тести точності IMO. Сам Doc 9849 не читали (платний); пакет ICAO відповідає власній презентації ICAO щодо Плану пом'якшення RFI. compliance-report отримує розділ standards-pack. Усі MODELLED.
• Розширений прямий сигнал LunaNet (docs/LUNANET-AFS.md): коди Голда AFS-I і Вейля AFS-Q для PRN від 1 до 210, сигнали lunanet-afs-i і lunanet-afs-q в kshana iq, код SB1 BCH, CRC-24Q і перемежувач, а також kshana lunanet-afs-check (spec, symbols, generate), закріплено за LNIS V5 Applicable Document 1 Volume A (LSIS-AFS V1.0, 29 січня 2025). Коди VALIDATED щодо надрукованих таблиць документа (які він позначає як TBC); один надрукований третинний стовпець (PRN 147), імовірно, є друкарською помилкою, і промах закріплено. Кодування LDPC підкадрів від 2 до 4 не реалізовано.
• Навчальні блокноти курсу (notebooks/course/): глушіння, спуфінг, holdover, цілісність, OSNMA і карта завад, кожен із вправами.
• Дослідження максимального URA для ARAIM, етап 3, робоча група EU-US WG-C (xval/araim-m3/, src/bin/gen_araim_m3_study.rs), що замінює відкликаний план «Table A-3»; MODELLED із заявленими відхиленнями.
• Чернетки для схвалення власником у docs/drafts/: стаття для JOSS, поправка до статуту TSC, процес реєстру оракулів і пропозиція щодо розділення LICENSES/. Нічого з цього не ухвалено.
• Подання Studio для можливостей версії 0,38 (kshana.dev/studio/). Відтворення мосту (два синтетичні прогони на одному годиннику: траєкторія, оцінка довіри, супутники, які чує журнал, і вердикт, із власними прапорцями приймача поряд із тривогами Kshana); оптичне PNT (два сценарії optical-atmosphere із необов'язковою реалізацією [timeseries] із зерном, MODELLED); тест holdover (результат holdover-test, виміряний щодо масок ITU-T, побудований за власним record.series результату); засіб перегляду обсерваторії завад, що відкриває створені вами файли й не постачає жодного; на сторінці Інструменти — оцінювач Jammertest, підгонка IMU і MQTT як формат телеметрії; а в розділі Довіра — вибір формату журналу (RTKLIB .pos, NovAtel OEM7, RTCM 3, GNSS-SDR, Septentrio SBF) із необов'язковим файлом IMU. Кожне подання читає файли в браузері й нічого не вивантажує; кожен показник зберігає мітку, яку тримає для нього реєстр, і кожне супроводжується консультативним застереженням. Сторінка сайту /benchmark показує фрагмент kshana bench leaderboard.

Виправлено#

• Проблема №36: побайтово точні шари закріплень. Побайтово точні шари закріплень виконуються лише на хості, оголошеному базовим (KSHANA_EXACT_PINS=1, встановлюється scripts/gate.sh), а не на кожному Mac на Apple silicon, бо математична бібліотека Apple відрізняється між випусками macOS; переносний шар працює скрізь, а tests/exact_pin_gate_guard.rs не дає знову прив'язати побайтово точний шар лише до платформи. Самі порівняння з оракулами на macOS проходять. Жодного літерала не перезнімали, жодного допуску не змінено. scripts/oracle-triage.sh і docs/LOCAL-ORACLE-TESTS.md описують, як розбирати розбіжність; .github/workflows/oracle-macos.yml — це ручна та щотижнева діагностика, а не шлюз.
• CodeQL: непривʼязаний шаблон у допоміжній функції trust-open у Studio тепер збігається з усім заголовком (web/studio/lib/trust-open.mjs).
• CI: диск виконавця. Завдання check збирає профілі dev і test без налагоджувальної інформації, тож компонування більше не заповнює диск.
• Захисти вихідного коду. Кожен вихідний файл, що містить тестові фікстури із закріпленнями, оголошує свою область закріплення, а тести, що пишуть тимчасові файли, використовують унікальний шлях для кожного виклику, тому паралельні прогони не можуть зіткнутися.
• docs/SCENARIOS.md згенеровано заново для необов'язкового поля optical-atmosphere timeseries.
• Плагін JetBrains: жодного використання застарілого чи запланованого до вилучення API платформи. IntelliJ Plugin Verifier (verifyPlugin) на збірці IntelliJ IDEA 263 (2026,3: 263.6800.24 і 263.7031.23) знайшов один застарілий виклик, FileEditorManager.openFile, у Insert Example; тепер він відкриває новий файл через OpenFileDescriptor. Плагін сумісний із 2024,3 (збірка since-build, без змін) і з обома збірками 263 і чистий на них. CI тепер запускає verifyPlugin і завершується помилкою на проблемах сумісності та на будь-якому використанні API, запланованого до вилучення.

[0.37.0] - 2026-10-17#

Додано#

• Оптичне PNT крізь атмосферу (вид сценарію optical-atmosphere, docs/OPTICAL-ATMOSPHERE.md, примітка до проєкту docs/design/optical-atmosphere-0.37.md). Для оптичного каналу та набору наземних ділянок він повідомляє втрати в чистому повітрі залежно від довжини хвилі та кута місця, стан турбулентності Хуфнагеля–Веллі (дисперсія Рітова, індекс мерехтіння, гамма-гамма завмирання, усереднення по апертурі), доступність залежно від запасу каналу за заявленим кліматом хмарності, запас, потрібний для цільових доступностей, і стелю, яку жоден запас не піднімає, розподіл тривалості перерв, похибку синхронізації та дальнометрії для кожної перерви через модель holdover годинника, різноманіття ділянок із кореляцією за відстанню та гіпотетичні виграші від зміни довжини хвилі, більшої апертури, зменшення мерехтіння адаптивною оптикою та додаткового запасу. optical_linkbudget отримує бюджет із урахуванням атмосфери; без нього його вихідні дані побітово ідентичні з 0,36 (поріг A5). Два вбудовані сценарії містять ILLUSTRATIVE кліматичні дані хмарності. MODELLED: три рядки реєстру. Числові методи виконують пороги A1–A6, попередньо зареєстровані в xval/optical-atmosphere/PREREGISTRATION.md, відносно незалежної програми mpmath; це перевіряє реалізацію заявлених формул, а не атмосферу, і жодного виміряного запису доступності не порівнювали, тому жоден рядок не має рівня VALIDATED. Поріг A4 спершу було не досягнуто на 3e-9, бо використаний нормальний CDF був наближенням з похибкою 1.5e-7; CDF замінили, а поріг залишили таким, як зареєстровано. Нативна збірка та збірка WebAssembly повертають побайтово ідентичні документи для обох вбудованих сценаріїв (A7, виконано на інтеграційному коміті 0.37.0).

[0.36.0] - 2026-10-16#

Додано#

• Крива ROC виявлення для моніторів IQ (PRO-32, docs/design/DETECTION-ROC.md). Кампанія з моніторами зберігає максимум статистики кожного тесту за вікнами заявлених подій (позитивні) та за вікнами-плитками поза подіями (негативні, roc_window_s). Звіт об'єднує їх за видом тривоги в ROC з її AUC і робочою точкою на налаштованому порозі, як roc.json і розділ звіту. На синтетичних кампаніях перевірку на рівні випадковості виконано. Поріг AUC для C/N0 (0,95) не виконано (0,79), оскільки негативні вікна відразу після події успадковують від виявлення спад CUSUM; це записано. MODELLED.

• Монітори IQ у кампанії відтворення в лабораторії (PRO-31, docs/design/MONITORS-IN-CAMPAIGN.md). Необов'язкова таблиця [monitors] у файлі кампанії запускає монітори IQ в єдиному проході виконавця: потужності та спектральний після кожного ланцюга фронтенда, а також C/N0, SQM і захоплення для кожного відстежуваного каналу. Їхні тривоги оцінюються щодо заявлених подій: виявлено чи пропущено, час виявлення та хибні тривоги на годину експозиції. Для кожного тесту заявлено замкнену формулу хибної тривоги, зокрема нову двосторонню гаусівську формулу для тестів SQM (2Q(k)). Без таблиці нічого не змінюється. На синтетичних кампаніях пороги хибних тривог для потужності та SQM і поріг хибної тривоги C/N0 виконано; 18 із 18 ослаблень виявлено, але межу часу виявлення, нижчу за один відлік детектора за побудовою, не виконано, і це записано. MODELLED; рядок реєстру «Монітори IQ, оцінені в кампаніях відтворення в лабораторії».

• Лабораторна підгонка за кампаніями IQ, продовження (tests/iq_labfit_followup.rs, завдання CI labfit-iq-followup). Воно перевіряє дві гіпотези, які розділ §13,6 документа docs/design/LABFIT-FROM-IQ.md залишив відкритими, за порогами, попередньо зареєстрованими в 1e532f84. Воно додає дві синтетичні кампанії: S зі ступінчастим J/S (зерно 2026_1014) і R, нову лінійну зміну (зерно 2026_1015). Результати наведено в docs/design/evidence/labfit-followup/RESULTS.md.

  • S1 виконано: за утримання кожного рівня J/S δ_eff відновлюється в межах +0,185 дБ. Похибка −1,1 дБ у кампаніях із лінійною зміною — це запізнення оцінювача.
  • S2 не виконано, закріплено тестом, що стверджує промах: (d) у записаному вигляді на кампанії зі ступінчастою зміною виконується для моделі контуру стеження (0,45 дБ), але не для емпіричної (6,42 дБ).
  • R1 виконано: на новій кампанії з лінійною зміною (d) із підігнаним спадом, помноженим на час утримання, до якого додано швидкість лінійної зміни кожної події, лежить у межах 1 дБ для обох моделей.
  • Промахи (a′) і (d) повторюються на R.
  • Кампанія тепер може заявити свій J/S як профіль step у тестовому каркасі.
  • Жоден вердикт розділу §13 не змінюється, а рядок реєстру залишається MODELLED.

• Обмежене входження FLL, за вибором (DS-LOOP-05): новий ключ проєкту контуру [design.carrier] fll_pull_in_max_s (с), Rust LoopConfig::fll_pull_in_max_s. За fll_assist = "pull-in" він примусово передає керування від FLL до ФАПЧ після цього часу, незалежно від PLI. За замовчуванням не задано, і тоді він поза хешем проєкту; типовий проєкт і його хеш не змінюються.

  • Перевірено за порогами, попередньо зареєстрованими в 58789af0, на введеній істині. Контроль виконано: типовий режим ніколи не передає керування в 9 із 10 зерен при 33 дБ-Гц.
  • Не виконано: з обмеженням у 1,0 с 16 із 20 прогонів утримують захоплення при 33 дБ-Гц і 8 із 20 при 31 дБ-Гц; решта циклічно чергують примусове передавання й повернення FLL. Фазовий джитер становить 1,8× від самої ФАПЧ при 33 дБ-Гц.
  • Поріг входження ~35 дБ-Гц залишається задокументованою межею типового режиму.
  • MODELLED; рядок реєстру «Обмежене входження FLL нижче порога передавання від FLL до ФАПЧ типового проєкту (за вибором)».

• Гістерезис захоплення та квантувач фронтенда у виді jamming (CAP-06c): два необов'язкові розділи для сценарію jamming.

  • [acquisition]: acquisition_threshold_dbhz (дБ-Гц, на порозі стеження або вище) і reacquisition_delay_s (с, за замовчуванням 0). Супутник захоплюється на порозі захоплення або вище, коли він був незахопленим протягом затримки. Він утримується, поки значення на порозі стеження або вище. Вихідні дані: epochs[].sats[].acquired (true/false), epochs[].acquired (кількість) і fom.availability_acquired (1).
  • [front_end]: adc_bits (від 1 до 16) і bandwidth_mhz (МГц, за замовчуванням удвічі більше за чипову швидкість). Виводить блок front_end: agc_gain_reduction_db (дБ, 10·log10(1 + J/N)), quantiser_loss_db (дБ, віднімається від ефективного C/N0 кожного каналу) і loss_model. Втрати — для гаусівського входу, позначені як недійсні для CW, вузькосмугових і свіпових глушників.
  • Без цих розділів усі вихідні дані побайтово ідентичні.
  • Перевірено за порогами, попередньо зареєстрованими в 70c72fcc. Втрати квантувача в межах 0,0007 дБ від незалежного Монте-Карло, а показання AGC у межах 0,012 дБ від циклу AGC шару IQ.
  • Зареєстровані прогони гістерезису були неінформативними (усі канали втрачено), тому цей поріг NOT MET. Додатковий набір прогонів, зареєстрований у 37793290, його виконує: кожен прапорець дорівнює незалежному перерахунку, і 732 із 1824 каналів показують гістерезис.
  • Висновок: із CW-глушником 1-бітовий АЦП втрачає приблизно на 5 дБ більше, ніж гаусівське значення.
  • MODELLED; рядок реєстру «Гістерезис захоплення та квантувач фронтенда у виді jamming порівняно з незалежними перерахунками».

• Затінення глушника рельєфом у виді jamming (CAP-06b): необов'язковий розділ [terrain] у сценарії jamming із глушником. Поля:

  • dem_hgt: тайл SRTM .hgt відносно робочого каталогу;
  • samples_per_side, ll_lat_deg і ll_lon_deg (град): розмір і кут тайла;
  • geoid_undulation_m (м, за замовчуванням 0), k_factor (за замовчуванням 4/3) і profile_step_m (м, за замовчуванням 30).

  Рушій добирає профіль рельєфу вздовж великого кола між глушником і приймачем і знаходить домінантне лезо ножа. Потужність глушника на вході приймача, а отже й кожне J/S, знижується на втрати на одному леза ножа за ITU-R P.526-15 §4,1.

  • Результат отримує блок jammer_terrain: nu_max (1), diffraction_loss_db (дБ), obstacle_distance_m (м), obstacle_terrain_m (м), path_length_m (м) і profile_points (кількість).
  • Без цього розділу всі вихідні дані побайтово ідентичні.
  • Перевірено за порогами та десятьма розташуваннями, попередньо зареєстрованими в 92cd2bfd, на зафіксованому реальному тайлі SRTM Долини Смерті, відносно незалежного перерахунку в numpy. Усе виконано: найгірша різниця 1.6e-10 на ν і на втратах (поріг 1e-9), втрати монотонні за висотою глушника, а втрати досягають J/S точно.
  • MODELLED; рядок реєстру «Затінення глушника рельєфом у виді jamming порівняно з незалежним перерахунком у numpy на реальному тайлі SRTM».

• Коефіцієнти підсилення антени CRPA у виді jamming (CAP-06a): необов'язковий розділ [crpa] у сценарії jamming. Поля: elements_enu_m (положення елементів у локальній системі схід–північ–вгору, м), weighting ("null-steering" або "mvdr") і bandwidth_mhz (шумова смуга MVDR, МГц, за замовчуванням удвічі більше за чипову швидкість).

  • Кожен канал формує промінь без спотворень на свій супутник. Шум каналу масштабується на ‖w‖², а глушіння на |wᴴa_j|² перед наявним рівнянням C/N0 в умовах протидії глушінню.
  • Кожен канал отримує блок crpa: array_noise_gain_db (дБ) і jammer_gain_db (дБ).
  • Без цього розділу всі вихідні дані побайтово ідентичні.
  • Недійсний розділ (порожній список елементів, невідоме зважування, невід'ємна... ненульова ширина смуги) є помилкою, через kshana і api::run_toml, а також через jamming::run_jamming.
  • Перевірено за порогами, попередньо зареєстрованими в 08d83b4d. Виконано: адитивність (після виправлення: перша збірка додала нові одиниці до таблиці одиниць кожного прогону jamming); один елемент — це не решітка; шумове підсилення та ефективне C/N0 відносно незалежного перерахунку в numpy у межах 1e-9 дБ; MVDR прямує до нуля за високого JNR.
  • Не виконано: підсилення глушника MVDR на 194 із 456 каналів на переносній математиці 0,36 (202 на математиці хоста; docs/revisions/STUDIO15-batch4-rebaseline.md) (найгірше 1.7e-6 дБ). Залишки від −100 до −188 дБ нижчі за роздільну здатність float64 на цьому порозі, а numpy розходиться сам із собою на той самий порядок.
  • MODELLED; рядок реєстру «Коефіцієнти підсилення антени CRPA у виді jamming порівняно з незалежним перерахунком у numpy».

• Рушій стеження IQ порівняно з GNSS-SDR 0.0.19 (PRO-33): kshana iq track і GNSS-SDR стежать за тими самими незалежними записами numpy GPS L1 C/A при 30–45 дБ-Гц.

  • Пороги попередньо зареєстровано в 48edd4a5. Зареєстроване калібрування не пройшло через хибне передавання в GNSS-SDR (F3), тому поправка 1 (1e4288c4) додає до обох приймачів FLL лише для входження, зафіксований до будь-якого тестового запису.
  • Виконано: джитер несівної та коду й Доплер збігаються в межах 5 % за кожного C/N0.
  • Не виконано: C/N0 NWPR рушія показує на 2,3–7,1 дБ нижче за SNV GNSS-SDR (F4, відома межа оцінювача; M2M4 у межах 0,06 дБ від істини); індикатори захоплення відрізняються за визначенням (F5); одна розбіжність зриву на 30 дБ-Гц (F6).
  • MODELLED; рядок реєстру «Рушій стеження IQ порівняно з GNSS-SDR 0.0.19 на незалежних записах».

• Два рядки VALIDATED для кодів шару IQ (DS-GIQ-06b, PRO-39).

  • BeiDou B1I. Усі 63 первинні коди B1I збігаються з незалежним генератором GNSS-SDR v0.0.19 чип у чип (поріг попередньо зареєстровано в 911106d1). Зафіксовано лише вихідні дані цієї програми: коди PRN B1I, які визначає публічний ICD, як префікс і хеш.
  • GPS L1C. Усі 126 кодів L1CP/L1CD і 63 накладок L1CO збігаються з контрольними стовпцями, які друкує IS-GPS-800J, а обчислена послідовність Лежандра збігається з його таблицею 6.2-1 (пороги попередньо зареєстровано в fe372e26).
  • Рядки: «Первинні далекомірні коди BeiDou B1I порівняно з незалежним генератором» і «Далекомірні та накладні коди GPS L1C порівняно з надрукованими контрольними стовпцями IS-GPS-800J».

• Смуги ГЛОНАСС, BeiDou і Galileo E6 у моделі спектра (CAP-12, сигнали): нові назви смуг glonass-l1of і glonass-l2of (будь-який канал FDMA як glonass-l1of-k<K>, K = −7 до 6), beidou-b1i, beidou-b1c, beidou-b2a, beidou-b3i і galileo-e6. Кожна несе несівну, модуляцію та мінімальну потужність прийому зі свого ICD. Вони вмикаються за вибором, за назвою: типовий набір смуг і всі наявні вихідні дані не змінюються.

  • Перевірено за порогами, попередньо зареєстрованими в 5806f28b: значення ICD, нулі, складена B1C і шлях C/N0 виконано.
  • Два пороги не виконано. Поріг одиничної площі був недосяжним у записаному вигляді (F1). Хвильові форми B1I і B1C шару IQ відповідають моделі лише в усередненні по смузі через нерівномірні лінійчаті спектри їхніх кодів (F2).
  • MODELLED; рядок реєстру «Модель спектра: смуги ГЛОНАСС, BeiDou і Galileo E6 (за вибором)».

• Варіант CFAR з усередненням за комірками в IQ-захопленні (PRO-37): iq::acq::ca_cfar і ca_cfar_cells ухвалюють рішення на сітці захоплення, порівнюючи кожну комірку із середнім опорних комірок її рядка Доплера. Поріг виводиться із замкненої формули ймовірності хибної тривоги CA-CFAR для M некогерентних блоків (ca_cfar_pfa, ca_cfar_alpha), тож рішення не залежить від нормалізації за потужністю відліку. Це вмикається за вибором; типовий детектор і всі наявні вихідні дані не змінюються.

  • Перевірено за порогами, попередньо зареєстрованими в 3724aefa: замкнена формула проти Монте-Карло (18 із 18 випадків) і проєктне значення 1 %, виміряне як 0,97–1,01 % на гаусівському та 2-бітовому квантованому шумі.
  • Один поріг не виконано: на безшумовому 2-бітовому сигналі 1,28 % позапікових комірок перевищують поріг, на бічних пелюстках кореляції коду (висновок F1).
  • MODELLED; рядок реєстру «Варіант CFAR з усередненням за комірками в IQ-захопленні».

• Модель мерехтінь порівняно з виміряними даними (PRO-34): модель мерехтінь Cornell каналу IQ порівняно з виміряними інтенсивністю та фазою GPS L1 на 50 Гц із екваторіальної ночі мерехтінь (запис Zenodo 16941224, INGV, Малінді, CC BY 4,0) за порогами, попередньо зареєстрованими в b6ccb499. Виконано: розподіл інтенсивності та фазові мерехтіння, пов'язані з S4. Не виконано: модель завмирає в 2,4 раза частіше нижче −10 дБ і в 3,5 раза довше (висновок F1). Зареєстрована обробка читає загорнуту фазу моделі (висновок F2); результат за фазою зберігається з розгорнутою. scripts/fetch_scint_malindi.sh завантажує дані. Рядок залишається MODELLED: «Канал іоносферних мерехтінь IQ (модель Cornell) порівняно з виміряними мерехтіннями GPS L1 на 50 Гц».

• Виправлений зчитувач відліків LuGRE (MR-09): realdata::lugre::parse_iqs_sdrx читає пакет IQ LuGRE з I у старшому півбайті та рівнями mid-rise 2v + 1 (SdrLayout::mid_rise), які усувають середнє −½, що його мають голі цілі числа в доповняльному коді на I і Q. run_acq.py --corrected дає GNSS-SDR те саме прочитання. Загальний зчитувач ION і всі наявні вихідні дані не змінюються: 149 результатів сценаріїв і дослідження побайтово ідентичні до і після, а закріплені висновки LuGRE читаються як зареєстровано (xval/lugre-reader/RESULTS.md). Жоден рядок реєстру не змінюється.

• Стеження за BOC(1 1) за вибором (CAP-07 (a)): LoopConfig::boc масштабує дискримінатори DLL для головного піку синусного BOC(1 1) і додає монітор bump-jump (дуже ранній і дуже пізній корелятори на ±0,5 чипа, лічильники вгору/вниз, N = 8), що зсуває NCO коду з бічного піку; Channel::bump_jumps перелічує стрибки. Вимкнено за замовчуванням, і всі наявні вихідні дані не змінюються. Перевірено за порогами, попередньо зареєстрованими в 6b68f6cc, на синтетичному сигналі BeiDou B1C: старт на бічному піку, що без параметра лишається на 0,55 чипа осторонь, з ним витягується на головний пік одним стрибком на 0,08 с, і жодного хибного стрибка з головного піку не побачено. Один поріг не виконано: сітка модульних тестів для масштабування виходить за лінійний діапазон дискримінаторів (висновок F1 у docs/design/evidence/boc-bump-jump/RESULTS.md). MODELLED; рядок реєстру «Стеження за BOC(1 1): масштабування DLL і розв'язання неоднозначностей bump-jump (за вибором)».

• Лабораторна підгонка за кампаніями IQ (B7.1, docs/design/LABFIT-FROM-IQ.md). [input] campaign = "<out-dir>" сценарію labfit підганяє вихідну теку kshana iq campaign у командному рядку (kshana iq labfit), у Python (kshana.iq_labfit) та в інструменті labfit MCP (лише теки всередині його робочого каталогу). Вона підганяє одну одиницю для кожного сигналу, проєкту контуру, ланцюга фронтенда та типу глушника:

  • модель C/N0 щодо заявленого J/S із цензуруванням;
  • поріг стеження, безпосередньо та в замкненому вигляді;
  • моделі захоплення контуру стеження та емпіричну, зв'язані через модель C/N0, з їхніми часами утримання;
  • кластерний бутстреп із зерном за записами, 90 % інтервали прогнозу та відкладені набори з виключенням одного запису;
  • попередньо зареєстровану хешовану таблицю [validation] із PASS/FAIL для кожного порога.

  Звіт — це kshana.labfit-iq/1 у вигляді JSON, CSV і Markdown, із блоком одиниць. Q_eff не можна ідентифікувати за даними C/N0 без незалежного вимірювання потужності. Його заявлено, але ніколи не підганяють, а підганяється параметр delta_eff = delta - 10 log10 Q (поправка до проєкту 2026-10-12). Невідомий тип глушника приймає найшкідливіше заявлене Q (cw, 1). На синтетичних кампаніях зі сцен самої Kshana поріг покриття на відкладених наборах (c) проходить. Пороги delta_eff (a') і (b') (покрито 0 із 50 кампаній) і поріг замкненого порога (d) не виконано: їх записано разом зі значеннями. MODELLED; рядок реєстру «Калібрування моделей C/N0 і захоплення відкритого приймача за результатами кампаній IQ із заявленою похибкою прогнозу». Шлях labfit за журналом приймача та його вихідні дані не змінюються.

• solar-system на ядрі JPL (CAP-31): planetary_kernel_path бере кожне тіло, яке містить SPK (з de440s: Меркурій, Венера, Земля, Місяць), із ядра, мітка KERNEL, і додає блок kernel лише коли задано. Новий рядок, VALIDATED відносно SPICE (попередньо зареєстровано f8e946ea; найгірше 3.3e-5 м, 1.0e-11 м/с). Типовий звіт не змінюється.

• Porkchop на ефемеридах DE440 (CAP-20b): maneuver::porkchop_kernel перебирає C3 і V∞ прибуття за геліоцентричними станами з DE440 SPK. Новий рядок, VALIDATED відносно станів SPICE

  • pykep 3.0.1 (попередньо зареєстровано 2d857fb1; Земля — Марс 2026–2028, 304 комірки, найгірше 2.6e-14, та сама комірка мінімального C3).

• Негравітаційна макромодель LRO: NOT MET (DS-LRO-10, попередньо зареєстровано e82047e2). lunar_od::LunarMacroModel (за вибором через LunarForceModel::macro_model): пряма сонячна радіація на плоскі пластини з тінню Місяця, батарея, що стежить за Сонцем, а також місячне альбедо та тепловий ІЧ; LunarMacroModel::lro_generic — це марковане загальне наближення LRO за опублікованими фактами (без пластин корпусу: таблицю пластин отримати не вдалося). На 4-годинній дузі LRO вона залишає редуковане динамічне СКВ на 6,668 м, а динамічне на 11,94 м, із неправдоподібним коефіцієнтом радіації (близько +21 / −22), тож усі три пороги не досягнуто. Висновок закріплено тестом, і жодні типові вихідні дані не змінюються (docs/design/evidence/ds-lro-10-macro-model/RESULTS.md). Необов'язковий місячний SRP за моделлю гарматного ядра тепер використовує конічну тінь Місяця замість тіні Землі (forces::conical_shadow_body).

• Місячне визначення орбіти: необов'язковий твердий приплив k2 і селеноцентрична релятивістика (DS-LRO-11), за замовчуванням вимкнено (LunarForceModel::lunar_tide, ::relativity); перемикач KSHANA_LRO_DEGREE для перехресної перевірки ANISE (DS-LRO-04); фікстура 24-годинної дуги LRO та інформаційна підгонка довгої дуги (DS-LRO-09). Інформаційні прогони записано в docs/design/evidence/ds-lro-09-11-longer-arc/RESULTS.md; жодне опубліковане число не змінюється.

• NRHO 9:2 у CR3BP порівняно з CAPSTONE (CAP-29d): новий рядок MODELLED, що вимірює колову обмежену NRHO рушія щодо реально пролетілої орбіти CAPSTONE (JPL Horizons, березень 2023; попередньо зареєстровано 4e868170): період 1,07 %, апоселенія 0,05 %, периселенія 4,1 % від середніх CAPSTONE, у межах зареєстрованих порогів 3 / 5 / 20 %. Вимірювання, а не перевірка незалежним еталоном.

• Обертові стани CR3BP до ICRF із центром у Місяці (RM-34, FUT-06): cr3bp::to_moon_centred_icrf / from_moon_centred_icrf / to_moon_centred_icrf_de440 відображають безрозмірний обертовий стан Земля–Місяць на миттєву лінію Земля–Місяць за DE440, враховуючи позаплощинну швидкість системи відліку. Новий рядок, VALIDATED відносно двовекторної системи відліку SPICE (попередньо зареєстровано 2313eb1b, змінено до будь-якого прогону d5ef79b3; 72 випадки, найгірше 1.8e-7 м і 1.2e-9 м/с).

• Члени родини CR3BP порівняно з API періодичних орбіт задачі трьох тіл від JPL: NOT MET (RM-35, попередня реєстрація a9074f65). cr3bp_family (корекція гало-орбіт, NRHO і DRO, індекс стійкості монодромії, продовження за псевдодовжиною дуги) збігається з 54 із 58 членів API за кожним порогом (стан, період і константа Якобі в межах 1e-10 скрізь). Один індекс стійкості гало-орбіти L1 (9.5e-2) і три замикання малих DRO (від 1.5e-8 до 3.3e-8 за порогу 1e-8) порогу не досягають, тому модуль має позначку #[doc(hidden)], і жоден рядок не заявляє про нього. Результати: docs/design/evidence/cr3bp-families/RESULTS.md.

• Додаткова (opt-in) орієнтація та середовище Місяця за DE440 (FUT-05, DS-LRO-08; типові налаштування не змінено): lunar_frame::try_icrf_to_moon_pa_de440, lunar::try_mci_to_mcmf_de440 / try_mcmf_to_mci_de440 (прив'язані до епохи, головні осі DE440) і lunar_od::De440LunarEnvironment (вбудована орієнтація за головними осями DE440 плюс геоцентричні Сонце та Місяць із наданого користувачем SPK DE440). Порівняно з ANISE (попередня реєстрація ea537710): орієнтація в межах 3.5e-7 рад, а підгонки LRO в межах 1 мм, але ефемеридна ланка не досягла свого порогу (Сонце 30,7 м, Місяць 1,1 м, зсув часу ≈ 1 мс з боку ANISE), тому це не рядок, перевірений за незалежним зовнішнім еталоном. Результати: docs/design/evidence/fut05-de440-lunar-env/RESULTS.md.

• Датум місячної системи відліку для кампанії, поріг NumPy з масштабуванням за обумовленістю: NOT MET (попередня реєстрація b887eb05; залишається MODELLED). Крок 0 виключає запасний варіант з псевдообернення як причину розриву 0,30 за кількістю оцінюваних станцій; NumPy збігається в межах порогу в шести з восьми сценаріїв, але stations_estimated порогу не досягає (6.8e-6 проти 5.9e-7), а на свіжу дату 2026-12-01 неспостережуваний маяк на південному полюсі робить інформаційну матрицю маяків ранг-дефіцитною, чого незмінений оракул оцінити не може. Результати: docs/design/evidence/mr05-lunar-datum-cond/RESULTS.md.

• Датум місячної системи відліку з реальної спостережної кампанії (аналітичний Місяць): VALIDATED на свіжих нормальних точках EDC за 2025 рік (попередня реєстрація 31f5283 до отримання будь-якої з них): незмінений оракул SPICE і NumPy збігається щодо обліку, рангів і нульового зв'язку, а також у межах 1.11e-3 для сигм (поріг 1e-2), 8.95e-4 для обумовленості та 1.79e-3 для відношень поперек/вздовж (поріг 2e-2). Це лише перевірка обчислення коваріації бібліотекою; пороги не розрізняють моделей Місяця. Результати: docs/design/evidence/mr06-llr-analytic-fresh/RESULTS.md.

• Орієнтація за IAU і GM чотирнадцяти доданих тіл Сонячної системи виокремлено з рядка «Фізичні константи кожного тіла Сонячної системи» в рядок VALIDATED (попередня реєстрація 154bc54): Body::iau_rotation_et збігається зі SPICE pxform на pck00011 у межах 1e-9 рад на 574 матрицях за початкових епох і на 574 за 41 свіжих епох, які раніше ніколи не порівнювали (найгірший випадок Фобос 1.38e-10 рад), а Body::mu дорівнює gm_de440 для всіх чотирнадцяти тіл. Решта початкового рядка (J2, середній радіус, звіт) залишається MODELLED. Результати: docs/design/evidence/mr08-body-orientation/RESULTS.md.

• Багатообертова задача Ламберта (maneuver::lambert_multirev): кожен розв'язок до трьох обертів включно, обидві гілки. Новий рядок реєстру, VALIDATED за pykep 3.0.1 (попередня реєстрація a75de851; 382 випадки, 1058 розв'язків, найбільша різниця швидкостей 1.6e-13 проти 1e-8). Внутрішня перевірка посадки Кеплера виявила одне обмеження maneuver::kepler_universal на дузі з e = 0,994; його зафіксовано в docs/design/evidence/lambert-multirev/RESULTS.md.

• Тиск сонячного випромінювання за моделями «коробка з крилами» та ECOM2 (DS-PA-14), за вибором користувача (opt-in). srp_boxwing: модель «коробка з крилами» з плоскими пластинами й таблицями Galileo FOC/IOV із метаданих супутників GSC, за номінального керування рисканням ГНСС, із коефіцієнтом випромінювання та частинними похідними по панелях, а також емпірична модель ECOM2 з її частинними похідними. Вибирається за допомогою ForceModel::box_wing_srp / PreciseForceModel::box_wing_srp (поля srp_boxwing, типове значення None: гарматне ядро та всі еталонні результати не змінено); за наявності набору «коробка з крилами» cr є його коефіцієнтом випромінювання. Порівняно з Orekit 12,2 за попередньою реєстрацією (xval/srp-boxwing-orekit/): кожен поріг виконано, близько 1e-15 відносно; VALIDATED як оцінювання моделі, а прогноз тиску сонячного випромінювання для Galileo залишається MODELLED.

• Тінь від сплюснутої Землі для тиску сонячного випромінювання та потемніння сонячного краю до лімба (FUT-09, RM-11). Новий модуль srp_shadow: oblate_conical_shadow (затінювальний еліпсоїд WGS-84), limb_darkened_shadow (закон Еддінгтона) і ShadowModel, що вибирається за допомогою ForceModel::srp_shadow (типово: наявна сферична конічна тінь, без змін); forces::srp_accel_with_lit_fraction. Тінь від сплюснутої Землі збігається з коефіцієнтом освітленості Orekit 12,2 у межах 7.4e-9 на 2400 геометріях (VALIDATED, xval/srp-oblate-shadow-orekit/); для потемніння до краю зовнішнього оракула немає (MODELLED).

• Термосфера NRLMSISE-00 (FUT-08, RM-10, DS-PA-13). nrlmsise00: порт gtd7 і gtd7d (перемикачі, режими добового Ap і 3-годинного масиву ap) із C-версії коду NRL Fortran, що перебуває в суспільному надбанні. Він побітово ідентичний цьому C-порту та в межах 1.9e-6 відносно pymsis 0.13.0 (NRL Fortran, одинарна точність) на сітці з 720 точок і відтворює 17 опублікованих тестових випадків (VALIDATED; xval/nrlmsise00-pymsis/). Це підтверджує порт, а не точність моделі щодо виміряної густини.

• Додатковий (opt-in) рівень густини для опору за NRLMSISE-00. forces::DensityModel::{Exponential, Nrlmsise00 { f107a, f107, ap }}, forces::drag_accel_with_density, density_at і propagator::ForceModel::drag_density. Статична експоненційна модель залишається типовою, біт у біт. Космічна погода є сталою для кожної моделі. VALIDATED на рівні орбіти за власним опором NRLMSISE-00 в Orekit 12,2 упродовж 24 h (найгірше 0,03 м проти до 142 км зміщення через опір; xval/drag-tier-orekit/).

• Додаткові (opt-in) Сонце та Місяць за DE440 у пропагаторі Коуелла (RM-33, FUT-10). propagator::ForceModel::with_ephemeris приймає будь-який EphemerisProvider (наприклад, KernelEphemeris DE440) для членів третього тіла та тиску сонячного випромінювання; він відмовляється від провайдера, що не може обслужити епоху, враховує повернення до аналітичного ряду і типово вимкнений. EphemerisProvider::relative_position_jd2 зберігає двочастинну точність. Порівняно з Orekit 12,2 на його власному зчитувачі DE440, орбіти тривалістю 24 h збігаються до 0,017 м; попередньо зареєстрований поріг положення Сонця та Місяця не досягнуто (6,4 м / 0,24 м; SPICE показує той самий розрив), тому MODELLED (xval/propagator-de440-orekit/).

• Додатковий (opt-in) атмосферний приплив S1 (DS-PA-03). tides::atmospheric_tide_s1 і s1_air_tide_acceleration (Biancale & Bode 2006, GFZ STR06/01, таблиця 1, модель N1, ступені 2–6), вмикаються за допомогою air_tide_s1() на propagator::ForceModel і precise_od::PreciseForceModel; типово вимкнено. MODELLED (коефіцієнти повторно звірено з опублікованою таблицею; зовнішнього оракула для впливу цієї сили немає).

• Пакетне визначення орбіти за швидкістю зміни дальності та азимутом/висотою з маскою висоти (RM-36, FUT-13). orbit_determination::determine_orbit_batch_tracking, simulate_tracking, predict_tracking, propagate_with_stm (варіаційна STM з аналітичними частинними похідними двотільної задачі та J2), is_visible, measurement_with_partials; batch_ls::gauss_newton_analytic. Шлях лише за дальністю не змінено. Порівняно з пакетним методом найменших квадратів Orekit 12,2 на 8 попередньо зареєстрованих сценаріях: кожен поріг виконано, окрім збігу стану без шуму (≤ 1 см), який не досягнуто в 2 із 4 сценаріїв на 1,46 і 1,74 см, при цьому kshana в межах 1e-8 м від істини; зафіксовано, MODELLED.

• Зважування за точністю SP3 (DS-PA-06). sp3::parse_sp3_accuracy і Sp3Accuracy::position_sigma_m відображають коди точності із заголовка та з окремих записів на сигми спостережень; варіант підгонки Galileo з урахуванням ваг SP3 (3D RMS рівня 2 — 0,035 м проти 0,070 м без ваг) додано поряд із незмінними записаними прогонами. MODELLED.

• Завдання запуску повної дуги Swarm-A (DS-PA-08) у .github/workflows/agency-od-validation.yml.

• Гравітація планет із таблиць PDS SHADR (CAP-30, частина CAP-31). SphericalHarmonicField::from_shadr (src/gravity_pds.rs) зчитує Mars GMM-3 (ступінь/порядок 120) і GRAIL GL0660B (ступінь/порядок 660); Body::with_gravity_field підключає будь-яке завантажене поле (типові налаштування не змінено). Обрізки до ступеня 20 постачаються разом (NASA PDS, суспільне надбання; tests/fixtures/planetary_gravity/NOTICE.md); повні файли завантажуються за допомогою xval/planetary-gravity-pyshtools/fetch_data.sh. VALIDATED за pyshtools 4.14.1 (у межах 4e-15 повної гравітації за ступеня/порядку 120 на всій сфері, 5e-14 за ступеня/порядку 660 для |lat| ≤ 60°); прив'язка до системи координат тіла залишається MODELLED (власна система координат кожного поля не є системою IAU, яку використано).

• Гравітація високого ступеня до ступеня 2190 (RM-14, FUT-07). SphericalHarmonicField::acceleration_hf / potential_hf (модифікований прямий стовпчик Холмса–Фезерстоуна, без антипереповнення, без полярної сингулярності), prepare_high_degree, потоковий завантажувач ICGEM from_gfc_file / from_gfc_reader (перевірки норми та максимального ступеня, записана приливна система, часозмінні члени відхиляються) і scripts/fetch_egm2008.sh (повна EGM2008, закріплена за SHA-256, не постачається разом; тести обмежено умовою KSHANA_EGM2008_GFC). propagator::FieldEvaluator вибирає її в додатковому (opt-in) Geopotential. Збігається з Orekit 12,2 до 7.3e-17 м/с² до ступеня 2190, а орбіта 200×200 тривалістю 24 h збігається до 0,13 м. MODELLED: pyshtools не досяг попередньо зареєстрованого порогу поблизу полюса (причину простежено до pyshtools), і контроль чутливості орбіти до ступеня 70 не досяг порогу (0,73 м < 1 м); обидва випадки зафіксовано в xval/.

• Інтегратор DOP853 (FUT-11). integrator::integrate_dop853, integrate_dop853_checked, integrate_dop853_dense (щільний вивід 7-го порядку), dop853_step, dop853_initial_step, із захистом кроку, що за збою закриває доступ; propagator::Integrator::Dop853, propagate_dop853, propagate_dop853_checked. Типовий драйвер не змінено. VALIDATED за SciPy 1.18.1 solve_ivp(method="DOP853"): окремі кроки в межах 5.6e-15, збіг послідовностей кроків, кінцеві стани в межах 1.6e-12 (xval/dop853-scipy/).

• Надійний розв'язувач Кеплера (FUT-12). Новий модуль kepler: solve_kepler_markley (початкове наближення Маркле 1995, нев'язка без скорочення) для всіх 0 ≤ e < 1, обгорнутий у propagator::solve_kepler_robust. VALIDATED за коренями mpmath з 50 розрядами до 0,9 ε·|E| до e = 0,999999 (xval/kepler-mpmath/).

• Додаткова (opt-in) тесеральна гравітація Землі в пропагаторі Коуелла (RM-09). propagator::ForceModel отримує geopotential: Option<Geopotential> (with_geopotential, with_egm2008(nmax)). Він обчислює SphericalHarmonicField (вбудована EGM2008 до ступеня/порядку 70 або будь-який файл ICGEM .gfc) у земній системі координат, до якої переходять через кут обертання Землі (EarthFixedFrame::Era) або ланцюжок CIO GCRS–ITRS (EarthFixedFrame::Cio). Типово None: жоден наявний вивід не змінюється. VALIDATED за Holmes–Featherstone в Orekit 12,2 упродовж 24 h (6 випадків, найгірше 0,036 м), з порогами, попередньо зареєстрованими в xval/cowell-tesseral-orekit/PREREGISTRATION.md.

• Двочастинні юліанські дати через обертання Землі на шляху орбіти: jd2::gmst82, cio::gcrs_to_itrs_matrix_jd2, frames::teme_to_itrf_jd2 / itrf_to_teme_jd2, orbit::Propagator::position_in_frame_jd2 і own_jd2_utc, перетворення From між jd2::Jd2 і timescales::TwoPartJd, а також додатковий (opt-in) two_part_jd = true для сценарію ephemeris (ECEF, траса на поверхні та вигляд зі станції; типово вимкнено й без змін, а ключ не входить до хешу сценарію, коли вимкнено). Новий рядок реєстру, VALIDATED за pyerfa gmst82/c2t06a (попередня реєстрація b10475ee; 40 дат: GMST побітово ідентичний, матриця в межах 2.7e-14, обертання на кроках 1 мкс у межах 1.1e-14 рад, чого шлях з одним f64 не досягає). Епоха силової моделі Коуелла залишається з одним f64; причину наведено в її документації.

• Прогноз EOP за межами таблиці (EopSeries::with_ls_ar_prediction, EopSeries::last_mjd): додаткове (opt-in) продовження ряду орієнтації Землі IERS предиктором LS+AR, виданим за його останнім рядком, так що аргументи системи координат для пізнішої епохи йдуть за прогнозом, а не фіксуються на останньому рядку. Відповіді в межах таблиці побітово ідентичні (перевірено тестом); ряд і далі фіксується на останньому рядку, доки це не викликати. Точність прогнозу залишається наявним висновком щодо LS+AR порівняно з Bulletin A (MODELLED).

• Зсуви небесного полюса dX, dY на ланцюжку CIO (cio::gcrs_to_cirs_matrix_with_offsets), а також прямі перевірки векторів ERFA для precession_matrix, teme_to_gcrs_matrix і нової функції. Новий рядок реєстру, VALIDATED за pyerfa (попередня реєстрація 979c1e39; 40 епох 1950–2100: прецесія та CIO побітово ідентичні, TEME→GCRS у межах 1.1e-10 рад, що є передбаченим наслідком двочленного ряду рівняння рівнодення). Наявні функції не змінено.

• UTC до 1972 року на двочастинному часовому шляху (timescales::tai_minus_utc_on_date, а також Jd2::from_utc_calendar, jd2::utc_to_tai і jd2::tai_to_utc з 1960-01-01): епоха змінної швидкості («гумова секунда»), з таблицею дрейфу SOFA, дробовими кроками наприкінці доби та масштабуванням дробу доби з UTC до SI. Новий рядок реєстру, VALIDATED за pyerfa dtf2d/utctai/taiutc (попередня реєстрація 23c40661; 117 моментів 1960–1971, найгірше 2.9e-11 с проти порогу 1 мкс). Кожен результат після 1972 побітово ідентичний (контрольну суму зафіксовано до зміни). До 1960 TAI − UTC дорівнює 0, як у SOFA. timescales::tai_minus_utc з одним f64 не змінено.

• Бортовий годинник супутника ГЛОНАСС у навігаційному повідомленні (GlonassEphemeris::sv_clock_bias_s): −τn + γn·(t − tb) із запису RINEX, за часом, зчитаним за годинником супутника (дві ітерації з фіксованою комою, конвенція RTKLIB). Розібрані −τn і γn раніше не використовувалися. Новий рядок реєстру «Бортовий годинник супутника ГЛОНАСС і поширення бортової орбіти», VALIDATED за RTKLIB 2.4.2-p13 geph2clk/geph2pos (попередня реєстрація e099c42a; 292 випадки на реальному бортовому файлі за 2013 рік: різниця годинника 0 с, найгірше положення 1,1 мм проти порогу 1 см). Функція бібліотеки; жоден вивід сценаріїв не змінюється. Перетворення PZ-90.11 → ITRF не застосовується, і модуль прямо про це каже.

• Розв'язок часу за PPP порівняно з годинником станції IGS (0,36, FUT-19): годинник приймача плаваючого фільтра PPP на WTZR збігається з фінальним комбінованим годинником IGS для станції до 0,075 нс (стандартне відхилення) зі сталим зсувом −0,66 нс упродовж двох годин після збіжності. Пороги попередньо зареєстровано в xval/ppp-time/. VALIDATED (новий рядок реєстру). Нова фікстура igs_2025055_WTZR_05m_0006.clk: записи годинників станцій із фінального файлу годинників IGS, який уже використовується для годинників супутників.

• Паритет PPP із gLAB (0,36, WP-07, RM-31): gLAB 6.0.0 запущено на тих самих вхідних даних WTZR як окремий інструмент (ядро Apache-2.0; контрольну суму завантаження звірено з опублікованим списком), з командним рядком процедурної поправки, зафіксованої до запуску. У першому зареєстрованому запуску плаваючий PPP Kshana та gLAB збігаються в межах 0,05 м на 240 із 240 епох і до 5,0 мм на останній. Поріг SPP не досягнуто (медіана 1,187 м проти 0,50 м), і це зафіксовано як висновок: власні розв'язки SPP у gLAB і RTKLIB відрізняються одне від одного на 0,852 м. Тому зареєстроване правило залишає ланки обох інструментів загалом не виконаними, тоді як паритет PPP зберігається.

• Зчитування навігаційних даних RINEX 4 (0,36, WP-07, PRO-41): rinex::parse_nav зчитує навігаційні файли RINEX 4.00-4.02 (> EPH GPS LNAV, Galileo I/NAV і F/NAV, BeiDou D1/D2, QZSS LNAV; інші записи пропускаються до наступного заголовка запису), а parse_nav_with приймає параметри. VALIDATED за об'єднаним файлом IGS RINEX 3 того самого дня: кожне декодоване поле ідентичне, а положення розходиться на 0 м. Зчитування RINEX 2/3 не змінено.

• Бортові положення GEO BeiDou (opt-in): NavParseOptions::include_beidou_geo і RinexEphemeris::sv_position_ecef_bds_geo (BDS ICD, нахил −5 град). parse_nav і далі пропускає GEO. MODELLED: попередньо зареєстроване порівняння з точною орбітою залежить від даних і ще не виконувалося.

• Файли спостережень RINEX 4: у тестах зчитується реальний файл спостережень RINEX 4,00 MGEX (MODELLED, відповідність формату).

• RTK із LAMBDA на реальному RINEX (0,36, WP-07 ★): rtk_real::run_rtk, подвійні різниці на короткій базі за двочастотним кодом і фазою GPS із плаваючим фільтром Калмана та фіксацією цілих чисел LAMBDA (тест відношення). VALIDATED на станціях IGS WTZR і WTZZ (1,4 м одна від одної) за їхньою базою ITRF2020 за попередньо зареєстрованими порогами: фіксовано в кожну епоху після перших десяти хвилин, медіана похибки бази 4,5 мм і 95-й процентиль 5,5 мм.

• Паритет PPP на реальних даних із RTKLIB (RM-31): xval/ppp-parity/run.sh і tests/ppp_parity_glab_rtklib.rs із попередньо зареєстрованими порогами. PPP RTKLIB v2.4.2-p13 на тих самих вхідних даних WTZR збігається з Kshana в межах 5 см у кожну епоху останніх двох годин (9,7 мм наприкінці) за третьою реєстрацією; перші два запуски, зафіксовані як висновки, мали вимкнений твердий приплив і антену приймача на базовому слоті RTKLIB. Поріг паритету одиночного положення не досягнуто (медіана 1,09 м проти 0,5 м). Ланку gLAB не запущено (залежить від даних).

• Кодувальники навігаційних повідомлень, окрім LNAV (0,36, WP-07, PRO-40): gnss_navmsg кодує GPS CNAV (типи повідомлень 10, 11, 30; CRC-24Q; неперервне кодування зі швидкістю 1/2 і K=7), Galileo I/NAV (типи слів 1-5 у парних/непарних номінальних сторінках; перемежувач 30x8; синхронізація 0101100000) і Galileo F/NAV (типи сторінок 1-4; перемежувач 61x8; синхронізація 101101110000) із тестовими декодерами. MODELLED: цикли кодування-декодування та відомі відповіді з ICD; попередньо зареєстрована перевірка того, що бортові ефемериди Galileo лежать на сітці молодшого розряду кодувальника, виконалася (найгірше 3.6e-3 молодшого розряду), але не досягла порогу за кількістю супутників (15 із 20), що зафіксовано. Кодувальники є функціями бібліотеки; підключення до сцени не входить до цієї зміни.

• Зчитувач файлів IONEX (0,36, WP-07): ionex::parse_ionex_file з IonexFile, IonexHeader, IonexEpoch, IonexFileMap і IonexTimeInterp: строгий зчитувач IONEX 1,0 з фіксованими стовпцями, з епохами, відрахованими від дня першої карти, значенням 9999 як відсутнім, картами RMS і найближчою, послідовною та поворотною інтерполяціями карт за часом, передбаченими форматом; похилий TEC на висоті оболонки із заголовка. Перевірено на закоміченій синтетичній карті та, залежно від даних (завантажується під час тесту із закріпленим SHA-256, не постачається разом), на фрагменті реальної GIM від CODE: кожен вузол точний; інтерполяція збігається з еталоном за формулою до 4e-13 TECU. iontec RTKLIB збігається до 3.6e-13 TECU у 6885 точках (попередня реєстрація B6). VALIDATED на доказах, що залежать від даних (рішення власника, 2026-10-13): тест завершується невдачею на будь-якій карті, окрім закріпленої за SHA.

• Згладжування за несівною за Хетчем (0,36, WP-07): hatch::HatchFilter і pvt::assemble_epoch_precise_smoothed, форма без розбіжності (без іоносфери) у прецизійному складанні одиночного положення. MODELLED із зафіксованим висновком: на станції IGS WTZR вона знижує медіану похибки одиночного положення з 1,55 м до 1,12 м, а 95-й процентиль з 3,47 м до 3,21 м, що менше за попередньо зареєстроване зниження на 40 % (решта похибки має характер зміщення, а не шуму).

• Плаваючий PPP на реальному RINEX (0,36, WP-07): ppp_real::run_ppp, статичний плаваючий фільтр прецизійного точкового позиціонування на реальних двочастотних коді та фазі GPS із фінальними продуктами IGS (зсуви та варіації антени, твердий приплив Землі, закрутка фази, затримка Шапіро, оцінювана волога затримка, виявлення стрибків циклів), із parse_antex_receiver. VALIDATED на відкладеній станції IGS WTZR за її координатою ITRF2020 за попередньо зареєстрованими порогами: після 6 h похибка становить 1,5 мм по горизонталі та 2,9 см по вертикалі, а кожна епоха останніх двох годин лежить у межах 10 см.

• Інтерполяція прецизійного годинника SP3 (0,36, WP-07): Sp3File::clock_s і clock_nodes лінійно інтерполюють табульовані годинники супутників SP3 між двома суміжними чинними вузлами (маркер неякісного годинника пропускається), а ClockRinex::from_sp3 передає їх у PreciseProducts, тож прецизійний ланцюжок працює лише з SP3. VALIDATED за фінальними годинниками IGS з кроком 30 с за 2025-02-24 за попередньо зареєстрованими порогами: 32 супутники GPS, RMS у середній точці 0,121 нс (поріг 0,15 нс), 95-й процентиль 0,265 нс (поріг 0,30 нс).

• RAIM поряд із показниками якості утримання часу годинником (CAP-05b): додатковий (opt-in) розділ [integrity] у різновиді годинника повідомляє окремий блок integrity_fom (RAIM за знімком на заданому небі із заданого місця: вердикт для кожної епохи та рівні захисту, доступність; недоступно, поки ГНСС (GNSS) заблоковано, ніколи не екстраполюється). Показники holdover не змінено; без цього розділу вивід побітово ідентичний. MODELLED.

• Пороги довіри до приймача, відкалібровані на JammerTest 2024 (CAP-13): попередньо зареєстроване калібрування моніторів падіння C/N0, AGC та індикатора глушіння на публічному наборі даних JammerTest 2024 (завантажується під час запуску, ніколи не постачається разом; examples/jammertest_trust_calibration.rs), що постачається лише як додатковий (opt-in) [monitors] profile = "jammertest-2024-calibrated" (1,5 дБ, 3,5 сигми, 29). Відкладена вибірка: пороги AGC, індикатора глушіння та їх об'єднання проходять; поріг хибних тривог C/N0 не проходить (0,023 проти 0,02), тому рядок MODELLED (xval/jammertest-trust/RESULTS.md). Типові налаштування та вивід без профілю не змінено.

• Гіпотези збоїв ARAIM для кількох супутників (CAP-05a): правило підмножин ADD v4.2, узагальнене за межі пар (add_v42_subset_plan, add_v42_protection_levels_to_order; порядок 2 є точно наявним шляхом, перевіреним MAAST), і додатковий (opt-in) розширений RAIM за цими гіпотезами (araim_subset_raim), який у разі виявлення збою повідомляє підмножину найбільшого розділення. Апріорні значення, що потребують глибших підмножин, відхиляються, ніколи не усікаються. MODELLED.

• Лінія горизонту в довірі до приймача (FUT-01): сеанс довіри до приймача може задати [skyline]; супутники за нею втрачаються для неба (sky-blocked, behind_skyline, open_fraction), а їхні втрати класифікуються як geometry, ніколи як environment; без неї запасний варіант за розривом азимуту та кожен вивід лишаються як раніше. Генератор навчання екіпажів отримує подію natural-degradation (затулене небо, а не завади) і сценарій scenarios/training/fjord-natural-degradation.toml. Монте-Карло UERE x DOP отримує дві геометрії із затуленою лінією горизонту з проєктної примітки, попередньо зареєстровані окремо: усі 26 перевірок проходять.

• Перевірка позначок часу RFC 3161 (CAP-14): kshana::evidence::tsa::verify_token перевіряє підпис токена позначки часу (RSA PKCS#1 v1.5, RSA-PSS, ECDSA P-256 і P-384), прив'язку сертифіката підписувача ESS, призначення timeStamping підписувача та його ланцюжок до довіреного якоря на genTime токена, автономно; kshana evidence verify --tsa-ca <anchors.pem> застосовує це до timestamp.tsr пакета (opt-in; без нього звіт не змінюється). VALIDATED, вузько: усі 27 самостійно згенерованих випадків збігаються з OpenSSL 3.0.13 щодо вердикту та genTime, за порівнянням, попередньо зареєстрованим до написання верифікатора. Відкликання не перевіряється.

• Рівні верифікації за показниками для кожного різновиду (RM-04): результат кожного різновиду сценарію тепер завершується блоком figure_tiers, що називає його головні показники, рядок матриці верифікації, якому належить кожен із них, і рівень, прочитаний із цього рядка (показники, яких жоден рядок не охоплює, перелічено як без рівня). Блок додається після прогону й відкидається назад до попереднього документа байт у байт (api::without_figure_tiers). У lunar-station-coverage немає figure_tiers, доки нове датоване прогнозування не замінить заморожене; leo-ppp, solar-system, sweep і sweep-nd не мають скалярного головного показника, а lunar-attack-surface записує компактний JSON. Члени кампаній зберігають свої документи без рівнів.

• Квантовий пресет quantum-cai-coast (CAP-08c): вбудований інерціальний сценарій, у якому акселерометр на основі інтерферометра з холодних атомів, заданий фізикою інтерферометра ([accel_quantum.cai] із заданим рівнем вібрації платформи), рухається за інерцією поряд із кварцовим акселерометром навігаційного класу під час 110-хвилинної перерви в роботі GNSS. MODELLED.

• Точне число еквівалентних ступенів вільності за Greenhall (CAP-03): allan::edf_greenhall, повний алгоритм Greenhall і Riley (2003) (порядки різниць від 1 до 3, показники шуму від +2 до -4, з перекриттям і без нього, модифікований і немодифікований, із таблицями для великих J) з обгортками ADEV, MDEV і HDEV. VALIDATED за попередньо зареєстрованим порівнянням з allantools 2024,6: 4 876 вузлів сітки в межах 6.0e-13 відносно; allantools дає збій ще у 32 точках, які записано без значення оракула. Довірчі інтервали assurance::uncertainty не змінилися жодним бітом.

• Складові похибки інтерферометра з холодних атомів (RM-26/27/28): фазовий шум рамановського лазера (із членом затримки ретровідбиття), зміщення через кривину хвильового фронту теплової хмари (чистий дефокус із радіусом виявлення) та розв'язання неоднозначності інтерференційної картини (з класичною підтримкою та за двох часів опитування) як бібліотечні функції в src/inertial/cai_error_terms.rs, кожна замкнена формула перевірена квадратурою або методом Монте-Карло. MODELLED; поки що недосяжно зі сценарію через вид (kind) (docs/QUANTUM-MODELS.md).

• Формати журналів годинника (RM-03): src/clock_log.rs читає файли годинника RINEX, ASCII-журнали фази або частоти у стилі TimeLab і журнали лічильника TAPR TICC в один нормалізований ряд фази (tau0 задано або знайдено, пропуски пораховано, політика щодо пропусків). Вмикається за бажанням: ряд телекомунікаційної синхронізації може назвати журнал ([series.clock_log]), а таблиця [clock_log] сценарію годинника додає блок measured (ADEV, TDEV, MTIE). Без цієї таблиці обидва види побайтово ідентичні (docs/CLOCK-LOG-FORMATS.md). Попередньо зареєстроване порівняння на трьох синтетичних журналах виконало пороги щодо фази та підключення; оцінювачі узгоджуються з allantools у межах 2.5e-14 там, де він обчислює, і він не обчислює точку MTIE для всього запису (зафіксовано). MODELLED.

• Маски дрейфу частотної синхронізації (RM-01): вид telecom-timing отримує сім масок генерації дрейфу MTIE і TDEV за сталої температури: ITU-T G.811 PRC, G.812 типів I–III, G.8262 EEC варіантів 1 і 2 та G.8262.1 eEEC, зі степеневими ділянками, які записують таблиці, а також еталонний сценарій scenarios/telecom-synce-eec.toml (вільний OCXO проти масок EEC: він не проходить на 1 000 с, де роботу має виконати контур). Кожен рядок перечитано за текстом на itu.int; G.812 (06/2004) замінено попередньо опублікованою редакцією 08/2026, яку прочитати не вдалося. MODELLED (транскрипція); наявні маски та вихідні дані не змінилися.

• Настанова щодо апріорного фільтра для виду gnss-ins (0,36, WP-09, висновок RM-21): типовий апріорний фільтр пакета підходить для IMU тактичного класу. З IMU навігаційного класу типове значення може погіршити злитий рух за інерцією порівняно з вільною INS: 52 м проти 11 м на профілі літака зі швидкістю 70 м/с. Задайте [imu_*.filter_prior] відповідно до класу датчика, як це зроблено в нових морському, залізничному й авіаційному пакетах. Жоден вбудований сценарій не поєднує IMU навігаційного класу з типовим апріорним фільтром: кожен, що використовує типове значення, має залишкові зміщення акселерометрів щонайменше 0,015 м/с². Лише документація; вихідні дані не змінюються.

• Експорт для випробувального стенда, перевірений власними зчитувачами симулятора (0,36, WP-09, CAP-16): файли руху kshana bench-export для 8 вбудованих сценаріїв зчитано назад зчитувачами NMEA, широти/довготи/висоти та руху в земній системі координат із gps-sdr-sim (MIT, коміт 28ca29a6, використано як окремий інструмент через xval/testbench-gpssdrsim/; жодну сигнальну функцію не викликано). Вони повертають експортовану траєкторію з точністю 1,2 мм, 0,15 мм і точно. ВИСНОВОК: зчитувач руху в земній системі координат цього симулятора не може прийняти повний CSV, бо його 100-символьний рядковий буфер розрізає кожен рядок. docs/TEST-BENCH.md тепер подає межі стовпців, які слід використовувати, і обмеження симулятора в 300 с. VALIDATED (новий рядок реєстру); байти експорту не змінилися.

• GNSS/INS на наборі даних KF-GINS (0,36, WP-09, FUT-17): завантажувачі та виконавець fusion::kfgins і модель вимірювання з важелем у замкненому EKF. На демонстраційному наборі даних KF-GINS (завантажується під час тестування, не входить до репозиторію) горизонтальна RMS Kshana відносно еталонної траєкторії становить 1,09 см проти власних 1,11 см у KF-GINS, і кожен попередньо зареєстрований поріг дотримано. VALIDATED на доказах, обмежених даними (рішення власника, 2026-10-13): набір даних завантажується із закріпленими SHA-256, а шлях відтворення міститься в xval/kfgins/PREREGISTRATION.md.

• Зв'язаний фільтр PNT у пакеті злиття (0,36, WP-09, FUT-16): вид fusion приймає необов'язкову таблицю [coupled], яка запускає один складений фільтр за псевдодальностями зі станом зміщення акселерометра (fusion::coupled::CoupledPntBiasFilter), а fusion::coupled::CoupledPnt3d є 3-D версією з 8 станами. Новий вбудований сценарій fusion-pnt-coupled: за зміщених акселерометрів зв'язаний режим утримує позицію квантового набору в межах 18,7 м (95-й процентиль) із повною цілісністю, тоді як розв'язані фільтри досягають 430 м. Без таблиці і fusion, і hybrid не змінюються (закріплено); hybrid відхиляє таблицю. MODELLED.

• Морський, залізничний та авіаційний пакети GNSS/INS (0,36, WP-09, RM-21): вбудовані сценарії gnss-ins-maritime, gnss-ins-rail і gnss-ins-aviation на бібліотеці траєкторій та необов'язкова таблиця [tight] для виду gnss-ins, що зливає псевдодальності від орбітального угруповання Walker за SGP4 (усі супутники за номінального стану, кілька найвищих у разі погіршення). На залізничному пакеті щільне зв'язування утримує розв'язок навігаційного класу на рівні 5,3 м у виїмці й тунелі проти 12,9 м за слабкого зв'язування. Без [tight] пакет не змінюється (закріплено). MODELLED.

• Щільне зв'язування за фазою несівної (0,36, WP-09, RM-25 / FUT-17): fusion::carrier_tc, EKF у просторі станів похибок із явним двостановим годинником приймача та плаваючими неоднозначностями несівної, що живиться від орбітального угруповання Walker за SGP4 з поправками Klobuchar і Saastamoinen у контурі вимірювань, виявленням проковзувань за різницею несівної в часі та повторною ініціалізацією неоднозначностей, а також прогоном лише за кодом на тих самих вимірюваннях для порівняння. MODELLED: під час руху за фігурою 8 розв'язок за несівною становить 2,5 см проти 47 см лише за кодом, а NIS/NEES узгоджені за різних зерен (seed).

• Бібліотека траєкторій GNSS/INS (0,36, WP-09, RM-24): вид gnss-ins приймає необов'язкову таблицю [trajectory] із profile = "straight" | "figure8" | "stop_go" | "aircraft" | "uas" | "csv". Профілі задають кутові швидкості Ейлера та прискорення вздовж траєкторії за істинним станом і виводять істинні дані IMU з кінематики твердого тіла (узгоджені повороти, набір висоти, Коріоліс); csv імпортує істинну траєкторію (t, lat, lon, alt, vn, ve, vd, roll, pitch, yaw) і розв'язує IMU, що її відтворює. Без таблиці пакет виконує свій історичний проїзд біт у біт (закріплено). MODELLED.

• Плитки DEM за широтою/довготою для місячного горизонту: [terrain] dem_tile_path читає текстову плитку realdata::lola_dem (висоти над середньою сферою на сітці широти/довготи) замість полярної стереографічної dem_path, для обох видів lunar-station-coverage і moonlight-service-volume; звіт повторює плитку (terrain.dem_tile, з її SHA-256). realdata::lola_dem тепер підключено до прорахунку променя горизонту. Плитка, перевибрана з вбудованої вирізки, дає станції горизонт вирізки з точністю 0,22 град. MODELLED.

• Рельєф на майданчику експорту обсягу обслуговування: за наявності розділу terrain кожен рядок експорту геометрії moonlight-service-volume для кожного супутника містить clears_terrain (супутник вище за плоску маску та горизонт майданчика експорту в його азимуті), звіт містить горизонт майданчика (export_site_terrain), а CSV часу виконання отримує цей стовпець. Без рельєфу експорт не змінюється. MODELLED.

• Заголовкові поля від рушія (0,36, STUDIO-06): kshana::api::HEADLINE_FIELDS, field_importance_json() і field_importance() для WebAssembly вказують для дванадцяти видів, які поля сценарію відповідають на його запитання, найкращі першими, у вигляді шляхів через крапку (jammers[].eirp_dbw). Studio читає їх перед власним ранжуванням. Лише метадані для показу: рушій їх ніколи не читає, жоден файл сценарію їх не потребує, жоден результат від них не залежить. tests/field_importance.rs зазнає невдачі, якщо вид не можна диспетчеризувати або шляху немає в жодному з вбудованих сценаріїв цього виду (він виявив два шляхи, які сплощені ідентифікатори Studio записали без дужок масиву).

• Таблиця відповідності видів і модулів від рушія (0,36, STUDIO-05): kshana::api::KIND_MODULES, kind_modules_json() і kind_modules() для WebAssembly вказують для кожного виду сценарію, рядки матриці верифікації якого називають інший модуль, ніж власний, назви модулів. Карта можливостей Studio використовувала власну копію, написану вручну; tests/kind_modules.rs зазнає невдачі, якщо вид у таблиці не можна диспетчеризувати або модуль не фігурує в жодному рядку матриці. Вихідні дані не змінилися.

• Короткий прогін IQ у збірці для браузера (0,36): iq_signals() і iq_run_short(fs_hz, duration_s, signal, ids, dopplers_hz, cn0_dbhz, seed) у модулі WebAssembly будують синтетичну сцену, захоплюють кожен супутник і супроводжують захоплені, усе в пам'яті, з обмеженнями 0,25 с, 1 000 000 відліків і 8 супутників. Побудовник сцени та пошук сигналу за назвою перенесено з iq::cli, доступного лише в нативній збірці (до iq::scene::synthetic і iq::signals::by_name), щоб обидві збірки спільно їх використовували; вихідні дані командного рядка не змінилися. Нативний тест і web/smoke.mjs порівнюють той самий запит з одним еталоном (tests/fixtures/iq_short_golden.json) байт у байт: відтоді як змінено переносну математику (STUDIO-15, нижче), збірка для браузера та нативна збірка дають однакові біти.

• Типізовані API для Python і TypeScript (CAP-34): kshana.pyi типізує закриті словники (ScenarioKind, кожна назва виду; ErrorKind; ProvenanceClass) та словники KindMeta і FieldUnit; scenario_kinds() і error_kind() повертають їх. Пакет WebAssembly додає run_typed (один прогін як типізований об'єкт RunOutput з розібраним документом у data) і scenario_kinds (розібраний KindMeta[]), а його kshana.d.ts містить той самий словник; error_kind має тип ErrorKind | "". tests/typed_api_sync.rs підтримує обидва списки рівними спискам рушія.

• Одиниці для кожного стовпця sweep-nd (FUT-28): результат sweep-nd тепер містить key_units і metric_units, одиницю кожного перебираного ключа та кожної записаної метрики, прочитану з власної таблиці одиниць перебираного пакета. Вісь може оголосити unit для ключа, якого пакет не повторює; оголошену одиницю, що суперечить одиниці пакета, відхиляють, а одиниця, якої не дає жодна зі сторін, є null і ніколи не вгадується. points[].coords[] і points[].metrics[] описано, тож кожен із 76 видів тепер повністю охоплений перевіркою одиниць полів (стеля неохоплених видів 1 -> 0).

• Масиви NumPy з RunOutput (FUT-26): RunOutput у Python отримує array(path), columns(path) і series(), які повертають numpy.ndarray для числового списку, числових стовпців списку записів або кожного ряду записів у документі. Кожен масив дорівнює numpy.asarray тих самих значень із data() (dtype і біти). NumPy імпортується лише тоді, коли викликають одну з них, і не входить до вимог середовища виконання. Типізовано в kshana.pyi і перевірено stubtest.

• Оптимізатор кампаній (CAP-32): новий необов'язковий розділ [optimize] виду campaign шукає від одного до трьох ключів сценарію в заданих межах найкраще значення однієї метрики: мінімізувати, максимізувати або досягти цілі. Він шукає вичерпно на сітці або детермінованим обмеженим симплексом Нелдера–Міда. Кожне обчислення є справжнім прогоном названого виду і наведене в trace результату. Приклад: scenarios/campaign-optimize-link-budget.toml. Пороги було зареєстровано заздалегідь (docs/design/evidence/cap32-optimize/):

  • функцію Розенброка виконано (f* = 1.7e-20);
  • розв'язок 1-D цілі в замкненій формі виконано (6e-15 відносно);
  • сітка побітово дорівнює незалежному повному перебору;
  • симплекс дає не гірший результат, ніж сітка 41 × 41, за 177 прогонів.

  1-D поріг раунду 1 записано як NOT MET, бо попередньо зареєстрований бокс виключав розв'язок. MODELLED; рядок реєстру «Bounded optimisation of one metric over campaign parameters». Додаткова функція: кампанії без цього розділу не змінюються.

• Ансамблі калібрування (CAP-10): три одноразові перевірки з одним зерном, повторені на 200 незалежних зернах проти попередньо зареєстрованих порогів, у docs/CALIBRATION-ENSEMBLES.md (згенеровано gen_calibration_ensembles; значення для кожного зерна в docs/data/calibration-ensembles.csv).

  • 95-відсотковий інтервал бутстрепа Монте-Карло кампанії накриває істинне середнє у 192 із 200 ансамблів, а його перевірка хі-квадрат проходить у 196.
  • Допуск перцентиля за одного зерна проходить лише у 183 із 200: NOT MET, як і передбачалося. Це поріг приблизно у 2 сигма, зафіксований і не послаблений.
  • Калібрування ADEV для білого FM проходять на кожному зерні, а їхня найгірша похибка далеко в межах допуску.

  MODELLED.

• Вбудовані види через трейт Scenario (FUT-27, виконується): трейт BuiltinKind (api::BuiltinKind, з гачком рівня доказів для кожного показника та append_figure_tiers) і перші види, перенесені на нього (inertial, spoof, passes, link-budget, jamming). Вихідні дані не змінилися: маніфест усього каталогу із SHA-256 кожного виходу однаковий до і після (tests/scenario_output_manifest.rs).

• Перевірка відсутності завантажень у Playground (RM-07): tests/playground_no_fetch.rs перевіряє три речі:

  • кожен сценарій бібліотеки Studio є в пакеті для браузера;
  • пакет побайтово ідентичний scenarios/;
  • кожен сценарій браузера запускається з порожнього робочого каталогу.

• Карти Alt-PNT: реальне гравітаційне поле, Монте-Карло похибки карти, SRTM повної роздільності (0,36, WP-10). Вид gravity-map приймає необов'язкову [reference]: гравітаційну аномалію, синтезовану з вбудованих коефіцієнтів EGM2008 (або з файла ICGEM .gfc через gfc_path, лише нативні збірки). Цей синтез збігається зі службою обчислень ICGEM приблизно до 1e-8 мГал на 794 вузлах у двох регіонах, за попередньо зареєстрованих порогів 0,005 мГал RMS і 0,02 мГал максимум (VALIDATED; рядок реєстру «Gravity-anomaly synthesis from a spherical-harmonic model»). Новий вбудований сценарій gps-denied-gravity-nav-egm2008 виконує 60-хвилинний бенчмарк на цьому реальному полі ступеня 70. Попередньо зареєстрований результат: похибка зіставлення 3106 м, тож поріг < 500 м NOT MET, як і передбачалося (ступінь 70 надто згладжений), а десятикратне зменшення дрейфу MET (MODELLED). Необов'язкова [map_error_mc] повторно запускає бенчмарк на згенерованих із зерна гауссівсько корельованих похибках карти і звітує розподіл похибки зіставлення (вбудований сценарій gravity-map-error-mc). Пошукове й не зареєстроване заздалегідь: за похибки карти 2 мГал, корельованої на 0,2 град (розмір, який закладає власна сигма зіставлювача), 1 із 20 реалізацій залишається в межах 500 м (медіана 2,9 км, p95 14,7 км) проти 144 м за ідеальної карти. Результат синтетичного бенчмарка менше 500 м припускає, що карта точна. Без жодного з цих параметрів документ побайтово ідентичний попереднім випускам. combined-altpnt приймає необов'язкову [magnetic_grid] (csv_path, column), що читає магнітний канал із CSV у форматі EMAG2v3. EMAG2 не входить до репозиторію, бо його умови не є явними: tools/fetch_emag2_tile.py завантажує його із закріпленим SHA-256 і вирізає прямокутник. Жодного навігаційного результату на реальній сітці EMAG2 не заявляється. Спільне оцінювання карти (terrain SLAM, RM-18): altpnt::sequential::run_sequential_trn_on_map пускає послідовний навігатор за рельєфом над збереженою картою, що відрізняється від істинної, або довіряючи їй, або оцінюючи поправку карти для кожної комірки фільтром Рао–Блеквелла у стилі FastSLAM. Попередньо зареєстровано проти SITAN з відомою картою за корельованої похибки карти 15 м на 20 зернах: середній виграш 1,5 %, краще в 10 із 20, тож обидва пороги покращення NOT MET (10 % і 12 із 20), без шкоди на ідеальній карті (MET). Один прохід без повернень не дозволяє вивчити карту (xval/terrain-slam-rbpf/, MODELLED). Документи terrain-slam побайтово ідентичні. Тести з реальним SRTM тепер виконуються в CI на двох закомічених вирізках повної роздільності; усі попередньо зареєстровані пороги виконано, найближчий вузол дорівнює GDAL 3.8.4 у 8 із 8 точок (xval/srtm-ungate/).

• Сумісність, WP-08 (0,36; кожен пункт зареєстровано заздалегідь і закомічено окремо до прогону оракула, кожен є новим рядком реєстру VALIDATED, окрім пункту телеметрії, який розширює наявний рядок):

  • Повідомлення CCSDS про дані орбіти (src/odm.rs): OPM 3.0/2.0, OMM 3.0/2.0 та OCM 3,0 (блоки TRAJ, PHYS, COV, MAN, USER) записуються й читаються в KVN та NDM/XML, а також повноточний OMM з набору елементів SGP4 (OmmMessage::from_omm_file); вихід OmmFile::to_omm_kvn не змінюється. Проти Orekit 13.1.8 в обидва боки: 27 із 30 повідомлень Kshana розбираються в Orekit, а Kshana читає кожне записане Orekit, значення в межах 1e-14 відносно, а епохи в межах 1e-9 с; закріплено чотири висновки (Orekit вимагає ELEMENT_SET_NO, відхиляє COMMENT в XML-параметрах, визначених користувачем, не записує BTERM без BSTAR і читає відносні епохи OCM у TDB у секундах SI). Застарілий записувач OMM META_START Orekit відхиляє (зафіксовано). Рядок «CCSDS Orbit Data Messages (OPM, OMM, OCM)».
  • Повідомлення CCSDS про дані орієнтації (src/adm.rs, src/ndm_xml.rs): AEM 2.0/1.0 та APM 2,0 у KVN і XML проти Orekit 13.1.8, кожен поріг виконано; записувач APM в Orekit відхиляє маневр без MAN_DELTA_MASS (закріплено). Рядок «CCSDS Attitude Data Messages (AEM, APM)».
  • Експорт SPICE SPK (src/spk_writer.rs): записувач і читач SPK типів 9 і 13 та експорт OEM у SPK; проти CSPICE N0067 ядра побайтово ідентичні ядрам SPICE і обчислюються бітово ідентично. Рядок «SPICE SPK export (types 9 and 13)».
  • SPICE SPK типів 3 і 21 (src/spk_writer.rs): сегменти типу 3 (Чебишов) і типу 21 (розширені лінії різниць) записуються із заданих записів і обчислюються так, як це робить SPICE; проти CSPICE N0067 ядра побайтово ідентичні ядрам SPICE, а кожне обчислення збігається біт у біт в обидва боки. Рядок «SPICE SPK types 3 and 21 (Chebyshev, extended difference lines)».
  • Розширення Space Packet (src/space_packet.rs): вторинний заголовок із часовими кодами CUC/CDS, керування помилками пакета, сегментація та перевірки потоку, проти ccsdspy 2.0.1, spacepackets-rs 0.18.0, spacepackets-py 0.32.0 і crc_hqx з CPython, нуль розбіжностей. Рядок «CCSDS Space Packet secondary header, packet error control and segmentation».
  • Схема телеметрії 1,3 через реальні споживачі: експозиція Prometheus і JSON OTLP/HTTP синтетичного потоку схеми 1.3, зокрема ряд геометрії та мітка class, точно читаються prometheus_client і OTLP proto, приймаються promtool 3.5.0 check metrics без проблем лінтингу та без змін проходять через OpenTelemetry Collector contrib 0.135.0 (обмежено даними: інструменти завантажено із закріпленим SHA-256, виходи закомічено).

• Визначення орбіти Марса, прогін 2 (0,36, WP-14, CAP-30): mars_od::fit_damped масштабує нормальну матрицю за її діагоналлю і демпфує крок (Левенберг–Марквардт) після того, як зареєстроване підігнування Гаусса–Ньютона зазнало невдачі на матриці, сира діагональ якої охоплює вісім порядків. Зареєстровано окремо (xval/mro-od/PREREGISTRATION-RUN2.md, та сама дуга, ті самі пороги та редагування). На оцінюваних проходах MRO орбіта в межах 0,36 км RMS (0,53 км максимум) від навігаційної реконструкції MRO, пороги виконано. Післяпідгінний доплер становить 48,6 мГц проти порога 30 мГц, не виконано (висновок закріплено). Поправку лише до оцінювання, R2-A1, розкрито в docs/revisions. Рядок залишається MODELLED.

• Модель 2-стороннього доплера Марса з рампою та визначення орбіти (0,36, WP-14, частина CAP-30, етап 2): mars_od передбачає 2-сторонній доплер DSN X-діапазону з рампою за таблицями рампи ODF (час світла, Шапіро, тропосфера, час станції, станції DSN через ланцюг CIO та EOP IERS) і підганяє орбітальний апарат Марса (GMM-3, треті тіла, SRP, опір). naif_kernel читає SPK типу 1 (перевірено за CSPICE), а gravity_sh::from_shadr читає поля PDS SHADR. Попередньо зареєстровано проти навігаційної реконструкції MRO на реальних проходах MRO (обмежено даними, scripts/fetch_mro_od.sh, щомісячний CI): передбачений доплер збігається зі спостереженнями до 12,5 мГц (поріг 30 мГц, виконано); зареєстроване підгінання орбіти зазнало невдачі на оцінюваній дузі й орбіти не дало (висновок закріплено). Рядок залишається MODELLED.

• Читач файлів даних орбіти DSN (0,36, WP-14, частина CAP-30): odf::parse_odf читає ODF TRK-2-18. На реальному ODF Mars Reconnaissance Orbiter (NASA PDS, у репозиторії) читач збігається з кількістю записів, положеннями груп, станціями та часами з мітки PDS, а всі його типи даних відомі. Таблиця кінця файла в мітці на один рядок коротша за файл, що зафіксовано як невідповідність мітки. MODELLED. Визначення орбіти за цими даними ще не виконано.

• Бюджет TWSTFT і стабільність передавання часу: вид time-transfer-budget (0,36, WP-14, FUT-19).

  • Двостороннє рівняння: twstft_budget розв'язує його для T_A − T_B із затримками обладнання станцій, асиметрією іоносфери Ku-діапазону вгору/вниз, різницею затримок транспондера та членами Саньяка й відновлює пряму модель з точністю 1e-15 с.
  • Бюджет невизначеності: поєднується квадратично, з TDEV лінії як складовою типу A.
  • Шум лінії: двосторонній ряд отримує нижню межу фазового фліккер-шуму, добову невзаємність і сталий залишок взаємності. Пакет timetransfer з білим джитером не змінюється.
  • Реальні ряди: стабільність наданих рядів BIPM Circular T, CSV MJD,ns або рядів годинника станцій IGS.

  MODELLED. Новий вбудований сценарій time-transfer-budget. Часовий розв'язок PPP окремо VALIDATED за годинником станції IGS на гілці реальних даних GNSS.

• Нагрівання при вході, радіометрія EO та втрати на виведенні (0,36, WP-14, CAP-28): три нові види.

  • entry-heating: 3-ступеневий вхід матеріальної точки над обертовою Землею або Марсом з нагріванням у точці гальмування за Саттоном–Грейвсом.
  • eo-radiometry: ВШ зображувача, MTF на Найквісті, відносна реакція на край і NIIRS за GIQE 4.
  • ascent-losses: багатоступеневе виведення з гравітаційним поворотом із втратами на гравітацію, опір, керування та протитиск, перевірене точною тотожністю «ідеальний dv мінус втрати».

  Пікове гальмування при вході перевірено за опублікованим номіналом Stardust за попередньо зареєстрованим порогом: 35,44 g проти 33,4 g (+6,1 %, поріг 10 %). Цей рядок VALIDATED. Нагрівання, радіометрія та виведення MODELLED. Також нове: reentry::us76_pressure, вбудовані сценарії entry-heating-stardust, eo-radiometry і ascent-losses, а також docs/ENTRY-EO-ASCENT.md.

• Керування орієнтацією за допомогою реактивних маховиків: вид aocs (0,36, WP-14, CAP-21). Інерціальний розворот із наведенням жорсткого корпусу з трьома або більше збалансованими реактивними маховиками під зворотним зв'язком MRP, з моментами маховиків мінімальної норми, обмеженими межею кожного двигуна (aocs). Він також може замкнути контур на мультиплікативному EKF за змодельованим гіроскопом і зорядним датчиком (aocs_mekf). Контур істинного стану порівняно з Basilisk 2.9.1 на трьох випадках, зареєстрованих заздалегідь до появи коду (три ортогональні маховики, чотириколісна піраміда, випадок насичення). Кожен компонент MRP, кутова швидкість корпусу, швидкість маховика й момент двигуна збіглися в кожному відліку, найгірше 2.4e-14 у сигмі та 2.9e-11 рад/с у швидкості маховика. Цей рядок VALIDATED; MEKF є MODELLED (узгодженість NEES). Нові вбудовані сценарії aocs-slew і aocs-slew-mekf, а також docs/AOCS.md.

• Планування наземних сеансів зв'язку та DVB-S2 ACM (0,36, WP-14, CAP-22/23): два нові види сценаріїв. acm-link дає для одного супутника над однією станцією Es/N0 кожного проходу та MODCOD DVB-S2, обраний вздовж нього (порогові значення за ETSI EN 302 307-1, таблиця 13, плюс запас). Він також дає обсяг даних, який ACM переміщує порівняно з базовим рівнем зі сталим кодуванням. contact-schedule робить те саме для кількох супутників над кількома станціями та будує безконфліктний план сеансів (розворот антени, одна станція на супутник, доставка зі зваженими пріоритетами, обмежена кожним накопиченням). Він звітує жадібний план із граничною цінністю, базовий план «першим прийшов» і точний оптимум на малих множинах разом із розривом оптимальності жадібного плану. Вікна доступу беруть із VALIDATED предиктора видимих проходів. Нові вбудовані сценарії acm-link і contact-schedule (ілюстративні вхідні дані) та docs/CONTACT-SCHEDULING.md. MODELLED (два нові рядки реєстру).

• Позиціонування за доплером Starlink проти опублікованого експерименту (0,36, WP-14, частина CAP-11, MODELLED). Це попередньо зареєстроване порівняння за проксі режиму доплера leo-pvt із пресетом starlink-sop з процентилями набору даних 3 із «Unveiling Starlink for PNT» (NAVIGATION 72(1), 2025, doi:10.33012/navi.685). Модель використала 3 супутники (маска 47 град, обрана за фіксованим правилом), без допомоги за висотою та з сигмою доплера 30 Гц, на 200 зернах. Її 90-й процентиль 3-D похибки становить 92,2 м за 20 с і 870 м за 8 с проти опублікованих 2 м і 10 м, тож обидва пороги в два рази NOT MET. Модель песимістична, а не оптимістична, як передбачалося: три нерухомі супутники дають значно менше геометричної різноманітності, ніж 63 супутники експерименту за 10 хвилин із перемиканням каналів кожні 15 с. Обидва промахи стверджуються у тесті (tests/starlink_doppler_published_proxy.rs).

• Оптимізатор імпульсних перельотів на DE440 (0,36, WP-14, CAP-20c/d): maneuver::optimise_transfer_kernel знаходить дати відльоту та прильоту балістичного двоімпульсного перельоту з одним витком, що мінімізують C3 відльоту або V-нескінченність прильоту в межах типу I або типу II. Він шукає на 2-денній сітці, потім уточнює методом Нелдера–Міда 2-D, за геліоцентричними станами з ядра DE440; він спирається на porkchop_kernel. Порівняння було зареєстроване заздалегідь (bf0439e8) проти незалежного оптимізатора SPICE + pykep 3.0.1 + SciPy 1.18.1 на можливості Земля–Марс 2026: усі чотири оптимізації узгоджуються до 8.7e-13 відносно, з датами в межах 1e-5 доби (VALIDATED, новий рядок реєстру). Як вторинне опубліковане джерело, NASA/TM-2010-216764 (довідник Земля–Марс на 2026-2045) збігається за мінімальним C3 типу II (9,182 проти 9,144) і за мінімальною V-нескінченністю прильоту типу II (2,564 проти 2,565). Його мінімальний C3 типу I не збігається: 10,535 проти 11,11 (-5.18 %), де бібліотечний оракул погоджується з Kshana. Цей промах зафіксовано й підтверджено тестом.

• Дослідження місячної опорної станції (0,36, за мотивами опублікованих матеріалів про заплановану місячну опорну станцію на південному полюсі; джерела в docs/LUNAR-REFERENCE-STATION.md): вид lunar-station-coverage, розгортка Монте-Карло моделі місячного диференціального PNT над південнополярною сіткою користувачів і добою епох, що дає для кожної точки та по регіону процентильну скориговану й нескориговану похибку, доступність із причинами, покриття відносно заданого порога, рівні захисту, радіус покриття за азимутом і бюджет лінії поправок. Він точно зводиться до lunar-differential-pnt в одній точці, епосі та випробуванні; його арифметику перераховано в numpy за попередньо зареєстрованим порогом (позиції та процентилі виконано; поправки станції свої пороги не виконали через округлення подвійної точності, зафіксовано). MODELLED; рядок реєстру «Lunar reference-station coverage and accuracy map». Не пов'язано з жодним агентством і не схвалено ним; жодних тверджень щодо характеристик будь-якої реальної системи.

• Попередньо зареєстрований прогноз: покриття місячної опорної станції (не валідація; MODELLED). docs/predictions/lunar-reference-station.md фіксує в коміті c05dac1d результати lunar-station-coverage за публічно заявлених припущень, із хешами SHA-256 вхідних даних і результатів та протоколом оцінювання, зафіксованим тепер (коефіцієнт 2 для точностей і рівнів захисту, 10 відсоткових пунктів для доступності та покриття; змінене припущення дістає новий датований прогноз, а не правку; промах публікується так само помітно, як і влучання). Кожна цифра визначається неопублікованим набором елементів орбітального угруповання з чотирьох супутників, який є ILLUSTRATIVE, і про це сказано. tests/prediction_frozen.rs його захищає; docs/VALIDATION.md отримує розділ «Pre-registered predictions». Рядка реєстру немає.

• Розширення місячної опорної станції (0,36; обмеження 2 і 3 дослідження станції та стиль розв'язку джерел), кожне вмикається за бажанням на lunar-station-coverage і за замовчуванням відсутнє, тож кожен наявний документ, зокрема заморожений прогноз, не змінюється: [receiver] (багатопроменевість a + b exp(-el / el0) у користувача та на станції, на станції за бажанням Гаусса–Маркова за епохами, шум коду DLL за C/N0, міжканальні зміщення; значення ILLUSTRATIVE для Місяця); orbit_err_growth_m_per_s (лінійне зростання похибки орбіти в ефірі за затримки поправок, ILLUSTRATIVE); [solution] (обмеження за висотою, мінімум із трьох супутників із ним, вікно нерухомого користувача за епохами). Два додатки до порівняння з опублікованими заявами, кожен зареєстрований заздалегідь окремо до свого прогону, лежать поруч із нередагованим записаним прогоном: K5 із зростанням не проходить за жодної швидкості; зі стилем розв'язку джерел K1–K5 не проходять, а K6 проходить (1 із 6), причому скоригована p95 3-D похибка R300 падає з 280,6 м до 2,11 м. MODELLED; три рядки реєстру.

• Маски горизонту місячного рельєфу (0,36; перше обмеження дослідження місячної опорної станції): необов'язковий розділ [terrain] у lunar-station-coverage (станція та кожна точка користувача) і moonlight-service-volume (кожна точка сітки) надає кожному майданчику азимутально залежний горизонт у форматі таблиці обрію 0,36 із заданого профілю з позначеним джерелом (station_horizon, user_horizon) та/або прорахунку променя над полярним DEM (dem_path) вздовж великих кіл місячної сфери з точною кривиною. Постачає вирізку публічного надбання з південнополярного DEM LRO LOLA LDEM_75S_240M розміром 0,98 МБ, перевибрану усередненням блоків 5 x 5 до 1200 м (data/lunar-dem/, з її NOTICE, SHA-256 та scripts/make_lola_south_polar_crop.py), і сценарій лише для репозиторію scenarios/lunar-station-coverage-terrain.toml. Перевірено за горизонтами в замкненій формі (гола сфера, кратер на плато, растеризований конус); MODELLED, рядок реєстру «Lunar terrain horizon masks from a stated profile or a polar DEM». Без розділу кожен документ, зокрема блок одиниць, побайтово ідентичний.

• Довіра з урахуванням геометрії (примітка до проєкту геометрії 0,36, розділ 4). Кожна епоха receiver-trust, статична чи судна, пакетна чи жива, несе геометрію своїх супутників: good, degraded (причини few-satellites, high-pdop, high-hdop та інформаційна sky-blocked) або unknown, де журнал не дає геометрії супутників, із HDOP, PDOP, VDOP і використаними супутниками. Її виводять із висот і азимутів, які повідомляє приймач (NMEA GSV, UBX NAV-SAT), через наявне ядро orbit::dop або беруть з NMEA GSA. Кожна епоха також несе позначку good, fair або poor, що завжди звітується і ніколи не оцінюється, та примітку з HDOP, PDOP, VDOP, кількістю супутників і втратою сигналу словами. Оцінка судна отримує монітор geometry, який нічого не віднімає, доки геометрія не погана (HDOP понад 4, PDOP понад 6 або менше 5 використаних супутників), після чого наростає до межі в 15 пунктів; сама геометрія сягає щонайбільше погіршеної смуги, ніколи не смуги недовіри (без тривоги). Кожне зменшення дістає клас geometry, environment або inconsistency, щоб погане небо не сприймалося як атака. loss-of-lock має клас geometry, коли втрачені супутники були всі нижче 15 градусів у своєму останньому повідомленні; зменшення за погану геометрію має клас inconsistency, коли HDOP, заявлений приймачем, розходиться з його заявленим небом більш ніж на max(1,0, 25 % виведеного HDOP), тож підроблене погане небо не може купити цю позначку. Нова таблиця [geometry] заявляє кожен поріг із його походженням (HDOP 4, PDOP 6, щонайменше 5 використаних, sigma_UERE 1,5 м, допуск HDOP max(1,0, 25 % виведеного HDOP), де 25 % є репрезентативним вибором для приймачів із годинниками для кожного угруповання або розв'язками за підмножинами, 15 градусів; цифри IEC 61108-1 та GPS SPS наведено як цитовані, їх слід звірити з текстом стандартів). Повна втрата сигналу не позначається як небо: коли супутники у видимості не відстежуються, а DOP супутників у видимості хороший (і невідстежувані не обмежені однією половиною горизонту), епоха несе signal_loss, а зменшення за геометрію має клас environment. Заявлені HDOP або PDOP 99 чи більше, якість GGA 0 і режим GSA 1 читаються як відсутність фіксації, а не як DOP. Межа (cap_points 15), кінець наростання (full_ratio 1,5) і нижня межа (floor, за замовчуванням degraded_min оцінки) містяться в [geometry], як і хороші рівні позначки (HDOP 2, PDOP 3, 6 супутників, репрезентативно); чинна межа дорівнює min(cap_points, 100 - floor), тож таблиця [score], що піднімає degraded_min (зокрема на 0,35), знижує межу замість відхилення, а нижню межу нижче degraded_min відхиляють. MODELLED; консультативне програмне забезпечення, не навігаційне обладнання із затвердженням типу (IEC 61108, IEC 61162): відповідальність за навігацію судна залишається на операторі.

• Геометрія доходить до кожної поверхні: JSON результату (epochs[].geometry, class на кожному зменшенні, geometry_model, geometry_summary), живі рядки JSON (схема 1,3), receiver_trust для Python і WebAssembly, assess_vessel_log і receiver_trust_replay, інструменти MCP assess_*, пакети доказів (epochs.json, config.json, доріжка геометрії на сторінці підсумку) і trust-telemetry (Prometheus kshana_trust_geometry* та мітка class на kshana_trust_reason_active, OTLP kshana.geometry.*, власні поля CEF cs6 (стан і класи геометрії), cfp3 (HDOP) і cfp4 (PDOP), перевірені обома оракульними розбирачами CEF, та LEEF geoStatus, geoHdop, geoClass). Позначка геометрії також експортується, додана після кожного попереднього ряду й поля та лише для входів, що її несуть: Prometheus kshana_trust_geometry_label{label} і kshana_trust_geometry_vdop, OTLP kshana.geometry.label і kshana.geometry.vdop, LEEF geoLabel, geoPdop, geoVdop, geoUsed, а в CEF третє поле cs6 (позначка) і cn1 (використані супутники); VDOP у CEF немає (власні поля з рухомою комою зайняті). Обидва оракульні розбирачі CEF зчитують випадки позначок так, як їх записано (поправка 5: 176 рядків, 172 розібрано pycef, 176 Logstash). HDOP, який заявлене небо не пояснює, позначається на кожній епосі та підраховується (geometry_summary.hdop_mismatch, рядок на сторінці підсумку доказів), а оцінюється лише тоді, коли геометрія погана. Втрата сигналу експортується окремо, бо поки вона триває, стан геометрії залишається degraded: Prometheus kshana_trust_geometry_signal_loss, OTLP kshana.geometry.signal_loss, LEEF geoSignalLoss=1; у CEF вона показується як клас environment у cs6.

• orbit::dop_cofactor: коваріаційний множник (HᵀH)⁻¹ за orbit::dop, виокремлений із нього тією самою арифметикою.

• Рядок реєстру «Position error from geometry: RMS error = sigma_UERE x DOP» (MODELLED, внутрішня узгодженість): Монте-Карло із зерном розв'язку найменших квадратів рушія на 8 геометріях DOP, зіставлених із gnss_lib_py, проти коваріаційного множника перевіреного ядра DOP, із допусками, зареєстрованими заздалегідь до першого прогону, і двома негативними контролями, що провалюються, як і мають; поруч із цим раніша перевірка на чотирьох підібраних вручну небосхилах з довірчими інтервалами хі-квадрат, подана як виконана до попередньої реєстрації.

• Азимутально залежні маски обрію (src/skyline.rs, docs/SKYLINE.md, пункт 1 примітки до проєкту): зріз за висотою, що залежить від азимута, поточковий максимум таблиць (кожна інтерполюється окремо, замкнена на 360°), вуличний каньйон у замкненій формі (із необов'язковими відкритими кінцями), сектори з різкими краями та профіль рельєфу з кривиною Землі; ефективний зріз дорівнює max(mask_deg, skyline). Чотири пресети REPRESENTATIVE із заявленим походженням (city-street, harbour-approach, fjord, container-terminal), які можна перевизначати поле за полем. Необов'язковий розділ [skyline] у gnss-sim, jamming, leo-pvt (кожен режим, зокрема полярна розгортка), файлах навчання leo-pass і nmea-scenario, а також в orbit та integrity через нового користувача наземного майданчика, user_site = { lat_deg, lon_deg, height_m } (геодезичні кути огляду на обертовій Землі, з геодезичним зенітом для горизонтального та вертикального розподілу ARAIM; кожен відлік є одним абсолютним моментом, epoch + t, до якого набори елементів, бортові ефемериди та файли SP3 просуваються від власних епох, датованих за найновішою епохою супутника, коли epoch не вказано; user на орбіті відхиляє skyline). Результати отримують skyline { source, open_fraction, provenance } та відліковий masked_by_skyline. Без розділу кожен сценарій побайтово ідентичний 0.35.0, перевірено за дайджестами з коміту випуску. Шість вбудованих прикладів: orbit-urban-canyon-skyline, integrity-harbour-approach, gnss-sim-container-terminal-skyline, jamming-harbour-approach-skyline, leo-pvt-fjord-skyline і кампанія leo-vertical-autonomous-vehicle-skyline (каньйон автономного транспортного засобу як плоский зріз і як вулиця; наявна кампанія не змінюється). MODELLED.

• Функції геометрії неба (src/geometry.rs, пункт 2 примітки до проєкту): sky_geometry (видимі та замасковані супутники з майданчика, моменту часу та пресетів угруповань, дворядкових наборів елементів (tle, щонайбільше 4 МіБ, поширених SGP4 рушія до UTC epoch) або заданих супутників; sky_source і sky_statement повідомляють, чи небо є репрезентативним, чи небом, яке набори елементів дають на цю епоху, а не вимірюванням; tle_skipped перелічує кожен невикористаний рядок із причиною; обмеження входу в 2000 супутників над горизонтом, перевірене до побудови системної таблиці, та 16 годинників приймача; п'ять DOP; ENU-кофактор і коваріація з одним годинником на систему або одним спільним; горизонтальний еліпс похибки на одну сигму та за заявленої довіри), sky_monte_carlo (похибки найменших квадратів із зерном, щонайбільше 5000), skyline_presets, skyline_profile і skyplot_svg. orbit::dop_cov відкриває коваріацію за orbit::dop, яка тепер є її зведенням (перевірені скаляри не змінилися). Поверхні: kshana sky і kshana skyline, функції Python і WASM з тими самими назвами та інструмент MCP sky_geometry (40 інструментів), а також ноутбук notebooks/geometry.ipynb (з дзеркалом .md; запускається tests/python/test_notebooks.py). Кожен результат несе позначку MODELLED, твердження про модель похибок і консультативну заяву.

• Реєстр: п'ять рядків про skyline і геометрію неба. VALIDATED, кожен у порівнянні, зареєстрованому заздалегідь до запуску його оракула: Azimuth-dependent skyline mask: visible set, azimuth and elevation, and DOP under the mask проти Orekit 12,2 (TopocentricFrame, ElevationMask) і gnss_lib_py 1.0.4 (get_dop), найгірші розбіжності кутів огляду та маски 1.1e-12° проти 1e-9°, ідентичні множини видимих, DOP 3.3e-13 відносно (xval/orekit-skyline/); Horizontal error ellipse and per-system cofactor from the geometry covariance проти numpy linalg.inv і linalg.eigh (стандартний P2), 270 випадків, осі 5.1e-13 відносно (xval/numpy-ellipse/). MODELLED: зведення каньйона, сектора та рельєфу; пресети; композиція геометрії неба (пресет неба, хмара Монте-Карло).

• З рядками про довіру до геометрії, skyline і місячну опорну станцію реєстр містить 274 рядків: 134 перевірених, 136 змодельованих, 4 партнерських.

• Місячна опорна станція: лабораторія часу станції (MODELLED). Необов'язковий блок [time_lab] у lunar-time-budget (src/lunar_time_lab.rs). Він моделює годинник станції (за замовчуванням клас miniRAFS, будь-який названий клас або картка пристрою, підігнана за заданими точками стабільності), підпорядкований LTC, потім вільний або повторно підпорядкований кожні N секунд. Він видає криву похибки часу x(t), час до 1, 10 і 100 нс (бісекція поруч із замкненою формою) та домінантний член для кожного горизонту, усе з одиницями. Залишок підпорядкування є ILLUSTRATIVE. Швидкість LTC не виводиться заново й зберігає власний рядок VALIDATED. Наносекундну ціль публічних матеріалів ICG WG-B з місячного PNT (червень 2024) наведено як твердження джерела, а не як заяву. Порядок годинників optical < PHM < RAFS < miniRAFS зберігається від 1 с до 7e5 с, а тест закріплює перетин кривих PHM і RAFS поблизу 7.5e5 с. Цей перетин є властивістю моделей годинників з одним типом шуму (чистий фліккер FM проти чистого білого FM), а не фізичним результатом. Без блока звіт, його таблиця та підсумок не змінюються. Приклад: scenarios/lunar-station-time-lab.toml. Додає один рядок реєстру з позначкою MODELLED.

• Місячна опорна станція: геодезія станції (MODELLED). Необов'язкові входи extra_reflectors і extra_beacons у lunar-llr-datum додають блок station_geodesy. П'ятимасивну інформацію про датум з архівного зрізу лазерної локації поєднано з тим, що внесли б доданий ретрорефлектор і доданий маяк VLBI на заданих майданчиках. Рефлектор локується в архівні епохи, коли він видимий, з їхніми архівними вагами. Маяк використовує мережу та розклад lunar-frame-campaign, зі станціями, що зафіксовані. Блок дає кожну 1-сигму Гельмерта до і після та їхнє відношення. Це межі Крамера–Рао для скороченого набору параметрів, на ILLUSTRATIVE розкладі та майданчику. Відсутні або порожні входи залишають звіт побайтово ідентичним. Приклади: scenarios/lunar-station-geodesy-baseline.toml і -with-station.toml. Додає один рядок реєстру з позначкою MODELLED.

• Місячна опорна станція: порівняння з опублікованими заявами (MODELLED). Кожну числову заяву в п'яти публічних джерелах наведено з точним формулюванням, сторінкою та заявленими припущеннями й класифіковано як порівнянну, частково порівнянну або непорівнянну (tests/fixtures/lunar_station_published/CLAIMS.md; джерела з URL, датою отримання, SHA-256 і ліцензією в tests/fixtures/lunar_station/SOURCES.md). Частково порівнянні заяви оцінено за шістьма односторонніми порогами, зареєстрованими заздалегідь до прогону (PREREGISTRATION.md, редакція 2, 05bf9a19): 1 із 6 заяв у межах попередньо зареєстрованого порога (зареєстровано заздалегідь 05bf9a19). Покриття становить 0,00 проти >= 0,95 на обох південнополярних колах, а скоригована p95 дорівнює 280,6 м проти <= 1,5 м. Причина в елементах орбіт супутників, яких не публікує жодне джерело: на ILLUSTRATIVE елементах із репозиторію чотири супутники перебувають у спільній видимості в 8 % епох, за майже сингулярної геометрії. Прогін не відтворює заяви на цих елементах і не є доказом того, що заяви хибні. Закріплено в tests/lunar_station_published_oracle.rs. Один рядок реєстру з позначкою MODELLED і висновком.

• Місячна опорна станція: готовність даних файла годинника. realdata::clk::rinex_clock_series тепер указує систему часу своїх епох. Це значення TIME SYSTEM ID або, якщо його не оголошено, значення за замовчуванням для системи супутників із заголовка. Результат також повідомляє, чи систему було оголошено. Функція відхиляє невідому систему часу (наприклад, місячну шкалу часу), неоголошений файл зі змішаними системами та файли, що не збігаються, замість того щоб читати їх як час GPS. Вона постачає синтетичний тестовий набір годинника станції. Формат файла поправок не визначено, бо публічного такого немає.

Змінено#

• Документація модулів fusion::ukf, fusion::tightly_coupled і fusion::gnss_ins_ekf більше не називає 17-станового навігатора UKF, щільне зв'язування з повним INS і явний стан годинника майбутньою роботою; вони вказують на hybrid_ukf, tightly_coupled17 і carrier_tc.

• RINEX 4 більше не відхиляється (0,36, WP-07): навігаційний файл RINEX 4 раніше відхиляли навмисно; тепер його читають (див. «Додано»). Для файлів спостережень версії 4 і новіших мітки заголовка зіставляють лише у стовпцях 61-80, тож нові записи вільного тексту не можуть видати себе за мітки.

• ionex::parse_ionex читає реальні файли IONEX (0,36, WP-07): повний запис із 16 значень заповнює стовпці 61-80, які читач сприймав за мітку, тож повертав None для кожного реального файла IONEX. Тепер він читає запис, поле мітки якого числове, як значення. Жоден постачений вихід цього не використовував.

• Прийняті потужності Galileo E1 і E5a за OS SIS ICD випуск 2,1 (редакція, 2026-10-14). Спектральні смуги galileo-e1 і galileo-e5a, а також жертви ГНСС із сигналами LEO, що беруть із них потужність, тепер використовують мінімальні прийняті потужності з таблиці 12 Galileo OS SIS ICD випуск 2,1: −157,25 дБВт (було −157,0) і −155,25 дБВт (було −155,0).

  • Зсуваються дев'ять результатів сценаріїв: приклади спектра, кампанія спектра, три вертикалі стійкості LEO і три проєкти сигналів LEO. Ефективне C/N0 зсувається на −0,25 дБ, а J/S на +0,25 дБ на цих смугах.
  • Кожне змінене значення (1766, старе → нове) наведено в docs/revisions/CAP12-galileo-icd21-power-changes.md та його CSV разом із таблицями документації, що змінилися. Жоден рядок реєстру не змінює статусу.
  • Друга частина, того ж дня: жертви із сигналами LEO galileo-e5b (−155,0 → −155,25 дБВт, таблиця 12 E5b) і galileo-e5-altboc (−152,0 → −152,24 дБВт). ICD не має рядка для повної смуги E5, тож значення AltBOC є сумою потужностей підсумків E5a і E5b із таблиці 12, побудованою так, як було старе значення. Зсуваються три результати проєктів сигналів LEO (64 значення: ці прийняті потужності та погіршення C/N0 від LEO до ГНСС на двох жертвах), перелічені в тій самій редакції (§5) і CSV. Більше нічого не зсувається.

• Виправлення атмосферного припливу S2 (tides::atmospheric_tide). Гармоніки атмосферного тиску S2 за Ray (2001) є коефіцієнтами ненормованих P_nm з косинусними фазовими запізненнями; їх використовували як повністю нормовані, а запізнення як синусне випередження IERS. Тепер вони входять, поділені на N_nm з ε = 90° − ψ; нова tides::s2_air_waves відтворює модель A2 із таблиці 5 GFZ STR06/01 для всіх 21 хвиль (найгірше 0,0005 см, 0,05°; VALIDATED). Змінюються лише виходи з увімкненими припливами: підгонка Galileo CI 0,132 → 0,133 м, компоненти Swarm-A на 1–2 мм (зареєстровано заздалегідь у xval/s2-air-tide-fix/).

• Лише документація: propagator::solve_kepler_checked, orbit::solve_kepler і ephem::solve_kepler задокументовано як застарілі розв'язувачі, числово не змінені, із вказівкою на kepler::solve_kepler_markley.

• Стан раунду D9 3 (utck_bound). BIPM Circular T 465 вийшов 2026-10-12. Попередньо зареєстровану проспективну оцінку досі не виконано: випуск 465 містить близько 285 тестових значень, а правило зупинки потребує 1000, тобто приблизно випуски 465–468. Прогін також потребує архівних файлів по лабораторіях від 2026-09-30, бо BIPM відтоді переписав 87 зі 113. Рядок реєстру та заголовок тесту про це говорять; тест, його пороги та його розбиття не змінилися.

• Перевірка правдивості документації (0,36). Дорожню карту, рядки можливостей, рядки стану проєктних документів і коментарі модулів приведено у відповідність до коду; вихідні дані не змінюються. Пункти, що вже побудовані, але досі значилися відкритими, тепер позначено виконаними: перевірки масок ITU-T, сценарій holdover на 24 год і приймання журналів годинника (телекомунікаційна синхронізація), швидкі старти першої хвилини, Лензе–Тіррінг і перехресна перевірка пропагатора Orekit, точний ланцюг ITRF-GCRS, золоті та міжплатформні хеші, походження, багатодефектний ARAIM (ADD v4.2), FDE для одного супутника, бібліотека CRPA, межа неоднозначності інтерференційної картини CAI, розмір streets-of-coverage і 3-D подання орбіти, динаміка орієнтації твердого тіла, записувач OMM і читач ядер NAIF, місячна лібрація DE440, речення про значення прогону в playground, PositioningFom, 17-становий навігатор зі щільним зв'язуванням і вид gravity-map. Рядки також точно вказують, що досі відкрите (наприклад, двочастинний JD у orbit::Propagator, читач src/ionex.rs проти реального продукту та виключення кількох супутників у raim). Відсутній docs/design/evidence/cn0-m2m4/RESULTS.md написано за свіжим прогоном його тестів (M1–M4 проходять), а чернетка валідації IQ для партнерів має поточні лічильники реєстру.

• Коди пам'яті Galileo E1 більше не постачаються у складі. data/galileo-os-sis-icd/C7_E1B.txt і C8_E1C.txt (додатки C.7/C.8 до ICD) вилучено з репозиторію та пакетів. Умови ICD (процитовані в LICENSING.md) дозволяють користувачеві зберігати коди із зазначенням джерела та використовувати їх у продукті, але допускають поширення лише в некомерційних цілях, а Kshana пропонується також за комерційною ліцензією. galileo::e1b_table / e1c_table тепер повертають Result і читають власну копію користувача з KSHANA_GALILEO_E1B / KSHANA_GALILEO_E1C або, у вихідному чекауті, з data/galileo-os-sis-icd/, куди новий scripts/fetch_galileo_e1_codes.sh витягує їх із PDF ICD (з перевіркою хеша). galileo::E1B_TABLE_TEXT / E1C_TABLE_TEXT вилучено. Без таблиць сигнали Galileo E1 (galileo-e1b, galileo-e1c) повертають помилку, яка пояснює, як їх надати, а тести E1 пропускаються з повідомленням. Із наявними таблицями кожен вихід E1 не змінюється. Жоден сценарій, еталон або вихід спектра не використовує таблиці кодів. Тестові дані E5a із додатків C.3/C.4 (оракул LFSR у tests/iq_signals.rs) оброблено так само: завантажуються тим самим скриптом, ігноруються git, а тест пропускається без них.

• Переносна математика всюди (0,36, STUDIO-15): кожна трансцендентна функція f64 у бібліотеці та вибірки rand_distr нормального, гамма й експоненційного розподілів тепер обчислюються через суто Rust-бібліотеку libm (portable_math::PortableFloat, portable_distr), тож нативна збірка та збірка WebAssembly повертають побайтово ідентичний JSON результату для всіх 141 вбудованих сценаріїв і для короткого прогону IQ. Ціна в тому, що останні біти результатів, обчислених математичною бібліотекою хоста, зсунулися: 98 зі 141 вбудованих сценаріїв змінилися, 43 ні; 5 змінилися більш ніж на 1e-3 у своєму найбільшому полі, решта менше. Кожне змінене значення перелічено як старе -> нове в docs/revisions/STUDIO15-portable-math-rebaseline.md (із CSV усіх 136 127 змінених чисел); жоден поріг чи допуск не змінився. Опубліковані числа, що змінилися: доступність europa-surface-pnt з дальністю до Землі 0,719 -> 0,713 і похибка RMS 86,147 -> 86,499 м (одна епоха на межі доступності тепер розв'язується однаково скрізь; на macOS arm64 вона друкувала 0,725 / 85,800 м); похибка станції lunar-joint-od-clock 3,541350 -> 3,536885 м із VLBI і 2183,558 -> 2184,021 м без нього; paper/crossover/inertial.json, вісім значень vibration_psd на 3 одиниці в останньому розряді (помилка в технічному звіті); випущений документ cislunar-observability у величинах на рівні похибки округлення (вісім значень за межею шести значущих цифр, до 6.8e-5 відносно; жоден ранг чи поріг не зсунувся). Закріплені хеші перевірок побайтової ідентичності (skyline_scenarios, geometry_corpus_identity, geometry_trust_no_change) перебазовано на іменований базовий рівень «0,36 portable», а значення 0.35.0 збережено як історичний запис; заморожений прогноз місячної опорної станції не змінено, а його переносний повторний прогін збережено поруч (docs/predictions/*.portable-0.36.json). tests/lunar_joint_od_numpy_oracle.rs (перевірений рядок спільного місячного OD): тестові набори повторно експортовано, а порівняння з numpy повторено з numpy 2.4.6, зареєстрованою версією, без змін скрипта й порога; усі шість мереж проходять (docs/revisions/STUDIO15-lunar-joint-od-oracle-rerecord.md). Роботу партій 2-3, об'єднану після STUDIO-15, також переведено на переносну математику (457 місць виклику у 62 файлах); що це зсунуло, описано в docs/revisions/STUDIO15-batch4-rebaseline.md: 12 вбудованих сценаріїв (найбільша відносна зміна 5.2e-8, жодна надрукована цифра не зсувається), 28 рядків перевірки skyline повторно затверджено, дайджест M2M4 у iq_campaign, застарілі істинні хеші gnss-ins, сигма датуму для неспостережуваного маяка (632,3769 -> 632,3772 м) і два зафіксовані висновки (замикання DRO у CR3BP; CRPA A3, 194 із 456 ліній). Точна edf Greenhall зберігає свій перевірений поріг із логарифмом подвійно-подвійної точності в ядрі (docs/revisions/STUDIO15-greenhall-edf-portable.md), а оракул випробувального стенда gps-sdr-sim повторно запущено на зсунутих експортах NMEA, і кожен поріг дотримано (docs/revisions/STUDIO15-testbench-gpssdrsim-rerun.md).

• README: рядок місячного набору вказує рівень доказів кожної частини (там було сказано, що всі MODELLED).

• realdata::clk::rinex_clock_series повертає RinexClockSeries (ряд, журнал сіткування, система часу, чи її було оголошено, тип запису) замість кортежу (PhaseSeries, GriddingLog). Тепер він переходить із записів супутника (AS) до записів приймача/станції (AR) із запитаною назвою.

• Жодна оцінка не змінюється, поки геометрія не погана; позначка звітується завжди. За хорошої або задовільної геометрії (зокрема відкрите небо лише GPS із 8 супутників) чи невідомої геометрії (монітор не працює) кожна оцінка така, як у 0,35: tests/geometry_trust_no_change.rs утримує виходи обох прикладів сеансів, а tests/geometry_corpus_identity.rs кожен закомічений корпус NMEA суден (також як відкрите небо лише GPS) і сценарії навчання екіпажів до байтів 0.35.0 після вилучення доданих ключів; у двох навчальних сценаріях, де глушіння робить геометрію поганою, погані епохи відрізняються лише зменшенням за геометрію. Журнал із поганою геометрією втрачає до 15 пунктів, яких не втрачав у 0,35. Інші заплановані зміни, усі додавання: ключі вище в JSON результату та пакетах доказів (score_model.weights не змінюється); схема живих рядків JSON переходить від 1,2 до 1,3 (додається geometry, у кожне зменшення class); витяг підсумку отримує geometry; телеметрія отримує ряди геометрії, поля та позначку class лише для входів, що їх несуть, тож потік або результат 0,35 відображається байт у байт, як раніше. geometry є 17-м іменем монітора; його вказано останнім у monitors_run, коли він ухвалив рішення (судно, журнал якого дає геометрію; список 0,35 зберігає свій порядок, а лічильник моніторів у підсумку збільшується на один) і він не має запису в [score.weights] (його задання відхиляється: його зменшення задається в [geometry]).

• tests/fixtures/dop/NOTICE називав ліцензію gnss_lib_py Apache-2.0; випуск 1.0.4 має ліцензію MIT.

• Читач NMEA тепер читає GSA (короткий GSA ігнорується, не рахується пропущеним) і зберігає висоти й азимути GSV, зокрема для супутників, перелічених без сигналу; читач UBX зберігає висоту й азимут NAV-SAT. C/N0 читається точно так, як і раніше.

• Зміна результату: широкосмугові та розгорнуті за частотою завадники тепер використовують Q = 2. Рівняння протиглушіння використовує підручникове коригування розширеного спектра Q для цих завадників, де раніше використовувало 1. Q = 2 відповідає білому шуму над головною пелюсткою з нормованою потужністю сигналу в смузі; воно закріплене в тестах за замкненою формулою з navsignal.

  • Без змін: завадники CW і вузькосмугові (Q = 1), нерозпізнаний тип завадника (Q = 1, найшкідливіше значення) та q_override.
  • Наслідок: там, де діє широкосмуговий або розгорнутий за частотою завадник, ефективне C/N0 зростає до 3,0103 дБ, похідні пороги J/S зростають на 3,0103 дБ, а радіуси відмови у вільному просторі зменшуються в 0,7071 раза.
  • Змінені вбудовані сценарії: 12 із 144 змінюються, усі як і було зареєстровано заздалегідь (xval/jammer-q/PREREGISTRATION.md, результати в xval/jammer-q/RESULTS.md):
    • jamming-demo: C/N0 +3,01 дБ;
    • jamming-harbour-approach-skyline: min_tracking 6 → 7;
    • lunar-jamming: втрачено супутників 26 → 0, медіана відстані зриву стеження 27,4 → 19,4 км;
    • tracking-loop: радіус відмови за динамікою контуру 75,2 → 53,2 км;
    • а також кампанії та перехресні перевірки спектра, що їх містять.
  • Зачеплені споживачі: види jamming, lunar-jamming, tracking-loop і impairment-eval, jamming_kind_cross_check видів спектра, еталонна крива MODELLED кампанії IQ і типове Q для labfit, а також експорт сцени interop.

• Плагін JetBrains: жодного застарілого або запланованого до вилучення API платформи. П'ять діалогів вибору використовують невеликий DialogWrapper зі спадним списком замість застарілого Messages.showChooseDialog; вибирачі одного файла використовують конструктор FileChooserDescriptor замість застарілого FileChooserDescriptorFactory.createSingleFileDescriptor(); анімація відкривається через BrowserUtil.browse(Path) замість browse(File), який платформа 2026,3 планує вилучити. Since-build залишається 243. Перевірювач плагінів IntelliJ повідомляє Compatible без застарілого або запланованого до вилучення використання щодо 2024,3 (IC-243.21565.193), 2025,2 (IC-252.23892.409), 2026.2.3 (IU-262.10968.63) і 2026,3 EAP (IU-263.6259.32); verifyPlugin за замовчуванням перевіряє 2024,3 та будь-який список, заданий у KSHANA_VERIFY_IDES.

• gnss_sim::run_gnss_sim і jamming::run_jamming повертають Result: недійсний розділ [skyline] є помилкою за прямого виклику, як це вже було через api::run_toml, замість тихого повернення до плоскої маски. Несумісна зміна для викликачів цих двох функцій на Rust.

Виправлено#

• Оцінювач кампаній: справжній хибний захват трекера ніколи не рахувався (iq::campaign). Перевірка хибного захвату трекера переводить канал із LOCKED у LOST, коли спрацьовує. Оцінювач позначав наступне оновлення каналу, яке на той час уже було розблоковане, тож його ніколи не рахували. Подія false-lock, повідомлена з LOCKED, тепер є одним епізодом у свій час, у прогоні та в кожній заявленій події, що його містить. Подія, знайдена під час втягування, або повторена каналом, що вже LOST, не є новим епізодом. Новий тест відтворює справжній хибний захват: законна несівна GPS L1 C/A зі стрибком 1/(2T) під час захвату (tests/iq_campaign_false_lock.rs).

  • В еталонній кампанії tests/iq_campaign.rs змінюється лише PRN 11 ramp/agc-3bit (епізоди хибного захвату 0 → 1, 426 і 437 на годину захвату).
  • Його DIGEST клітинок закріплено повторно.
  • Попередньо зареєстрований пін оцінених результатів залишається чинним і досі відтворюється точно: у його хеші лише ці шість полів, змінених цим виправленням після реєстрації, відображено назад на їхні значення до виправлення. Виправлені значення закріплено окремо.
  • Жодного порога не змінено, і жоден рядок VALIDATED, цифра чи число на сайті не зсунулися.

• lunar-frame-campaign: маяк без спостережень тепер звітується (знайдено MR-05). Звіт отримує unobserved_beacons і warning лише тоді, коли якийсь маяк не має спостережень, і тоді сигми спостережуваних маяків беруться з їхньої власної інформації замість того, щоб усім бути null. Датум не змінюється, і жоден типовий, вбудований чи опублікований вихід не зсувається (docs/revisions/BEACON-unobserved-cell-changes.md).

• Місячна система головних осей (lunar_frame::icrf_to_moon_pa, використовується lunar_od і підгонкою LRO): зсув DE421 від середньої Землі до головних осей з moon_080317.tf застосовано в неправильному напрямку та з неправильним порядком кутів Ейлера, тож аналітична система PA лежала приблизно на 208″ від PA замість бути на ній. Тепер її транскрибовано так, як визначає Frames Required Reading SPICE, і вона збігається з SPICE pxform('MOON_ME','MOON_PA') до 2.6e-16 рад; аналітична система PA перебуває на 6″–8″ від PA за DE440 (зареєстровано заздалегідь e1ead19b, перереєстровано be33382e після того, як перша запропонована зміна не виконала поріг 1e-12; docs/design/evidence/fut05b-me-pa-offset-sign/). Опубліковані числа, що зсуваються: підгонка LRO (tests/agency_lro.rs), сире перекриття 53,8 → 39,9 м, динамічна 12,6 → 12,05 м, редукованодинамічна 6,65 → 6,67 м (пороги не змінено). Аналітичний стек тепер збігається з перехресною перевіркою рівня DE ANISE (12,0 / 6,67 м) на обох рівнях; раніша розбіжність на динамічному рівні була цією помилкою.

• Сервер MCP відхиляє [terrain] dem_hgt (продовження CAP-06b). Шлях до плитки рельєфу для виду jamming тепер у inline_only::FILE_SOURCE_KEYS. Вбудована поверхня відхиляє сценарій, що її називає, повідомленням, яке не містить ні шляху, ні помилки операційної системи. Тест захисту файлових джерел тепер також позначає поля, що закінчуються на _hgt.

• Jd2::from_parts із дробовою частиною дня втрачав дріб у перетвореннях UTC, TAI, UT1 і обертання Землі (одна година частини дня давала похибку Землі в 15°); тепер частину дня нормалізовано до цілого. Жоден виклик рушія не зазнав впливу: кожен передає ціле число днів, а кожен постачений вихід побітово ідентичний.

Заплановано#

• Геометрія із заданого skyline (пункт 1 для 0,36, тепер у рушії як src/skyline.rs): sky-blocked і open_fraction зі skyline, де вхід його дає (розрив за азимутом як запасний варіант), подія природного погіршення (фіорд або термінал) в nmea-scenario та дві замасковані геометрії з примітки до проєкту в рядку sigma_UERE x DOP, зареєстровані заздалегідь як додаток.
• Геометрія для журналів RINEX з навігацією (з власного розв'язку рушія) і журналів Android (з рядків Status); обидва сьогодні читаються як unknown. Геометрія в $PKSHT (версія 1 без змін у 0,36) та інтеграції Signal K і OpenCPN.
• Наявна раніше прогалина, не внесена в 0,36: коли поле SNR кожного супутника порожнє, жодне зменшення за loss-of-lock чи C/N0 не спрацьовує; повна втрата сигналу видима лише через signal_loss монітора геометрії (клас environment). Зменшення за неї заплановано.
• Потік схеми 1,3 у зовнішніх оракулах телеметрії (розбирач текстового формату Prometheus і колектор OTLP), які сьогодні охоплюють лише потоки 1,2.
• Двостороннє затінення (каньйон або вузький фіорд) читається як втрата сигналу, а не як заблоковане небо, доки skyline не інтегровано.

[0.35.0] - 2026-10-12#

Уривок, що називає сторонні клієнти ШІ, тут пропущено; він є в CHANGELOG.md на GitHub.

Верифікатор Galileo OSNMA#

• Новий модуль kshana::osnma і kshana osnma verify <input>: відкритий верифікатор на чистому Rust на стороні приймача для Galileo OSNMA. Він читає сторінки I/NAV і звітує для кожного супутника та епохи, чи автентифіковано навігаційні дані, з причиною для кожного збою чи затримки: розбір HKROOT і MACK, повторне складання DSM-KROOT і DSM-PKR, перевірка відкритого ключа за Меркле, перевірка ланцюга ключів TESLA, перевірка MACSEQ і міток для ADKD 0, 4 і 12, зокрема перехресна автентифікація, і результат у формі $PKSOS для монітора довіри до приймача. Вихід несе застереження, що стан не є службою цілісності навігації. docs/OSNMA.md вказує, що перевіряється, а що ні, вимогу до часу та те, що Kshana не надає жодних прав за IPR ICD OSNMA ЄС (користувачі спираються на авторизацію з додатка E до ICD). Реалізовано за SIS ICD випуск 1,1 і Receiver Guidelines випуск 1,3. Сторінки перевіряються за CRC, а потік байтів u-blox UBX-RXM-SFRBX можна читати напряму (--format ubx). Типові тести використовують синтетичні дані та опубліковані тести відомих відповідей для примітивів; необов'язковий тест читає локально завантажену копію офіційних векторів. Після незалежного огляду верифікатор бере свій час лише з перевірених ключів TESLA (підроблений підкадр із далекого майбутнього більше не може стерти збій), дозволяє автентифікації спливати й слідувати за IODnav, що використовується, враховує перевірені повідомлення тривоги (чий лист Меркле тепер включає випадкове поле NPK) і стан NMA «don't use», не допускає фіктивних міток у стан супутника, зберігає ланцюги за CID із відкликанням і поновленням, перевіряє хеш доповнення KROOT і обмежує довжини кадрів UBX та обсяг роботи з перевірки TESLA. Супутник читається автентифікованим лише доти, доки найновіші ефемериди та дані годинника, які він надсилає, є, біт у біт, тими даними, що були автентифіковані (а не просто під тим самим IODnav); стан або відкликання із неавтентифікованого заголовка NMA враховується лише тоді, коли два супутники погоджуються або його несе перевірений KROOT; відтворений старіший KROOT не може замінити ланцюг; а потік ключів, що завис, звітується.

Додано (канали сервера MCP)#

Уривок, що називає сторонні клієнти ШІ, тут пропущено; він є в CHANGELOG.md на GitHub.

• kshana-mcp --http <addr>, потоковий HTTP, самостійне розміщення. За замовчуванням loopback; нелокальна адреса потребує --allow-remote та bearer-токена в KSHANA_MCP_HTTP_TOKEN; жоден інструмент не читає й не записує шлях (файлові інструменти IQ вимкнено); обмеження розміру запиту, часу й паралелізму; без заголовка CORS; перевірки Host і Origin. Kshana не розміщує жодної кінцевої точки (docs/deploy/mcp-http.md, із шаблонами для Docker, Fly.io і Cloud Run).

Додано (поверхні)#

• osnma_verify у Python і WebAssembly. Верифікатор за kshana osnma verify на байтах у пам'яті, що повертає JSON, який друкує --json (застереження в його полі advisory; лише стан автентифікації, а не служба цілісності навігації). Ті самі відмови, що й у командному рядку. Не в MCP: вхід є довгим сирим потоком приймача, який краще обслуговують CLI та Python. docs/SURFACES.md і docs/OSNMA.md про це говорять.

• trust_telemetry у WebAssembly, Python і MCP, з командою плагіна та дією JetBrains. Відтворює потік довіри або результат receiver-trust як текст Prometheus, рядки syslog CEF чи LEEF або навантаження OTLP JSON за допомогою кодувальників, які використовує kshana trust-telemetry (kshana::surface::trust_telemetry); без сокета й без годинника. Плагін: /kshana-trust-telemetry і навичка trust-telemetry. JetBrains: Render Trust Telemetry. Можливості wasm і python та сервер MCP тепер також вмикають otlp, що не додає жодного крейта.

• Вирівнювання паритету. Дії JetBrains Validate Scenario, List Scenario Kinds і Assess Receiver Stream; kshana --help тепер перелічує receiver-trust evidence, evidence, trust-telemetry і nmea-scenario; ноутбук compliance-and-test-bench (відображення відповідності та експорт для випробувального стенда); а кожна решта клітинок JetBrains «CLI only» у docs/SURFACES.md тепер є явним N/A із причиною.

Уривок, що називає сторонні клієнти ШІ, тут пропущено; він є в CHANGELOG.md на GitHub.

Додано (пакети доказів)#

• kshana receiver-trust evidence і kshana evidence verify: підписані, придатні до перевірки пакети доказів для події довіри до GNSS. Пакет об'єднує сирий зріз журналу та SHA-256 повного журналу, конфігурацію з кожним порогом, результати та причини для кожної епохи, версію рушія, маніфест із ланцюгом хешів і самодостатній підсумок HTML, підписані Ed25519 (ключ із kshana evidence keygen або ваш власний файл; ключі ніколи не зберігаються в пакеті, а *.evidence-key ігнорується git). verify перевіряє кожен хеш, ланцюг і підпис та точно називає, що не проходить; із --pubkey він закріплює підписувача. Токен RFC 3161 можна додати, він читається й прив'язується до маніфеста (власний підпис authority ця збірка не перевіряє; це покриває openssl ts -verify). Зріз журналу є точними байтами вікна там, де читач повідомляє джерельні проміжки (NMEA, UBX, RINEX 3, Android), інакше цілим журналом, і маніфест вказує, яким саме. Створення та перевірка є чистими публічними функціями (kshana::evidence), що збираються для wasm32. Пакети заявляють, що вони є технічним записом, а не юридичним висновком. Нові залежності: дерево ed25519-dalek (BSD-3-Clause та Apache-2.0/MIT, мінімальні можливості) і пряма zeroize (вже в цьому дереві) для стирання ключового матеріалу. Див. docs/EVIDENCE-PACKS.md.

Додано (телеметрія довіри)#

• kshana trust-telemetry: довіра до GNSS як джерело телеметрії безпеки. Читає потік довіри для кожної епохи (рядки JSON: оцінка 0-100, смуга, причини) або пакетний результат receiver-trust і подає кінцеву точку Prometheus /metrics (за замовчуванням localhost), події syslog у CEF або LEEF у конверті RFC 5424 (UDP чи TCP) і, за вимкненої за замовчуванням можливості otlp, експорт OTLP/HTTP JSON. Доставка працює у робочих потоках з обмеженнями часу з'єднання та запису, обмеженим відступом перепідключення та лічильником kshana_trust_syslog_send_failures_total, тож мертвий чи завислий колектор не може зупинити живу оцінку чи заморозити /metrics; мітки причин обмежено 64 рядами. Жодних нових залежностей. Зразок панелі Grafana міститься в deploy/grafana/. Імена метрик, мітки та відображення полів CEF/LEEF описано в docs/TRUST-TELEMETRY.md. Формат потоку ізольовано в src/telemetry/sample.rs.

Додано#

• Морська довіра: жива оцінка довіри 0-100 до розв'язку рухомого судна за NMEA 0183, яку приймач уже виводить, із необов'язковим бар'єром. kshana receiver-trust приймає таблицю [platform] (kind = "static" або "vessel", максимальні швидкість, прискорення та швидкість повороту судна, висота антени над ватерлінією та необов'язковий датчик курсу; кожне типове значення задокументовано з причиною). Для судна статичний монітор стрибка позиції, який вимірює відстань від середнього калібрування і є хибним на судні в русі, замінено причинними моніторами рухомої платформи: кінематична узгодженість позиції зі звітованими швидкістю та курсом і з обмеженнями судна, курс за гірокомпасом проти курсу над ґрунтом, лаг проти швидкості над ґрунтом, висота антени проти заявленої висоти над ватерлінією, одночасне колапсування та зростання розкиду C/N0 відносно базового рівня калібрування, і узгодженість часу (також із годинником цього комп'ютера в живому режимі). Він також читає звітований стан автентифікації, загальний або для кожного супутника (лише звітований стан: жодної криптографії OSNMA). Кожен поріг заявляється в таблиці [maritime] до прогону. Тоді кожна епоха отримує оцінку від 0 до 100 за детермінованим, попередньо зареєстрованим відображенням (без навчання, нічого не підгоняється під події; ваги, межі смуг і докази містяться в таблиці [score]), відображену на наявні стани довіри, з моніторами, що знижували оцінку, та їхніми пунктами. Статичні сценарії не змінюються і хешуються як раніше. kshana receiver-trust live <session.toml> читає stdin, файл, що доповнюється, TCP чи UDP і записує один рядок JSON на епоху та власне речення $PKSHT; із --gate воно пропускає потік без змін, поки розв'язку довіряють, і позначає розв'язок недійсним (якість GGA 0, стан RMC і GLL V, режим GNS і VTG N), поки не довіряють. Бар'єр вимкнено, якщо про нього не просять; --listen tcp:<port> обслуговує потік через бар'єр будь-якій кількості клієнтів TCP (за замовчуванням loopback, повільного клієнта відключають, а не блокують інших). Це консультативне програмне забезпечення, не навігаційне обладнання із затвердженням типу (IEC 61108, IEC 61162); відповідальність залишається на операторі. examples/maritime-trust/ є синтетичним журналом Таллінн–Гельсінкі, записаним лише як текст, із зсувом позиції на півдорозі, під час якого приймач продовжує звітувати дійсний розв'язок; його очікуваний вихід закріплено тестом. Посібник: docs/MARITIME-TRUST.md. Перевірки не можуть побачити спуфера, чий розв'язок узгоджений зі всім на шині; посібник про це говорить.

Карта завад#

• kshana interference-map і kshana route-exposure: публічна картина того, де літаки та судна повідомляли про погіршені навігаційні дані, і скільки з маршруту це зачіпає. Вхідні дані є локальними файлами CSV, створеними з відкрито ліцензованих даних ADS-B (adsb.lol, ODbL 1,0) та AIS (NOAA MarineCadastre, Kystverket за NLOD 2,0); кожен вихідний файл є одним джерелом і однією добою UTC у форматі GeoJSON, що несе метод, його пороги, ліцензію на дані, атрибуцію та зміщення покриття джерела. Метод ADS-B агрегує NIC і NACp на фіксовану сітку та називає клітинку погіршеною за часткою різних літаків, із захистами для обладнання, що ніколи не звітує точність, низької висоти та причин широкої області. Метод AIS запускає п'ять детекторів: позиції на суходолі (проти наданої користувачем берегової лінії), кругові треки, неправдоподібні стрибки, неправдоподібні швидкості та багато суден в одній позиції. Пороги є попередньо зареєстрованими сталими іменованої версії методу. Лише агрегати: ідентифікатори хешуються в пам'яті й ніколи не записуються, а клітинки з менш ніж 5 різних літаків чи суден не публікуються. Погіршена клітинка не є висновком про завади. Типові команди не використовують мережу; допоміжна fetch-land --allow-network за бажанням завантажує полігони суходолу Natural Earth із закріпленої за комітом адреси й зберігає файл лише тоді, коли його SHA-256 збігається. Вхід ADS-B є CSV або безпосередньо файли історії adsb.lol readsb (нова залежність: flate2 із суто Rust-бекендом, для gzip). Обидва методи мають версію 2: виклик погіршеного чи аномального стану потребує щонайменше 5 літаків або суден (мінімум для публікації), кожен підрахунок на клітинку нижче 5 приховується як null, а доба, фон якої неможливо оцінити, приховує свої виклики. Вихідні файли називаються <source>-<dataset>-<date>.geojson і ніколи не перезаписуються; вхід передається потоком рядок за рядком; експозиція маршруту обробляє антимеридіан. Тести використовують лише синтетичні дані. Див. docs/INTERFERENCE-MAP.md та огляд ліцензій у docs/data/INTERFERENCE-DATA-SOURCES.md.

Додано (потоки для навчання)#

• kshana nmea-scenario: синтетичний містковий NMEA 0183 для навчання екіпажів розпізнавати глушіння та спуфінг ГНСС (GNSS). За TOML сценарію він записує файл або передає потоком через TCP чи UDP (унікаст або широкомовлення; у реальному часі, прискорено або якнайшвидше) повний місткований набір GGA, RMC, VTG, GSV, GSA, GNS, ZDA, HDT і VBW для траєкторії судна з обмеженнями кутової швидкості повороту, прискорення та течії, з геометрією супутників за власними номінальними орбітальними угрупованнями рушія. Сценарні події на часовій шкалі: глушіння, відведення положення (дійсне визначення, що поступово віддаляється), спуфінг часу та затримка повтору, кожна з наростанням і спадом. Журнал інструктора (JSON і текст) фіксує, що і коли було введено, з істинною траєкторією поряд із заявленою. Бібліотека в scenarios/training/ (глушіння у відкритому морі, відведення біля узбережжя, спуфінг часу при підході до порту, поєднаний) містить примітки для тренера. Вивід має правильні контрольні суми та детермінований для кожного зерна (seed); тести фіксують еталонний фрагмент для кожного сценарію та читають кожне речення зчитувачем NMEA receiver-trust. Лише текст: жодного виводу RF, IQ чи форми сигналу; потоки призначені для навчання й тестування і ніколи не повинні подаватися в чинні навігаційні системи судна. Див. docs/NMEA-TRAINING.md.

Морські інтеграції (0.35.0, напрям B)#

• Додаток Signal K (integrations/signalk/, не опублікований у npm): запускає kshana receiver-trust live або підключається до нього (власний вхід NMEA сервера, користувацькі аргументи входу, потік TCP у форматі JSON-рядків або речення $PKSHT потоку шлюзу), публікує оцінку довіри, смугу, причини, сповіщення та стан шлюзу в navigation.gnss.kshana.* (включно з положенням, повідомленим приймачем, як контекстом, ніколи як navigation.position) і породжує сповіщення Signal K (warn за погіршення, alarm за відсутності довіри, з порогами утримання, скидання та застарілості, усі в схемі конфігурації). Без залежностей npm. Перевірено на записаному синтетичному виводі.
• OpenCPN: NMEA режиму шлюзу надає безпосередньо kshana receiver-trust live --gate --listen tcp:10110 (рекомендовано); ретранслятор TCP без залежностей (integrations/opencpn/nmea-tcp-relay.mjs) є необов'язковою альтернативою. У будь-якому разі OpenCPN бачить недійсне визначення, коли довіра руйнується, та $PKSHT у своєму вікні налагодження NMEA; тести відтворюють синтетичний потік шлюзу через справжній сокет TCP і перевіряють, що отримує споживач. Рідний додаток панелі оцінки (integrations/opencpn/plugin/, API додатків 1,18, CMake) зчитує $PKSHT із власного потоку NMEA OpenCPN і сповіщає про смугу «немає довіри»; він збирається, його логіку перевірено модульними тестами, і його запускали всередині OpenCPN 5.8.4 під віртуальним дисплеєм (докази та сценарій відтворення в integrations/opencpn/evidence/); його не запаковано для менеджера додатків.
• Еталонна збірка (deploy/reference-build/): загальний перелік деталей, налаштування ОС, модулі systemd для консультативного монітора та додаткового (opt-in) шлюзу (перевіряються за допомогою systemd-analyze verify через check-units.sh), варіант із контейнером, підключення Signal K.
• Додаток Signal K приймає схему живого JSON 1,2 (ключ position, потім доданий ключ advisory; невідомі додані ключі ігноруються), що перевірено на реальному виводі 1,2 і на справжньому signalk-server.
• Виправлення за результатами огляду: модулі systemd завжди перезапускаються й працюють в ізоляції (без оболонки, без мережі там, де вона не потрібна), фрагмент logrotate, check-units.sh завершується невдачею за будь-якого зауваження; контейнер запускає шлюз зі змінних середовища з перевіркою стану та базовими образами, закріпленими за дайджестом; метадані оцінки Signal K, застаріле сповіщення замінюється, коли дані відновлюються, помилки дочірніх процесів зберігаються, а завершення примусово посилюються, небезпечні inputArgs відхиляються, а сповіщення міститься в notifications.navigation.gnss.kshana.trust; ретранслятор обмежує утримуваний неповний рядок; розбирачі $PKSHT відхиляють оцінки поза діапазоном від 0 до 100; перевірка посилань у документації; робочий процес CI (marine-integrations.yml), що запускає все це, включно зі справжнім бінарним файлом наскрізно.
• docs/MARINE-INTEGRATIONS.md. Консультативне програмне забезпечення, не обладнання із затвердженням типу; відповідальність залишається на операторі. Лише програмне забезпечення: нічого не передається, і жодних показників виявлення чи хибних тривог не заявляється.

Додано: зіставлення з вимогами compliance та експорт для випробувального стенда#

• docs/compliance/ і kshana compliance-report. Зіставлення виводів Kshana з п'ятьма рамками та стандартами стійкості (Resilient PNT Conformance Framework v2.0 Міністерства внутрішньої безпеки США, настанови IMO для суден, настанови EASA для авіації, стаття 21 NIS2, EN 16803, платний стандарт, на який посилаються за частиною та за кількома номерами пунктів, видимими в тексті каталогу), по одній таблиці на рамку: джерело, що воно вимагає в нашому переказі, виводи, які підтримують докази для нього (supports evidence for), і прогалина. Версії джерел, URL-адреси та те, що було й не було прочитано, зафіксовано. kshana compliance-report <result.json>... заповнює зіставлення за наданими прогонами та позначає кожен рядок як evidenced, partly-evidenced, not-evidenced або out-of-scope, у Markdown і JSON, з прогалиною, що лишається в кожному рядку. Формулювання таке: «підтримує докази для» (supports evidence for); нічого не оцінюється і не схвалюється. Тести використовують синтетичні прогони й завершуються невдачею, коли закомічена таблиця розходиться з кодом.
• kshana bench-export <scenario.toml>. Записує рух транспортного засобу та події сценарію gnss-ins, jamming або gnss-sim для лабораторного симулятора ГНСС (GNSS): CSV руху користувача з документованими системами координат і супровідним файлом метаданих, NMEA 0183 GGA/RMC, текст шляхових точок, а також події як CSV і як блоки receiver-trust [[events]] (src/interop/testbench.rs). Лише рух і події: жодного сигналу не записується. Кожен файл зчитується назад у tests/interop_testbench.rs і порівнюється в межах свого заявленого допуску. docs/TEST-BENCH.md описує метод відтворення експорту через симулятор і оцінювання журналу приймача за допомогою kshana receiver-trust.
• Що вважається доказом. Результат зараховується для можливості лише тоді, коли містить поля, які записує його різновид; сама позначка різновиду не означає нічого. Невідомі різновиди, результат, що розходиться з рівноцінним сценарієм, не шістнадцяткові хеші та спотворені лічильники довіри до приймача перелічуються як невикористані із зазначенням причини. Звіт екранує комірки Markdown і не може панікувати на хеші, що не є ASCII. compliance::run_from_text і assess_texts приймають тексти, а не шляхи.
• Експорт для випробувального стенда. --epoch перевіряється на діапазон (UtcEpoch::parse_iso); файл шляхових точок перевіряє кожен інтервал, а команда пояснює причину, коли її пропущено; документація зазначає, що напрямок gnss-ins є рисканням корпусу, а не курсом, поля-заповнювачі GGA і власну зміну висоти сценарію. bench-export і compliance-report наведено в тексті довідки.
• fusion::pack::truth_trajectory відкриває історію істинного стану профілю руху gnss-ins (з тим самим кроком, що й власна істина цього різновиду), а UtcEpoch отримує поля дати й часу NMEA.

Перевірка карти завад#

• Семантику декодування та геометрію карти завад звірено з незалежними реалізаціями на синтетичних вхідних даних. Значення кодів NIC і NACp звірено з декодуванням pyModeS синтетичних кадрів ADS-B, значення AIS «недоступно» з декодуванням pyais синтетичних речень AIVDM, призначення комірок сітки з shapely, довжину маршруту за станом комірки з shapely і GeographicLib, а маскування суходолу з shapely і pyproj, кожне в межах допуску, зафіксованого до першого порівняння (tests/fixtures/interference_map_ref/PREREGISTRATION.md). Це підтверджує, як зчитуються коди та значення полів, і геометрію, а не те, що позначена комірка є завадою. Зчитувач полігонів суходолу тепер замикає кільце, яке не повторює свою першу вершину, а раніше він зчитував його без останнього ребра. Документація задає порогові значення низької точності NACp і NIC як межу, яку позначає кожен код (NACp 6 є межею EPU 556 м, NIC 5 є межею вмістилища 1 NM).

Додано (перевірка форматів телеметрії та пакетів доказів)#

• Зовнішні перевірки криптографії пакета доказів, верифікатора пакета та форматів передавання телеметрії. Тестові вектори RFC 8032, розділ 7,1, Ed25519 (1, 2, 3 і 1024) та приклади SHA-256 з FIPS 180-4 проходять через власні функції підписування, верифікації та хешування пакета з точною рівністю. Верифікатор, написаний на Python лише за нормативним розділом docs/EVIDENCE-PACKS.md (hashlib і cryptography), збігається з верифікатором на Rust на 71 неушкоджених і підроблених пакетах: за вердиктом, набором збоїв, вердиктом підпису та обома головами ланцюжка. Наша експозиція Prometheus зчитується розбирачем офіційного клієнта Python, а наш OTLP JSON суворо перевіряється офіційним повідомленням opentelemetry-proto, і обидва збігаються зі станом, з якого їх створено. CEF і LEEF не мають незалежного відкритого валідатора й залишаються обчисленими лише за моделлю. docs/EVIDENCE-PACKS.md отримав нормативний формат пакета та процедуру верифікації, за якими написано верифікатор з чистої кімнати; VerifyReport отримав signature_valid. Оракули та фікстури: scripts/gen_ed25519_rfc8032_ref.py, scripts/gen_evidence_pack_ref.py з scripts/evidence_verify_cleanroom.py, scripts/gen_telemetry_formats_ref.py; тести evidence_crypto_reference, evidence_pack_reference і telemetry_formats_reference. CI не потребує Python.

Додано (перевірка подій CEF)#

• Події CEF телеметрії правильно зчитуються назад двома незалежними розбирачами з відкритим кодом. pycef 1,11 і кодек Logstash CEF (logstash-codec-cef 6.2.7 у Logstash 8.15.3) розбирають 157 рядків CEF (кожну зміну смуги та кожну епоху закоміченого потоку телеметрії, а також ворожий текст, що містить =, зворотні скісні риски, вертикальні риски, розриви рядків, табуляції та багатобайтовий текст) і відновлюють кожне поле заголовка, рівень серйозності, точний набір ключів розширення та кожне значення точно. Кодек Logstash також зчитує чотири рядки, текст заголовка яких потребує екранування, чого pycef не вміє. Поріг зареєстровано до запуску будь-якого з розбирачів (tests/cef_reference.rs); фікстури в tests/fixtures/cef/, скрипти оракулів scripts/gen_cef_ref.py і scripts/gen_cef_logstash_ref.py; CI не потребує ні Python, ні Logstash. LEEF не має підтримуваного відкритого розбирача й залишається обчисленим лише за моделлю. Події CEF тепер містять оцінку довіри та зсув епохи в користувацьких полях з рухомою комою словника CEF (cfp1, cfp2) замість цілочисельних полів cn1 і cn2, які не підходили ні для одного зі значень; CEF у цьому випуску новий, тож жодне випущене раніше не змінюється.

Змінено#

• MCP: assess_receiver_log приймає журнал як text або base64; вхід інструмента обмежено 4 МіБ.
• Діаграма глушіння також бере кольори з палітри. src/jamming.rs був єдиним модулем, який редакція палітри Observatory залишила з власними кольорами, поки надходила робота над jammer-Q; його *.chart.svg (jamming, maritime-strait-jamming та інші сценарії різновиду jamming) тепер зчитує src/palette.rs, а список дозволених винятків у tests/palette_sync.rs порожній. Лише кольори та шрифт: діаграми jamming-demo і maritime-strait-jamming дорівнюють своїм раніше записаним зображенням після нормалізації кольору, font-family і нижнього колонтитула з версією. Жодне зображене значення не змінилося. Записані копії Studio в web/studio/recorded/ було записано знову під час перенесень 0.33.0 і 0.34.0 (лише штамп версії): вони й далі мають стару розмальовку діаграми глушіння і перейдуть на розмальовку палітри під час наступного перенесення.

Виправлено#

• Межа 3 сигма для ансамблю годинників тепер охоплює флікерну підлогу, і перевірка стану фільтра її бачить. За наявності flicker_floor істинний годинник мав флікерну ЧМ, а двостанний фільтр, що дає межу цілісності, її не мав, тому покриття 3 сигма для постачуваного сценарію clock-ensemble становило 0,41 (класичний) і 0,33 (квантовий), а перевірка NIS/NEES, яка брала власну істину з моделі фільтра, повідомляла однакові значення з підлогою та без неї. Тепер межа дорівнює двостанній дисперсії плюс точна дисперсія флікерної фази, накопиченої від останньої синхронізації, обчисленої з того самого банку, що й для істинного годинника; перевірка NIS/NEES бере істину з розширеної моделі з цим банком і запускає узгоджений розширений фільтр (а двостанний фільтр проти флікерної істини повідомляє consistent = false). Зміна виводу лише для годинників з ненульовим flicker_floor: integrity для clock-ensemble переходить від 0,40866 / 0,33026 до 0,99970 / 1,0 (класичний / квантовий), а NIS/NEES filter_health тепер включають флікер; похибка часу, holdover_s і timing_p95_ns не змінилися, а сценарії без підлоги побайтово ідентичні. scenarios/orbit-gnss-challenged.toml (різновид орбіти, зерно (seed) 7, підлоги 1e-16 / 2e-11) також змінюється: fom.integrity класичний з 0,7734 до 1,0 і квантовий з 0,9796 до 1,0, а NIS/NEES filter_health та їхні смуги змінюються. Його квантовий filter_health.consistent перемикається з true на false: це подія вибірки ансамблю флікера 16 зерен на 60 кроків (NIS 0,8815 проти смуги [0,9125, 1,0914]), а не дефект. Смуга охоплює 95 %, тож приблизно 5 % зерен за побудовою позначають узгоджений фільтр (40 свіжих зерен цього сценарію: квантовий 1 і класичний 2 позначено); на 64 на 200 те саме зерно лежить усередині смуги для обох годинників (NIS 0,990 і 1,001). Відоме подальше завдання: різновид fusion має ту саму прогалину (класична цілісність 0,80 з підлогою); різновид hybrid лишається вище 0,99.

[0.34.1] - 2026-10-10#

Безпека#

• Посилено вхід сервера MCP. Інструменти сценаріїв сервера MCP тепер приймають лише вбудований вміст і відхиляють поля з файловим джерелом; розмір входу обмежено. Консультативне повідомлення: GHSA-8wpf-hqg5-6xjr.

[0.34.0] - 2026-10-09#

Лабораторне відтворення: рушій стеження, монітори виявлення та засіб запуску кампаній для записів GNSS IQ, із відповідними конструкціями контурів, оцінювачами C/N0 та оцінками. Клас доказів: усе наведене нижче є MODELLED або перевірене на внутрішню узгодженість за замкненими формулами та зерновим моделюванням; жодне з цього не додає рядка VALIDATED, а реєстр верифікації не змінено (251 рядок: 124 перевірених за зовнішнім еталоном, 123 обчислених за моделлю, 4 партнерські). Це шар програмного аналізу: нічого тут не синтезує форму сигналу глушника чи спуфера, і нічого не передається.

Додано#

• Лабораторне відтворення: умови випробувань, засіб запуску кампаній і оцінювання (0.34.0). kshana iq campaign <campaign.toml> відтворює записи × ланцюжки входу × конструкції контурів (kshana.loop-design/1) і оцінює кожну комірку за файлом умов випробування для кожного запису (kshana.test-conditions/1, TOML або JSON). Цей файл стверджує, що лабораторія знає про запис: очікувані супутники та для кожної події її мітку типу, початок і кінець, уражені супутники й заявлений профіль J/S або потужності глушника. Це лише метадані. Оцінки для кожного супутника, для всього прогону та для кожної події такі:

  • доступність, час до втрати захоплення та заявлене J/S у момент втрати;
  • час повторного захоплення від кінця події та від втрати;
  • виміряне погіршення C/N0 для кожного інтервалу заявленого J/S;
  • епізоди хибного захоплення на годину захоплення (прапорець трекера або Доплер проти супровідного файлу істини);
  • джитер дискримінаторів PLL і DLL.

  Поряд із кожною виміряною кривою погіршення малюється аналітичний еталон спектрального розділення (jamming::effective_cn0_dbhz з Q цього типу), який позначається MODELLED скрізь, де він з'являється.

  Комірки виконуються паралельно через скінченний автомат стану захоплення сеансу стеження, і кожна записується атомарно під ключем хешу вмісту. Ключ охоплює SHA-256 запису, хеші умови, входу, конструкції, прогону та оцінювання, обов'язковий data_class (synthetic | client-confidential) і версію рушія. Коли задано run.epochs, потік kshana.track-epoch/1 і події захоплення кожної комірки також зберігаються, іменуються за ключем комірки та хешуються в комірку. cell_key і report::digest є публічними, тож споживач може заново вивести кожен ключ і дайджест. Тому повторний запуск пропускає завершені комірки, а виводи ніколи не залежать від кількості воркерів. Прогін записує scorecard.csv/.json, самодостатній report.html і DIGEST. Пороги «пройдено/не пройдено» ([scoring.bars], які можна перевизначити для кожного запису) застосовуються під час побудови звіту.

  • [scoring] cn0_estimator = "m2m4" | "nwpr" (типово "m2m4", частина хешу оцінювання) вибирає C/N0, що лежить в основі повідомленого C/N0 і кривої погіршення. Обидві оцінки завжди оцінюються й повідомляються (медіани всього прогону та базового рівня, а також для кожного інтервалу J/S), а комірка та таблиця оцінок фіксують оцінювач. NWPR показує занижене значення приблизно на 8 дБ × Bn·T за власного джитеру контуру; M2M4 — ні.

  Також нове:

  • kshana iq campaign report <dir> відновлює таблиці оцінок, звіт і дайджест із комірок;
  • kshana iq conditions <file> перевіряє файл умов випробування за його схемою;
  • events_from_sigmf = true імпортує анотації kshana:test_event запису SigMF як події;
  • Python отримує iq_test_conditions, iq_campaign і iq_campaign_report;
  • kshana-mcp отримує iq_campaign, що є інкрементним і відновлюваним за бюджету відліків на виклик, з усіма файлами, обмеженими робочим каталогом, і iq_campaign_status.

  Тести: tests/iq_campaign.rs запускає синтетичну кампанію з 3 записів × 2 вхідних ланцюжків × 2 конструкцій. Її сцени мають заявлені профілі C/N0, і вона охоплює:

  • кожну метрику, перевірену за введеною істиною;
  • відновлення після часткового однопотокового прогону з пошкодженою коміркою, побайтово ідентичне непереривному чотирипотоковому прогону;
  • файли епох для кожної комірки;
  • регресію повторного захоплення трьох супутників за 20 с: із увімкненим reacquire кожен канал повертається в межах 2 с після розриву у 2 с; результат із вимкненим reacquire зафіксовано;
  • пороги, переоцінені без повторного запуску;
  • CLI;
  • ігноровані за замовчуванням перевірки пропускної здатності та пам'яті в режимі release, включно із записом на 4 ГБ (5,45× реального часу, пікова пам'ять на 2 МБ вища за початкову RSS; вимірювання на одній машині, а не пороги).

  Лише програмне забезпечення: нічого не передається, і жодна форма сигналу завад чи спуфінгу не синтезується. Нотатки щодо проєкту та реалізації: docs/design/LAB-CAMPAIGN.md.

• Рушій стеження для лабораторного відтворення (0.34.0: B3.1, B3.2, B3.3, B6.1).

  • Файли конструкцій контурів: TOML kshana.loop-design/1 (docs/design/LOOP-DESIGN-TOML.md; розбирач iq::track::design). Одна або кілька іменованих конструкцій задають кожне поле контуру:

    • вид несівної (PLL, FLL або PLL з допомогою FLL), порядки та смуги пропускання;
    • дискримінатори PLL/FLL/DLL і допомога несівній;
    • крок і інтегрування;
    • пороги захоплення та вікна C/N0, і бітова синхронізація;
    • скінченний автомат захоплення;
    • передавальне виявлення ("auto" або явне).

    Конструкції можуть extends одна одну. Невідомі ключі відхиляються. Кожна розв'язана конструкція має хеш SHA-256 за канонічною формою JSON (ключі відсортовано на кожному рівні, фіксоване форматування чисел), тож хеш не залежить від порядку полів; кожен вивід його фіксує. Поверхні:

    • kshana iq track --design <file> [--design-name], де явні прапорці перевизначають конструкцію та фіксуються;
    • kshana iq sweep --design <file>, що запускає кожну конструкцію у файлі;
    • Python iq_track(design=, design_name=, reacquire=), iq_loop_designs;
    • MCP iq_track design/design_name.

  • M2M4 C/N0 (EpochOutput.cn0_m2m4_dbhz, стовпчик епохи стеження cn0_m2m4_dbhz після cn0_beaulieu_dbhz; словники епох Python). Оцінка за другим і четвертим моментами за тими самими вікнами, що й NWPR, лише за потужністю prompt: NWPR показує занижене значення за власного джитеру несівної контуру (приблизно 8 дБ × Bn_PLL·T), а M2M4 — ні. На GPS L2C CM (20 мс, номінально 40 dB-Hz, PLL від 1 до 10 Гц) вона дає 39,93 dB-Hz за кожної смуги, тоді як NWPR падає з 39,55 до 38,22; на L1 C/A за 45 dB-Hz вона дає 45,34. NWPR і кожен інший вивід не змінено (фіксація біт у біт). Двійковий запис лишається 184 байтів (значення займає зарезервований float і біт прапорця 6).

  • Додаткові відводи корелятора (мультикорелятор / SQM). [design.integration] extra_taps_chips = [..] (зсуви в чипах від prompt, додатні для раннього; щонайбільше 16, кожен у межах ±2) корелює додаткові репліки поряд з E/P/L і повертає їх як EpochOutput.extra ((offset, value) у порядку конструкції). Контури ніколи їх не використовують. Ключ пропускається в канонічному JSON, коли порожній, тож хеш типової конструкції та кожен вивід без відводів не змінюються (kshana.track-epoch/1 лишається; CSV/JSONL/двійковий вивід без відводів побітово ідентичні). З відводами: стовпчики CSV/JSONL і двійковий запис у 184 + 16 × taps байтів, заголовок якого містить extra_taps_chips, тож старий зчитувач відхиляє файл, а не розбирає його хибно. --extra-taps (CLI), extra_taps (Python) і extra_taps_chips (MCP iq_track). Конструкції одного прогону мають збігатися за відводами.

  • Паралельні канали (iq track / iq sweep --threads <N|auto>; Rust TrackSession::with_threads). Канали кожного фрагмента виконуються на до N потоках (std::thread::scope; wasm32 лишається послідовним). Кореляція та скінченний автомат захоплення каналу торкаються лише цього каналу; його епохи та події буферизуються й записуються в приймачі в порядку каналів, тож вивід (CSV, JSONL, двійковий, події, підсумок) побайтово ідентичний послідовному прогону за будь-якого N. Типово лишається 1 потік. Виміряно на записі з 12 каналів, 4 с, 4,092 МГц на 4 ядрах: 19,5 с послідовно, 11,5 с на 2 потоках, 6,3 с на 4 (3,1×; початкове захоплення послідовне).

  • Експорт поверхні захоплення (kshana.acq-surface/1; iq::acq_surface, docs/design/ACQ-SURFACE.md). iq acquire --surface <path> (один PRN; CSV, JSON або двійковий), Python iq_acq_surface і MCP iq_acquire surface_out записують усю поверхню потужності кореляції Доплер × фаза коду, яку обчислює пошук (її комірки збігаються з комірками acquire біт у біт), із піком і двома уточненнями тонкого Доплера: параболічною оцінкою та тонким пошуком із кроком 1/16 інтервалу (≈5 Гц за когерентності 4 мс, проти інтервалів у 167 Гц). Сам acquire і кожне типове налаштування не змінено.

  • Потоковий вивід епох (kshana.track-epoch/1; iq::track::sink). Кожне оновлення контуру містить:

    • корелятори early/prompt/late;
    • усі три виводи дискримінаторів;
    • стани NCO PLL/FLL/DLL і фазу несівної;
    • прапорці PLI та захоплення;
    • обидві оцінки C/N0 і біти;
    • стан захоплення.

    Він записується в міру виникнення, як CSV, JSON Lines або версійна двійкова форма із зчитувачами на Rust (BinaryEpochReader) і Python (iq_read_epochs).

    • iq track отримує --epochs, --events і --summary (kshana.track-summary/1), а iq sweep отримує --epochs і --events. MCP iq_track отримує epochs_out/events_out і будує свою відповідь із підсумку з обмеженою пам'яттю.
    • Купа прогону більше не росте разом із довжиною запису: tests/iq_track_memory.rs вимірює це лічильним алокатором (6× довжини, той самий пік у межах 64 КіБ), із контролем, що показує: шлях у пам'яті таки росте.
    • Потоковий вивід побітово збігається з відтворенням у пам'яті.

  • Скінченний автомат стану захоплення (iq::track::lock, TrackSession): втягування → захоплено → втрачено → повторне захоплення → втягування, або виведення з роботи, коли втрата триває довше за reacq_window_s (типово 30 с). Невдалі пошуки повторюються кожні reacq_interval_s (0,1 с) з рівними інтервалами, тож графік повторів додає щонайбільше 0,1 с до виміряного часу повторного захоплення. Необов'язкове збільшення інтервалу (reacq_max_interval_s понад reacq_interval_s) типово вимкнене, а max_reacq_attempts — необов'язкове обмеження (0, тобто без обмеження, типово). Тепер після перерви в 2 с на трьох PRN при 4,092 MS/s усі канали повторно захоплюються й утримують захоплення. За бюджету в 3 спроби кожен канал було виведено з роботи протягом 0,2 с після втрати.

    • Пороги (loss_dwell_s, pull_in_max_s, доплерівське вікно повторного захоплення) беруться з проєкту. Кожен перехід є подією з указаною причиною.
    • Перевірка хибного захоплення шукає відстежуваний доплерівський зсув проти його псевдоніма FLL/PLL ±1/(2T). Вона виявляє хибне захоплення, яке виміряв PR #38 (−2400 Гц відстежувано за зсуву 500 Гц). Із ввімкненим повторним захопленням канал завершує роботу із захопленням на введеному доплерівському зсуві.
    • Розрив сигналу в 0,8 с оголошується втратою, і сигнал повторно захоплюється протягом 0,3 с після його повернення.
    • --summary final_state (і стовпець таблиці) — це стан після останнього переходу, тож канал, виведений з роботи після останнього оновлення контуру, показує RETIRED.
    • Допомога FLL лише під час втягування ([design.carrier] fll_assist = "pull-in", типово; "always" зберігає попередню поведінку біт у біт). FLL передає керування PLL, коли згладжений PLI утримується на рівні fll_off_pli (0,8) або вище впродовж fll_gate_dwell_s (0,1 с), і повертається, коли він падає нижче fll_on_pli (0,6). Залишений ввімкненим, тракт FLL на 10 Гц зривав фазове захоплення нижче приблизно 38 дБ-Гц на чистих сигналах: за 35 дБ-Гц частка фазового захоплення становила 10–16 % за справжньої фазової похибки 38–41°. З вмиканням за умовою (gating) типовий варіант утримує 100 % за 35 дБ-Гц із 4,5°, так само як самостійний PLL. Втягування за похибки передавання 100 Гц не змінилося. Докази із заздалегідь зареєстрованими порогами: docs/design/evidence/carrier-lock/. Тому типові контури не збігаються біт у біт із попередніми прогонами типового проєкту. Щоб їх відтворити, використовуйте fll_assist = "always". Відома межа: за 35 дБ-Гц передавання відбувається через 1,9–2,6 с після початку відстежування, а за 33 дБ-Гц FLL на 10 Гц утримує PLI нижче порога передавання, тож втягування ніколи не завершується.
    • Нові ключі проєкту контурів та API:
      • [design.carrier]: fll_assist, fll_off_pli, fll_on_pli, fll_gate_dwell_s;
      • [design.lock]: reacq_window_s, reacq_interval_s, reacq_max_interval_s, де max_reacq_attempts змінено з типового значення 3 на необов'язкове обмеження (типово 0);
      • Rust: LoopConfig.fll_assist (FllAssist, FllGate), LoopCore::set_fll_enabled, EpochOutput.fll_active, ChannelSummary.final_state.
    • Хеш проєкту обчислюється за канонічною формою JSON, і хеш убудованого типового проєкту дорівнює 33261cd171a53803a6c262686e878e01f37d902a93d5918c20a44297b8ef8e80 (закріплено тестом).
    • Примітки щодо сумісності виводу:
      • таблиця iq track має кінцевий стовпець final_state;
      • CSV від iq sweep має кінцевий стовпець design_hash, а його JSON містить design_hash і warnings;
      • mean_cn0_dbhz перебору тепер є середнім за всіма оновленнями, що мають оцінку NWPR (підсумок з обмеженою пам'яттю), а не за другою половиною прогону.
    • Повторне захоплення вимкнено в убудованому типовому проєкті, де скінченний автомат лише спостерігає, а контури працюють біт у біт так само, як і без нього. (Проте самі типові контури змінилися: див. допомогу FLL вище.) Увімкніть його для окремого проєкту ([design.lock] reacquire = true), через --reacquire або через reacquire=True.
    • Попередження commensurate_sampling: коли fs лежить у межах 1e-6 від кратного половині чіпової швидкості (iq::track::commensurate_samples_per_chip), iq track/iq sweep (вивід, --summary, JSON перебору), відповідь MCP iq_track і результат Python iq_track попереджають, що тремтіння та зсув контуру коду нерепрезентативні. Першопричину задокументовано із заздалегідь зареєстрованими порогами в docs/design/evidence/dll-jitter/. Рівно за 2 відліки на чіп із відстанню 0,5 чіпа S-крива DLL є єдиною сходинкою, і контур дрижить: ≈ 0,09 чіпа середньоквадратичної похибки коду (≈ 26 м) за 45 дБ-Гц проти ≈ 0,004 чіпа за некомензурабельної швидкості. Занижене приблизно на 2 дБ значення NWPR C/N0 за такої швидкості має ту саму причину. За рівно 0 Гц доплера коду та 4 відліків на чіп код ніколи не перетинає мертву зону ±0,21 чіпа, тож зсув фази коду до приблизно 0,2 чіпа може зберігатися без прояву в тремтінні (виміряно: відстань 0,5 чіпа дає 2,0× похибки коду контрольного варіанта із середнім +0,011 чіпа; відстань 0,25 чіпа дає +0,125 чіпа); попередження охоплює цю швидкість.
    • Відома межа: типовий проєкт не передає керування від FLL до PLL нижче приблизно 35 дБ-Гц (поріг втягування ~35 дБ-Гц; див. допомогу FLL вище та docs/design/evidence/carrier-lock/).
    • Пошук хибного захоплення або повторного захоплення, який неможливо виконати (швидкість без цілого числа відліків на період коду), більше не зупиняє відстежування.
    • Тести: tests/iq_track_engine.rs, tests/iq_cli.rs, iq::track::design::tests, tests/python і повний цикл MCP IQ.

• Профілі C/N0 у синтетичних сценах (0.34.0). iq::channel::cn0_profile задає в сценах самого Kshana змінні в часі C/N0 для кожного супутника як зсуви в дБ відносно C/N0 сцени. Форми: сходинка, лінійне наростання, кускова лінійна функція та детерміновані (із зерном) завмирання Райса, подібні до сцинтиляцій, із заданими S4 і часом декореляції. Вони застосовуються через наявний гачок каналу сцени (Cn0ProfileChannel, у поєднанні з ефектами іоносфери, тропосфери, сцинтиляцій і багатопроменевості), без змін ядра сцени. cn0_dbhz супровідного файлу істини слідує за профілем.

  • Інтерфейси: kshana iq scene … --cn0-profile <toml> і kshana.iq_scene(…, cn0_profile="<toml>").
  • Для чого це потрібно: контури, монітори та оцінювання кампаній можна випробовувати на навантаження проти відомої істини. Воно змінює лише потужність законних сигналів.
  • Перевірки (tests/iq_cn0_profile.rs). Пороги: середня інтенсивність завмирань у межах 5 % від 1, S4 у межах 8 % від цілі (за S4 = 0,3, 0,7 і 1), кореляція інтенсивності понад 0,9 за 0,05 τ і нижче 0,05 за 5 τ; істина — точно заданий C/N0 плюс профіль; падіння відстежуваного NWPR C/N0 у межах 0,7 дБ від сходинки 6 дБ. Виміряно: S4 у межах 1,3 % від цілі та відстежуване падіння 6,26 дБ.

• Монітори виявлення на шляху IQ (0.34.0, «Lab replay»). Новий модуль iq::monitor, команда kshana iq monitor і прив'язка kshana.iq_monitor(path, ...). Вони спостерігають запис і повідомляють часові ряди та позначені події (час початку, тривоги та завершення, пік, поріг). Вони лише виявляють і вимірюють; ніщо тут не генерує сигнал.

  • Повна потужність / AGC: потужність блока та підсилення, яке застосував би ідеальний AGC; позначає зростання та спади.
  • Спектр до кореляції: PSD за Велчем для кожного блока проти вивченого базового рівня. Поріг перевищення виходить із цільового значення хибної тривоги. Також комплексний ексцес і детектор імпульсів. Детектор імпульсів рахує відліки понад порогом у кожному блоці та піднімає подію, коли точний біноміальний верхній хвіст цього числа нижчий за pulse_pfa (типово 1e-4 на блок), а не коли z-оцінка перевищує межу: за малих очікуваних лічильних значень коротких блоків один відлік уже становить кілька сигм.
  • C/N0 для кожного каналу: два односторонні детектори змін CUSUM (спад і зростання), що отримують незалежні оцінки (крок задається з вікна C/N0 контуру).
  • SQM за корелятори: різниця (I_E − I_L)/I_P і відношення (I_E + I_L)/(2 I_P), а також тести асиметрії за додатковими корелятори, коли канал їх надає.
  • Ряди індикатора захоплення: PLI та індикатор захоплення частоти за послідовними prompt-відліками, як необроблені сигнали. Рішення про захоплення та втрату захоплення залишаються за скінченним автоматом стану захоплення рушія відстежування.

  Один потоковий прохід (iq::monitor::run::run_monitors) виконує все з файлом параметрів TOML/JSON (MonitorConfig); виконавець кампаній використовує ту саму точку входу. Усе MODELLED. Кожну статистику перевірено проти її замкненої форми детермінованою (із зерном) симуляцією (tests/iq_monitor.rs):

  • перевищення потужності блока проти хвоста гамма-розподілу;
  • середнє ексцесу 2 і розкид 2/√N;
  • частка імпульсів e^{−t};
  • довжини серій CUSUM проти наближення Зігмунда (виміряно 330 і 8,46 відліку проти 338 і 8,34);
  • індикатор фазового захоплення проти середнього рисівської фази;
  • на відстежуваному сигналі C/A різниця та відношення SQM розходяться з замкненими формами першого порядку приблизно на 6 % (виміряно 5,97 %; поріг тесту 12 %).

  Формула хибної тривоги для спектрального перевищення є наближенням; виміряна частота становила 1,3× формули. Наскрізно монітори позначають:

  • сходинку C/N0 на 6 дБ (час зміни в межах однієї оцінки);
  • відбитий шлях, що з'являється посеред запису (тест відношення);
  • перерву сигналу (PLI падає з 0,999 до −0,3, а FLI з 0,93 до 0,03 під час неї);
  • вузькосмуговий тон і поодинокі відліки з великою амплітудою (спектральний тест, тест імпульсів і тест ексцесу). Це загальні тестові входи ЦОС, а не моделі завад.

Змінено#

• iq track/iq sweep працюють потоково через нову сесію (див. «Додано»).
  • --csv зберігає свої стовпці з 0,32, але тепер виводиться потоково, тож рядки кількох каналів чергуються в часовому порядку, а не групуються за каналами. --json зберігає свою форму з 0,32 і досі тримає в пам'яті кожну епоху: для довгих записів використовуйте --epochs.
  • iq sweep вимірює тремтіння за оновленнями другої половини тривалості прогону (раніше — за другою половиною кількості оновлень), а його CSV/JSON отримують стовпець design_hash.
  • Таблиця відстежування отримує стовпець final_state.
  • Текст довідки більше не стверджує, що iq track приймає прапорці вхідного каскаду; їх застосовує лише iq acquire.
  • Параметри acq_noncoherent і doppler_max у Python iq_track тепер типово дорівнюють None (значення проєкту, 1 і 5000 Гц в убудованому проєкті). Його епохи отримують ранні/пізні корелятори, carrier_phase_cycles, bit_edge, bit і state, а результат отримує design і events.

Виправлено#

• Типовий крок захоплення більше не передає відстежуванню Galileo E1 залишок, який FLL не може втягнути. Крок 2 / (3 · N · T_code) залишає до 1 / (3 · N · T_code) похибки доплера під час передавання, але типовий двоквадрантний FLL втягує лише 1 / (4 T_track). Для кожного коду тривалістю 4 мс або більше (N = 1), зокрема Galileo E1-B і E1-C, залишок (83,3 Гц за 4 мс) виходив за межі втягування 62,5 Гц, і відстежування хибно захоплювалося на +125 Гц, а індикатор фазового захоплення зі значенням 0,97 приховував це. Типовий крок тепер також обмежено значенням 0.2 / T_track (kshana::iq::acq::default_step_hz), тобто 0,8 від втягування, тож передавання залишається в його межах, навіть коли виграє сусідній біном. (Спершу пробували 0,4: це давало хибне захоплення в 1 прогоні з 42 на E1-B, а пошук GPS L1 C/A із когерентним накопиченням 1 мс обирав біном на 350 Гц осторонь і захоплювався на +500 Гц; 0,25 і 0,2 не дали жодного в тих самих прогонах.) Ціна: Galileo E1-B/E1-C переходять із бінів 166,7 Гц на біни 50 Гц, 201 бін на ±5 кГц замість 61; коди 1 мс (166,7 Гц, N = 4) не змінилися. "auto" у проєкті контурів означає саме це; явне doppler_step_hz або --doppler-step використовується як записано, а iq acquire (без передавання відстежуванню) зберігає підручниковий крок. Заголовок епохи та --summary тепер записують розв'язаний крок і смуги контурів для кожного каналу (resolved). Типовий хеш проєкту не змінився. Зміна виводу: виявлення на кодах тривалістю 4 мс і довше можуть потрапляти в інші доплерівські біни.

• GPS L2C CM (оновлення контуру 20 мс) утримує захоплення з типовим проєктом. Типові PLL на 15 Гц і FLL на 10 Гц мають Bn · T 0,3 і 0,2 за T = 20 мс, і контур втрачав захоплення навіть з ідеального старту (PLI −0,08, M2M4 15,8 дБ-Гц). Новий ключ проєкту carrier.bn_t_max (типово 0,1) обмежує шумові смуги PLL і FLL значенням bn_t_max / T, коли час оновлення контуру перевищує 4 мс (Design::loop_config_for): 5 Гц і 5 Гц за 20 мс, 10 Гц і 10 Гц за 10 мс BeiDou B1C; коди 1 мс і 4 мс зберігають 15 і 10 Гц. Це стосується й явно заданих смуг; bn_t_max = 0 це вимикає. Ключ пропускається в канонічній формі зі своїм типовим значенням, тож типовий хеш не змінюється; проєкт, що задає будь-яке інше значення, має інший хеш. За 45 дБ-Гц L2C CM тепер дає PLI 0,996, похибку доплера 0,00 Гц і M2M4 42,71 дБ-Гц. Відомий невирішений пункт: NWPR C/N0 там занижений на 1,76 дБ (і на 2,45 дБ на B1C за 10 мс), тож T5 матриці для L2C залишається проігнорованою знахідкою.

• docs/assets/clock-ensemble-band.svg згенеровано заново: закомічений рисунок застарів відносно власного сценарію (зміна даних, а не перемальовування). Діаграму було намальовано 2026-06-02 за scenarios/clock-ensemble.toml; через два дні 67fed19e задав у цьому сценарії пороги flicker-FM (квантовий flicker_floor = 1e-16, CSAC flicker_floor = 2e-11), а рисунок так і не перемалювали. Він показував прогін до порогів: вісь y від 0 до 47 нс, p95 перерви за прогін для CSAC від 10,5 до 47,6 нс (середнє 25,2 нс), класичний holdover 4050 с у середньому. Сценарій у постачанні (як уже зазначають підручник і підсумок CLI) дає вісь y від 0 до 407 нс, p95 за прогін для CSAC від 40,8 до 374,0 нс (середнє 167,0 нс), класичний holdover 844 с [220 до 2130 с]; лінія специфікації 20 нс лежить на тих самих 20 нс на приблизно в дев'ять разів вищій осі. Рушій не змінився: сьогоднішній рушій на червневому файлі сценарію точно відтворює вісь старого рисунка. На рисунок немає посилань у README чи в документації.

Відомі обмеження#

• NWPR C/N0 занижується за високого C/N0·T на prompt-відлік, а BOC(1 1) за 5 MS/s втрачає приблизно 1 дБ. NWPR є незміщеним на ідеальних prompt-відліках, але власне тремтіння PLL контуру коштує приблизно підігнаних 8 дБ × Bn·T (одна сцена, чотири точки: −0.24/−0.44/−0.77/−1,58 дБ за 1/2.5/5/10 Гц і 20 мс; близько −1 дБ за типового bn_t_max = 0.1); M2M4 нечутливий. Дані BeiDou B1C за 5 MS/s також втрачають близько 1 дБ потужності prompt через обмеження смуги (використовуйте 10 MS/s або більше). Жодне з цього не є дефектом оцінювача; рядки T5 матриці сигналів для GPS L2C і BeiDou B1C залишаються проігнорованими знахідками з цими причинами.

[0.33.1] - 2026-10-08#

Безпека#

• Захищено текст діаграм і прийняття діаграм у Studio. Текст, який сценарій переносить у згенеровану діаграму, тепер екрановано послідовно однією спільною процедурою, а Studio приймає з діаграми лише розмітку малювання. Адресні параметри Studio, пошуки за ключем виду та вибірки сценаріїв обмежено відомими значеннями. Убудовані діаграми, записані результати та опубліковані числа не змінилися. Оновлення рекомендовано всім, хто відкриває файли сценаріїв із недовірених джерел у Studio або вбудовує згенеровані діаграми у вебсторінки. Консультативне повідомлення: GHSA-h25h-cg9f-v2cg.

[0.33.0] - 2026-10-08#

Документація#

• Обсяг завад і спуфінгу в шарі IQ, викладений точно. Записи 0.31.0 і 0.32.0 нижче стверджують, що шар IQ додає «жодного синтезу сигналів завад чи спуфінгу». Це правильно щодо самого шару IQ (iq::scene генерує лише законні сигнали ГНСС), але це читалося як твердження про весь рушій, а це не так: починаючи з 0.29.0 секція [iq] виду spectrum записує знімок SigMF свого аналітичного моделювання з налаштованими глушниками в ньому (шумоподібні глушники — бін за біном, тони та чирпи — як сигнали), а spoof_capture підсумовує в пам'яті репліки автентичного сигналу й спуфера, щоб перевірити захоплення контуру (складений сигнал ніколи не записується). Рушій також містить програмний приймач ГНСС (GNSS) з 0.20.0 (sdr: захоплення та відстежування; з 0.31.0 також iq::acq і iq::track). Ніщо в Kshana нічого не передає і не керує радіообладнанням. Рядок стану в README, docs/POSITIONING.md, docs/SPECTRUM.md і примітки проєкту IQ тепер це зазначають; випущені записи залишено такими, якими їх опубліковано. Поведінка не змінюється.
• Відоме обмеження: комензурабельна дискретизація. За частоти дискретизації, що є цілим або напівцілим кратним швидкості чіпів, відліки припадають на ті самі фази чіпа в кожному чіпі, і дискримінатор коду стає сходинковим. На синтетичному сигналі GPS L1 C/A за 45 дБ-Гц із відстанню 0,5 чіпа 2,046 МГц (2 відліки/чіп) дає ≈ 0,09 чіпа (≈ 26 м) середньоквадратичної похибки коду та зсув −0,09 чіпа проти ≈ 0,003 чіпа за некомензурабельної швидкості. NWPR C/N0 там занижений на ≈ 2,4 дБ. За 4,092 МГц усе залежить від відстані та доплера коду. За 0,5 чіпа це нешкідливо за доплера 1500 Гц, але 2× із зсувом 0,011 чіпа за 0 Гц, а за 0,25 або 0,1 чіпа це 8–10× похибки коду. На відстежування несівної це не впливає. Виміри наведено в docs/design/iq-notes/receiver.md.

Додано#

• Шар GNSS IQ на сервері MCP (фаза B.1). kshana-mcp отримує шість інструментів, які керують шаром kshana iq з боку агента: iq_signals (допустимі назви сигналів і налаштування IQ), iq_info (опис запису), iq_scene (генерація сцени із заданим профілем або з бортових ефемерид, з необов'язковим каналом на рівні сигналу), iq_acquire (FFT-захоплення, за потреби після каскадів вхідної частини), iq_track (захоплення, потім банк DLL/PLL/FLL) і iq_frontend (смуговий фільтр, режекція, гасіння, вирізання, AGC, квантувач). Відліки IQ ніколи не проходять через протокол: кожен інструмент приймає шляхи до файлів усередині однієї робочої теки, заданої через KSHANA_MCP_IQ_DIR (якщо не задано, файлові інструменти IQ вимкнені, а решта інструментів не зазнає впливу), відмовляє в шляхах, що розв'язуються поза нею, і у виводах, які вже існують, якщо не задано overwrite, перед будь-якою роботою застосовує бюджет відліків на виклик (KSHANA_MCP_IQ_MAX_SAMPLES, типово 50 000 000), відмовляє в невідомих аргументах і відповідає стислим підсумком JSON (виявлення, C/N0, стан захоплення та кожен записаний файл з кількістю байтів). Вивід для кожної епохи йде лише у файли, які назвав викликач. Інструменти виконують той самий шлях коду, що й CLI, через новий публічний шов kshana::iq::cli::execute, який повертає повідомлення CLI замість його друку (stdout є каналом JSON-RPC MCP); iq::cli::build_code і iq::cli::signal_names тепер також публічні. Лише програмне та додаткове: шар IQ не додає синтезу завад чи спуфера, нічого ніколи не передається, і нових залежностей немає. server.json оголошує дві змінні середовища. Тести повного циклу в mcp/kshana-mcp/tests/iq_round_trip.rs генерують коротку сцену з двох супутників і перевіряють захоплення проти власного супровідного файлу істини сцени, захоплення відстежування та C/N0, вхідний каскад, вивід SigMF, бюджет, обмеження шляхів і вимкнений стан.

• Шар GNSS IQ у реєстрі валідації. Попередньо зареєстрована перехресна перевірка з gps-sdr-sim (незалежним генератором базової смуги GPS L1 C/A, MIT, коміт 28ca29a6) тепер входить до постійного набору тестів (tests/iq_gpssdrsim_cross_generator.rs). Її закомічений еталонний вивід (tests/fixtures/iq_gpssdrsim_cross_generator/: 20 мс власних 8-бітних I/Q gps-sdr-sim, перелік його каналів і стан каналів за ним із засобу, зібраного з тією самою збіркою) відтворюється через scripts/gen_iq_gpssdrsim_ref.sh. Під час тестування не потрібні ні мережа, ні зовнішній інструмент. Додано два рядки реєстру (251 рядок: 124 перевірено, 123 змодельовано, 4 партнерських):

  • Геометрія сигналу сцени GNSS IQ проти незалежного генератора базової смуги: перевірено. Істина сцени (видимий набір, псевдодальність, фаза коду, доплер, кути огляду) для сцени з бортовими ефемеридами збігається зі станом каналів gps-sdr-sim на всіх 11 каналах: найгірше 1,6 мм, 5.5e-6 чіпа, 7.4e-5 Гц, 4e-9 градуса, проти порогів 0,05 м, 2e-4 чіпа, 0,02 Гц і 1e-4 градуса, визначених до прогону.
  • Захоплення GNSS IQ на незалежно згенерованих відліках I/Q: обчислено за моделлю, зі знахідкою. iq::acq знаходить кожен змодельований супутник у відліках gps-sdr-sim у межах зареєстрованих порогів (фаза коду в межах 0,195 чіпа, доплер у межах 72 Гц). Проте зареєстрований поріг «жодного іншого PRN не виявлено» не виконується: на безшумовому виводі gps-sdr-sim поріг гаусового шуму перетинається взаємною кореляцією інших супутників для всіх 21 відсутніх PRN. Суворий тест збережено, проігноровано разом зі знахідкою, а закріплений тест її фіксує. Код рушія й публічний API не змінюються. Відліки I/Q не порівнюються відлік за відліком: цілочисельна таблиця синусів gps-sdr-sim, підсилення, нульова початкова фаза несівної та усічені поля LNAV не є величинами, щодо яких приймач мусить погоджуватися. Порівняння виконується за спостережуваними величинами, які вимірює приймач.

Змінено#

• iq track типово передає керування після захоплення ≈4 мс (зміна поведінки). Захоплення, що ініціалізує кожен канал відстежування, тепер когерентно інтегрує ceil(4 ms / T_code) періодів коду замість одного, де T_code — повний період коду (добуток довжин первинного та вторинного для багаторівневого коду, одиниця, за якою інтегрується захоплення). Безрівневі коди 1 мс (GPS L1 C/A, BeiDou B1I, GLONASS L1OF) тепер шукають за 4 періодами (4 мс), тож типовий доплерівський крок 2 / (3 · N · T_code) становить ~167 Гц замість ~667 Гц. Кожен код, повний період якого вже 4 мс або довший, зберігає 1 період: Galileo E1-B (4 мс), BeiDou B1C (10 мс) і багаторівневі GPS L5-I/L5-Q, Galileo E5a-I/E5a-Q та E1-C (від 10 до 100 мс з їхніми накладними кодами), а також GPS L2C. Тому кожен сигнал інтегрує щонайменше ~4 мс. Пошук за одним періодом міг передати канал із зсувом до ~333 Гц, поза межами втягування FLL, і тоді канал відстежував хибне захоплення на ~500 Гц осторонь, повідомляючи про чисте відстежування. На детермінованому (із зерном) перебірі з 180 каналів GPS L1 C/A (доплер у межах ±5 кГц, від 38 до 47 дБ-Гц, половина з навігаційними даними; docs/design/evidence/iq-track-acq-default/, можна повторити) хибні захоплення зменшуються з 27 із 180 до 1 із 180, а пропущені захоплення — зі 102 до 11, ціною ~40 мс додаткового пошуку на PRN на GPS L1 (11 → 52 мс). Єдине залишкове хибне захоплення — за 38 дБ-Гц, на 36 Гц осторонь. Усі інтерфейси погоджені: kshana iq track і kshana iq sweep (--acq-coherent), Python kshana.iq_track (acq_coherent=None тепер auto; заглушку оновлено) та інструмент MCP iq_track. Користувачі, які покладалися на старе типове значення, можуть передати acq_coherent=1 (--acq-coherent 1). Власне типове значення --coherent для kshana iq acquire залишається 1. Нові публічні iq::acq::auto_coherent_periods і iq::acq::AUTO_COHERENT_S; регресійний тест tests/iq_cli.rs::track_default_handoff_does_not_false_lock_where_one_period_did.
• Кожна згенерована графіка тепер відповідає темі Observatory сайту: байти кожної діаграми змінюються. Це свідома ревізія лише опублікованих рисунків, кольорів і шрифтів; жодне нанесене значення, координата чи підпис не змінилися. *.chart.svg кожного сценарію (а отже, експорти діаграм Studio та демонстраційні діаграми README), HTML-звіт прогону (*.report.html), анімація часової шкали (--animate), HTML-сторінки результатів сценарію та дослідження, підсумок валідації, а також рисунки та схеми документації використовували теплу темну липневу палітру (тло #0c0b08, золото #e0bd84) і теплу паперову тему звіту. Тепер вони беруть кожен колір і шрифт з одного модуля, src/palette.rs, який віддзеркалює web/theme.css: діаграми малюються в темному стилі приладу на тлі Observatory (#060A14) зі шрифтовим набором Geist; звіт, програвач анімації та сторінки результатів слідують за світлим/темним уподобанням глядача зі світлими й темними токенами Observatory. Шість доменів відмов зберігають по одному кольору (завади — кораловий, спуфінг — пурпуровий, синхронізація часу — синій, орбіти — блакитний, цілісність — лаймовий, навігація — бурштиновий), а рівні доказів читаються так: перевірено — лаймовий, змодельовано — бурштиновий, партнерський — пурпуровий. Рампи водоспаду зберігають свій перцептивний порядок (inferno), переприв'язаний до нового тла.
  • tests/palette_sync.rs утримує модуль у межах web/theme.css в обох темах, перевіряє, що docs/assets/palette.json і docs/diagrams/mermaid-config.json (обидва згенеровані з модуля, для інструментів рисунків Python і mermaid-cli) актуальні, і завершується невдачею, якщо шістнадцятковий літерал кольору з'являється в src/ поза палітрою.
  • tests/published_figures_still_reproduce.rs отримує третій діагноз, «змінилися лише кольори та шрифти», щоб ревізію палітри можна було відрізнити від зсуву нанесеного значення. Кожну перемальовану діаграму README перевірено на рівність її попередниці після цього нормалізатора.
  • tools/gen_validation_figures.py читає палітру і тепер також генерує три рисунки результатів README, які не мали закоміченого генератора (domain-coverage-map, scenario-fom, sgp4-regime-bars), зі справжніми текстовими елементами, з web/capabilities.json, результату clock-holdover і tests/fixtures/sgp4_comparison.md. tools/gen_readme_assets.py читає ту саму палітру, що виправляє її розбіжність зі світлою темою сайту. Значення sgp4-regime-bars — це стовпець найгіршого випадку kshana↔ref цього еталонного файлу (7.31e-9, 8.05e-9, 8.18e-9 і 4.12e-6 км), без змін щодо рисунка Matplotlib, і tests/figures_doc_sync.rs тепер завершується невдачею, якщо закомічений рисунок і еталонний файл розходяться.
• docs/assets/figures/domain-coverage-map оновлено до поточних даних (зміна даних, а не перемальовування). Рисунок стверджував про 28 можливостей у 8 доменах (11 перевірених, 17 змодельованих), що застаріло відносно його власного заявленого джерела; тепер, намальований новим генератором за web/capabilities.json, він показує 46 можливостей у 8 доменах (17 перевірених, 29 змодельованих).

Виправлено#

• Q для CW/вузькосмугового глушника тепер 1,0, а не 1,5. Підручникове значення для тону на несівній — 1 (тон зберігає спектральний пік сигналу, κ = T_c, Q = 1/(R_c κ)); старе значення 1,5 робило тон менш шкідливим, ніж широкосмуговий шум за однакового J/S. Зміна виводу: приблизно −1,8 дБ ефективного C/N0 за CW/вузькосмугових глушників за високого J/S у видах jamming, lunar-jamming та interop (тон убудованого прикладу spectrum: 17,98 дБ-Гц за таблицею, було 19,74). Q для широкосмугових залишається 1,0 (консервативно, приблизно на 3 дБ нижче підручникового ~2) до розгляду у 0,34. Задайте q_override, щоб зберегти старе 1,5.

• Цілочисельний вивід kshana iq scene використовує цілочисельний діапазон. З шумом одиничної потужності та масштабом записувача 1 сцени ci8/ci16 виходили приблизно як {-1, 0, 1}, а 2-бітні сцени мали пороги на 2,8 сигми. Цілочисельні формати тепер масштабуються так, щоб очікуване середньоквадратичне значення на компоненту становило чверть повної шкали (31,75 LSB у ci8, 8191,75 у ci16) або 2 LSB у 2-бітному форматі. Масштаб і кількість обрізаних елементів друкуються та записуються у супровідний файл. Вивід із плаваючою комою не змінився.

• Вісім еталонних значень у семи тестових файлах більше не падають на macOS через розбіжності в останньому біті (частина issue #36). Еталонні значення, що перевіряють, що рушій і далі будує закомічені вхідні дані оракула (якобіани, таблицю станів, азимути запуску), порівнювалися біт у біт і падали на macOS arm64 на 2–кілька тисяч одиниць в останньому розряді. Тепер вони порівнюють у межах 1e-12 від масштабу, взятого з еталонного файлу; цілі числа, ключі та довжини, як і раніше, порівнюються точно, а тест мутацій показує, що відносна зміна 1e-6 усе ще призводить до невдачі. Еталон азимута запуску порівнює sin az і гілку висхідної/низхідної траєкторії замість самого азимута, бо asin підсилює одну ulp свого аргумента приблизно до 3e-9 рад там, де нахил дорівнює доповненню широти майданчика. Жоден допуск оракула чи заздалегідь зареєстрований поріг не змінився. Два тести (спільне визначення орбіти для Місяця, спостережуваність для Місяця) не охоплено: на macOS самі їхні заздалегідь зареєстровані порівняння зсуваються, і це залишено на подальшу роботу.

• kshana iq track і kshana iq sweep застосовують прапорці вхідного каскаду. Текст довідки оголошував --bandpass/--notch/--blank/--excise/--agc/--bits для track, але track і sweep ніколи не будували ланцюжок: прапорці мовчки ігнорувалися, а прапорець без значення, як-от --notch, поглинав прапорець після себе. Обидві команди тепер розбирають їх так само, як iq acquire, і ставлять свіжий ланцюжок вхідного каскаду перед проходом захоплення та проходом відстежування. Вивід дорівнює запуску команди на файлі, який записує iq frontend за тих самих прапорців.

• Дані сцени IQ розміщуються окремо для кожного сигналу. kshana iq scene --data (і NavData::Seeded) ставили біти 50 біт/с на кожен сигнал, включно з пілотними, а на Galileo і BeiDou — зі швидкістю GPS LNAV. Тепер дані слідують власному таймінгу символів кожного сигналу, який задає новий SpreadingCode::data_modulation() (DataModulation, установлюваний кожним конструктором у iq::signals). Це 10 мс на L5-I5, 4 мс на E1-B, 2 мс на BeiDou B1I GEO (D2) і біти по 20 мс із меандром 10 мс на GLONASS L1OF. Дані відхиляються на пілотних сигналах, на GPS L2C як одному потоці CM/CL, а NavData::Lnav — на будь-чому, крім L1 C/A. Власні коди типово зберігають попередній таймінг 20 мс. Програмна Scene, що просила NavData::Lnav на коді, відмінному від L1 C/A, або NavData::Seeded на пілотному сигналі, раніше генерувала мовчки, а тепер повертає помилку при першому читанні.

• Канали GLONASS L1OF захоплюються й відстежуються на власній несівній FDMA. iq::acq::acquire і канали відстежування переносили кожен код униз лише від if_hz. Тому в багатоканальному записі GLONASS пошук каналу +3 знаходив сигнал каналу 0 (усі канали мають один далекомірний код) і ніколи не шукав на 1,6875 МГц вище. Обидва тепер використовують SampleSpec::baseband_hz(carrier) = if_hz + (carrier − center_hz). Доданок несівної дорівнює нулю для будь-якого запису, центрованого на власній несівній сигналу, і пропускається, коли центр невідомий, тож обробка CDMA не змінюється. Якщо ви обходили стару поведінку, вносячи carrier − center до if_hz супровідного файлу, приберіть цей доданок: зсув тепер застосовується з несівної та центру, тож залишений він застосується двічі. Відоме обмеження, яке тут не змінилося: сцена GLONASS ідентифікує кожен супутник за частотним каналом k, а ідентифікатор супутника u32 загортає від'ємний канал. Супровідний файл істини записує k = -7 як sat_id 4294967289 (k + 2^32). Прочитайте його назад як k з приведенням до i32.

[0.32.0] - 2026-10-05#

Додано#

• Шар GNSS IQ у CLI та Python (0.32.0, фаза A). Наявний модуль iq тепер придатний до використання без написання Rust. До групи обробки даних додаються п'ять нових команд kshana iq: scene генерує довгу багатосупутникову сцену IQ у файл із супровідним файлом істини; acquire виконує FFT-захоплення одного або кількох PRN у записі й повідомляє про кожне виявлення (PRN, доплер, фаза коду, статистика, поріг); track захоплює, а потім запускає банк DLL/PLL/FLL над записом і видає вивід відстежування для кожної епохи (CSV/JSON) з налаштовуваними смугами контурів, часом інтегрування та відстанню між корелятори; sweep відтворює один запис через кілька проєктів контурів і повідомляє отримані метрики тремтіння та захоплення для кожного проєкту; а labfit підганяє модель втрати захоплення контуру відстежування до часової шкали довіри до приймача. Те саме ядро відкрито для Python (kshana.iq_scene, iq_acquire, iq_track, iq_labfit, iq_signals), що повертає списки та словники, зручні для NumPy. Лише програмне та додаткове: без нових залежностей, без передавання, без синтезу сигналів завад чи спуфінгу; рушій, захоплення, відстежування та проєкти контурів належать самому крейту, тож виклик з CLI чи Python дає ті самі біти, що й тести Rust. Новий модуль iq::cli; власний супровідний файл істини сцени є незалежним оракулом у tests/iq_cli.rs (захоплення відновлює кожну введену фазу коду та доплер, відстежування збігається до введеного доплера). Жодна опублікована кількість видів сценаріїв чи рядок матриці верифікації не змінюється.
• Решта можливостей бібліотеки GNSS IQ у CLI iq та Python (0.32.0, фаза A.2). Продовжує фазу A, відкриваючи решту шару iq без написання Rust:
  • Канал поширення в iq scene (і в Python iq_scene): іоносфера першого порядку (--iono-stec/--iono-vtec або --iono-klobuchar), тропосфера Саастамоєна/Нілла (--tropo), модель сцинтиляцій Корнелла (--s4, --scint-tau0, --sigma-phi), дзеркальна багатопроменевість від землі (--multipath-height/--multipath-ground), трьохстановий канал наземного мобільного зв'язку (--land-mobile) і блок поза прямою видимістю (--nlos) застосовуються до кожного супутника через новий внутрішній міст крейту (iq::channel::SceneChannelAdapter), який перетворює абсолютні шляхи моделей каналу на форму сцени як надлишок над геометрією.
  • Вивід SigMF у iq scene (--format sigmf): записує відліки як пару .sigmf-data/.sigmf-meta із захопленням і анотаціями для кожного супутника; acquire/track уже читають SigMF, тож сцена проходить повний цикл.
  • ЦОС вхідного каскаду: нова команда iq frontend <in> <out> і ті самі прапорці в acquire/track (--bandpass, --notch, --blank, --excise, --agc, --bits 1/2/3/8/14) запускають каскади iq::frontend (смуговий FIR, адаптивний режекторний фільтр, гасіння імпульсів, вирізання в частотній області, AGC, квантувач); віддзеркалено в Python як iq_frontend.
  • Сцени з бортових ефемерид: iq scene --nav <rinex_nav> --rx-pos lat,lon,alt (з --start/--window/--prn) розміщує кожен справний супутник GPS у його справжній бортовій геометрії за допомогою зчитувача RINEX рушія, тож супровідний файл істини містить справжні дальність, доплер і фазу коду для кожного супутника; віддзеркалено в Python як iq_scene_broadcast. Лише програмне та додаткове: без нових залежностей, без передавання, без синтезу сигналів завад чи спуфінгу (ефекти поширення в каналі діють лише на законний сигнал). Кожне числове твердження перевіряється проти незалежного еталона (замкнена форма або введена істина) у модульних тестах каналу/вхідного каскаду та в tests/iq_cli.rs.

[0.31.0] - 2026-10-04#

Додано#

• Шар GNSS IQ: симуляція на рівні сигналу та обробка програмним приймачем. Новий модуль iq переводить Kshana від одного супутника й короткого блока вхідного каскаду L1 C/A до повного шару на рівні сигналу, доступного з групи команд kshana iq. Він генерує довгі багатосупутникові необроблені сцени IQ із супровідним файлом істини для кожної епохи (iq::scene); застосовує поширення на рівні сигналу — іоносфера з розходженням код–несівна, тропосфера, амплітудні та фазові сцинтиляції (модель Корнелла), багатопроменевість Френеля та трьохстановий канал наземного мобільного зв'язку, з відсутністю прямої видимості (iq::channel); захоплює та відстежує за допомогою FFT-захоплення і багатоканального банку DLL/PLL/FLL, відтворюючи один запис через багато проєктів контурів (iq::acq, iq::track); моделює вхідний каскад — фільтрація FIR/IIR, квантування від 1 до 14 біт, AGC, режекція, гасіння імпульсів і вирізання в частотній області (iq::frontend); потоково обробляє великі записані набори даних в обмеженій пам'яті — формати int8/int16/float32/запакований 2-бітний і дійсна проміжна частота, багатофайловий SigMF, передискретизація, інвентар набору даних із SHA-256 для кожного файлу та пакетний виконавець (iq::io); додає розширювальні коди для GPS L5/L2C, Galileo E1 (CBOC, справжні коди пам'яті ICD) та E5a, BeiDou B1C/B1I і GLONASS L1OF, кожен перевірений за своїм документом керування інтерфейсом (iq::signals); і підганяє модель втрати захоплення контуру відстежування до спостережуваної поведінки справжнього приймача в лабораторних прогонах, із похибкою відкладеного набору за схемою «виключення одного прогону» та екстраполяцією, позначеною як прогноз (iq::labfit). Кожне числове твердження перевіряється проти незалежного еталона (таблиця ICD, замкнена форма або незалежний приймач, що відновлює введену істину); фізичні моделі каналу та контурів залишаються MODELLED. Це лише програмний шар: він записує файли IQ для програмних приймачів і не синтезує сигналів завад чи спуфінгу та не керує радіообладнанням. Жодна опублікована кількість видів сценаріїв чи рядок матриці верифікації не змінюється. Проєкт: docs/design/GNSS-IQ-PLAN.md.
• Довіра до приймача: оцінювання журналу справжнього приймача ГНСС (GNSS). kshana receiver-trust <scenario.toml> читає журнал u-blox UBX, RINEX 3 (з необов'язковим файлом бортової навігації), Android GnssLogger або NMEA 0183 в одну часову шкалу з мітками часу та запускає над нею монітори довіри: падіння відношення потужності несівної до густини шуму (C/N0), втрату захоплення, автоматичне регулювання підсилення (AGC), індикатор глушіння u-blox, стрибок позиції та, з RINEX і навігацією, власне одноточкове визначення рушія з автономним контролем цілісності приймача (RAIM) за паритетом і монітор із підтримкою годинника. Кожна епоха є номінальною, погіршеною або недовіреною, а результат повідомляє, коли і чому. Події та прогнозовані падіння C/N0, указані в сценарії, оцінюються за допусками, указаними в тому самому файлі: виявлено, із запізненням або пропущено, а також збігається чи розходиться. Виводом є JSON результату, CSV для кожної епохи та діаграма; результат містить SHA-256 журналу та кожен поріг. Також доступно з Python (kshana.receiver_trust), пакета WebAssembly (receiver_trust, журнали вбудовані) і нового інструмента assess_receiver_log сервера Model Context Protocol (MCP). Посібник: docs/RECEIVER-TRUST.md; приклад: examples/receiver-trust/. На журналах спуфінгу JammerTest 2024 шлях рушія відтворює першу тривогу заздалегідь зареєстрованого конвеєра оракула на кожному опублікованому початку (tests/receiver_trust_jammertest.rs). Монітори залишаються MODELLED; жоден рядок матриці верифікації не змінюється.

0.30.0 - 2026-10-03#

Мінорний випуск. Раунд валідації 2 і пакети хвилі 1 переводять матрицю верифікації з 223 рядків (93 VALIDATED) на 0.29.3 до 249 рядків (123 VALIDATED, 122 MODELLED, 4 PARTNER); кожне підвищення перевірялося проти незалежного оракула із допуском, визначеним до прогону, і кожну розбіжність опубліковано як знахідку. Нове: власний зчитувач ядер NAIF і шлях DE440, один перевірений шлях поширення й часу від SGP4 до ITRS, бібліотека виміряних годинників, генератор еталона LunaNet AFS, розв'язувачі розширеної точності та інформаційні розв'язувачі з квадратним коренем, а також справжня обробка цисмісячного IQ на даних LuGRE. Опубліковані числа, що змінилися, перелічено нижче як ревізії.

Двадцять сім рядків матриці верифікації стають VALIDATED після того, як незалежний оракул погодився в межах допуску, визначеного до першого порівняння (правило підвищення в docs/VALIDATION.md): десять у першому раунді валідації та сімнадцять у другому. П'ятдесят один рядок MODELLED було піддано зовнішньому оракулу в першому раунді, а решту придатних до маршрутизації рядків — у другому; кожну розбіжність записано нижче як знахідку, а не підігнано. Три рядки було розділено, щоб перевірена частина не несла неперевіреного залишку, що переводить матрицю з 223 на 226 рядків; пакети валідації, долучені відтоді, переводять її на 249. Кількості прочитано зі згенерованого docs/VERIFICATION-MATRIX.md.

Скорочення, використані в цьому записі

Скорочення	Значення
ADD, ARAIM, MAAST	Airborne Design Document (для ARAIM); розширений автономний контроль цілісності приймача; Matlab Algorithm Availability Simulation Tool Стенфордського університету
ADEV, VRW, ARW	девіація Аллана; випадкове блукання швидкості; випадкове блукання кута
ANISE, SPICE, NAIF, PCK	відкритий інструментарій астродинаміки (Nyx Space); інструментарій NASA Spacecraft, Planet, Instrument, C-matrix, Events від його Navigation and Ancillary Information Facility; ядро планетарних сталих
BCRS, TDB, TT	барицентрична небесна система відліку; барицентричний динамічний час; земний час
BIPM, UTC(k)	Міжнародне бюро мір і ваг; реалізація всесвітнього координованого часу окремою лабораторією
CCSDS, OEM, LTC, TCL	Консультативний комітет із космічних систем передавання даних; повідомлення про ефемериди орбіти; місячні системи часу, записані в полі TIME_SYSTEM повідомлення
CRLB	нижня межа Крамера–Рао
CW	відносний рух Клохессі–Вілтшира
DE440	Development Ephemeris 440 Лабораторії реактивного руху
DOP, PDOP	геометричний чинник (погіршення точності); геометричний чинник для позиції
EKF, UKF, INS, GNSS, IMU	розширений фільтр Калмана; ненаближений (unscented) фільтр Калмана; інерціальна навігаційна система; глобальна навігаційна супутникова система; інерціальний вимірювальний блок
EMT, VPL, HPL	ефективний поріг монітора; вертикальний і горизонтальний рівні захисту
EOP, IERS, PCC, MAE	параметри орієнтації Землі; Міжнародна служба обертання Землі та систем відліку; Prediction Comparison Campaign; середня абсолютна похибка
ERFA, SOFA	Essential Routines for Fundamental Astronomy; Standards of Fundamental Astronomy
GMAT	General Mission Analysis Tool від NASA
NTN, SSB	нетерестріальна мережа (3GPP); блок сигналів синхронізації
IGS, ILRS, ITRF2020	Міжнародна служба ГНСС (GNSS); Міжнародна служба лазерної локації; Міжнародна земна система відліку 2020
ILS, LAMBDA	цілочисельний метод найменших квадратів; Least-squares AMBiguity Decorrelation Adjustment
ISB	міжсистемне зміщення
LEO	низька навколоземна орбіта
MHSS, PL, TPL	розділення розв'язків за множиною гіпотез; рівень захисту; рівень захисту часу
PSD, IQ, SigMF	спектральна густина потужності; синфазні та квадратурні відліки; Signal Metadata Format
QPN	квантовий проєкційний шум
RAIM	автономний контроль цілісності приймача
SBAS, WAAS, DFMC, GEO	супутникова система функціонального доповнення; американська Wide Area Augmentation System; двочастотна багатоугруповальна; геостаціонарний супутник SBAS
RMS, SISRE	середньоквадратичне значення; похибка дальності сигналу в просторі
RTKLIB	відкрита бібліотека позиціонування ГНСС (GNSS)
TCXO	кварцовий генератор із температурною компенсацією
VLBI	радіоінтерферометрія з наддовгою базою

Validated#

Кожен рядок нижче називає вид свого оракула (Library: незалежна стороння бібліотека, що обчислює однозначно визначену величину; Measured: справжні виміряні дані; P2: незалежна числова бібліотека, що перераховує величину лінійної алгебри на закомічених вхідних даних), сам оракул, допуск, визначений до прогону, і результат. Кожне підвищення повторно виконав другий рецензент, який відтворив еталонний файл байт у байт і показав, що навмисна мутація рушія робить тест червоним.

• Злиття датчиків GNSS/INS (Library), обмежене слабо зв'язаним 15-станним EKF станів похибки: NaveGo v1.4 (LGPL-3.0, запущений під GNU Octave) на власному справжньому проїзді Ekinox IMU/GNSS. Горизонтальне, вертикальне та інноваційне за позицією середньоквадратичні значення Kshana становлять 0,912, 0,940 і 0,861 від значень NaveGo (поріг 1,2), а його середня нормалізована інновація — 0,395 (поріг 1,5). GNSS присутній протягом усього проїзду, тож перерву не перевірено. Щільно зв'язаний UKF і зв'язаний фільтр годинника лишаються поза твердженням.
• 3-DOF-орієнтація та бюджет похибки наведення (Library), звужено до піка гравітаційно-градієнтного моменту: Basilisk 2.9.1 GravityGradientEffector, 40 випадків, у межах 1e-12 відносно (найгірше 2.1e-15). Бюджет наведення RSS є сумою чисел, наданих викликачем, і лишається поза цим.
• Спільна геометрія зв'язку та навігації для Місяця (Library), звужено до розміщення майданчика, азимута, висоти та дальності: ANISE 0.10.2, 768 відліків, у межах 1e-6 град. і 1 мм (найгірше 2.2e-12 град. і 5.6e-9 м). Параметр точності далекометрії є вхідним параметром проєкту поза твердженням.
• Динаміка орієнтації твердого тіла без моментів (Library): корпус космічного апарата Basilisk 2.9.1, 1e4 с на двох загальних тензорах інерції, кватерніон і швидкості в межах 1e-9 (найгірше 3.3e-11 і 3.4e-12 рад/с).
• Розв'язання цілочисельних неоднозначностей фази несівної ГНСС (GNSS) (LAMBDA) (Library), звужено до розв'язку ILS і двох його найкращих норм: RTKLIB v2.4.2-p13 lambda(), 300 коваріацій, 0 цілочисельних розбіжностей, норми в межах 1e-9 відносно (найгірше 5.6e-13). Частота успіху методу bootstrapping лишається перевіреною лише всередині.
• Складений PL часу, скалярний MHSS (P2): numpy 2.3.5 і scipy 1.18.1 на 300 закомічених вхідних даних, PL у межах 1e-9 відносно (найгірше 1.2e-10), керівна підмножина ідентична.
• Вибілювання спільної моди GLS і тотожність Махаланобіса (P2): numpy 2.3.5 LAPACK на 201 закомічених коваріацій, у межах 1e-12 відносно (найгірше 7.9e-16); числа обумовленості до 19,3.
• Постачальник орієнтації місячних головних осей DE440 (Library): SPICE pxform на двійковому PCK на 2 000 епохах поза вузлами, у межах 1.7e-5 рад (найгірше 1.7e-6 рад, близько 3 м на поверхні), після виправлення, переліченого в розділі «Виправлено».
• Вхід і вивід записів SigMF та спектри Велча (Library), звужено до читання й запису SigMF та welch_psd: scipy 1.18.1 signal.welch у межах 1e-12 відносно на бін (найгірше 6.0e-14); записи sigmf-python 1.13.0 декодовано побітово ідентично; метадані крейту дійсні відносно схеми SigMF v1.2.6. Синтез IQ та його порівняння моделей лишаються поза цим.
• Підганяч бортових ефемерид LEO та SISRE залежно від інтервалу підгонки (Measured), звужено до 16-параметричної кеплерівської підгонки та її SISRE лише за орбітою: точні орбіти TU Graz ITSG чотирьох супутників проти статистики Liu et al. 2025, компоненти в межах 1,5× (0,804–1,087) і SISRE в межах 1,5× (0,716–0,809).

Знахідки#

Оракул не погодився з цими рядками, тож вони лишаються MODELLED. Кожну знахідку також записано в текст оракула рядка (а отже, і в docs/MODELLED-RATIONALE.md), із тестом, який її закріплює.

• Оцінювання стану бортового годинника: на відкладених годинниках IGS 11 супутників GPS Block IIF тристанний фільтр узгоджений на один крок уперед, але надмірно впевнений через одну годину на 9 з 11 (періодичні та фліккерні складові не входять до моделі).
• Виявлення спуфінгу: на JammerTest 2024 жоден монітор на рівні спостережень не спрацював протягом 10 с після жодного з 8 опублікованих початків, а три вікна перед початком містили хибні тривоги.
• Рівень захисту часу за спуфінгу: виміряна невиявлена похибка часу перевищує TPL на 3 з 8 виявлених початків (від 1,9× до 5,3×); калібрування годинника за 60 с не покриває блукання TCXO приймача.
• Вікно запуску та геометрія виведення: проти Orekit 12,2 геометрія збігається з точністю до округлення, але швидкість майданчика від обертання Землі не відповідає з відносною похибкою 1e-6 на широті 62,9 град. (1.12e-6, рух полюса, який сферична модель опускає). Раунд 2: швидкість за справжнім полюсом з епохою збігається, типова швидкість без епохи все ще не відповідає (див. нижче).
• Балістичний коридор входу в атмосферу (Аллен–Еггерс): прогнозоване пікове гальмування для входу Stardust становить 61,8 g проти відновлених 32,89 g (+88 %, допуск 15 %).
• Спільна похибка UT1 і руху полюса: проти формули точності, надрукованої у 178 випусках Bulletin A IERS, полюс збігається в межах 1,5×, а UT1 — ні (0,48 за 10 діб, 1,59 за 40 діб). Замінено в раунді 2: рядок тепер VALIDATED (див. нижче).
• Типовий офлайн-вхід параметрів орієнтації Землі: astropy підтверджує підрахунок рядків, але 12 рядків, які крейт називає прогнозами Bulletin A, позначені як виміряні (I), а не як прогнозні (P). Тому цифри збігу в рядку оперативного предиктора стосувалися виміряних рядків. Замінено в раунді 2: рушій класифікує рядки за прапорцем, і рядок VALIDATED.
• Похибка прогнозу орієнтації Землі в оперативному стилі: похибка UT1 предиктора становить від 2.4× до 12.6× похибки Bulletin A за 1–10 діб і 5,32 мс за 10 діб, що поза діапазоном 0,36–3,13 мс 2-го EOP PCC.
• Місячна геодезична VLBI: проти світлових часів ANISE через DE440 жодна затримка не лежить у межах 1 пс; найбільша розбіжність — 24 мкс, переважно через аналітичний центр Місяця (близько 200 км від DE440). Раунд 2: шлях через ядра VALIDATED в окремому рядку; цей аналітичний шлях лишається MODELLED.
• Експорт для взаємодії на Місяці: Orekit 12,2 відмовляється від систем часу LTC і TCL, тож обмін місячними файлами OEM з другим читачем не встановлено.
• Відносний рух Клохессі–Вілтшира: проти нелінійного руху Orekit на 100 м розбіжність становить від 1,2 до 6,3 мм, понад 1 мм; вона масштабується як пропущений член другого порядку, тож заздалегідь зареєстрований допуск лежав нижче похибки лінеаризації. Замінено в раунді 2: поправка другого порядку VALIDATED проти того самого порогу.
• Зростання похибки інерціально-рельєфної навігації в режимі інерційного руху: проти вільно-інерціального Монте-Карло NaveGo закони зростання тримаються в межах 5 % до 600 с і завищують далі (від 2.2× до 8× за одну годину), бо опускають зворотний зв'язок Шулера. Замінено в раунді 2: модель похибки Шулера VALIDATED.
• Місячний обсяг обслуговування за справжньою геометрією угруповання: 4 з 12 опублікованих статистик доступності розходяться більш ніж на 2 процентних пункти (до 22,5).
• Верхня межа зміщення простежуваності гетерогенних UTC(k): на 105 024 рядках BIPM верхню межу перевищено в 50,8 % рядків; опублікована невизначеність обмежує вимірювання зміщення в BIPM, а не саме зміщення.
• Класифікація нуль-простору датума Місяця: на опублікованій геометрії з п'яти відбивачів кореляція становить -0.78 проти -0.97, а CRLB початку координат на 96–98 % нижча за наведену в статті.
• Підложка геометрії датума місячної LLR: проти 192 нормальних точок ILRS для Місяця за 2024 середньоквадратичний залишок в один бік становив 96 м з попередньою інтерполяцією орієнтації й становить 22,7 м після виправлення нижче, усе ще понад порогом 10 м (округлені координати станцій, без руху полюса). Ряд орієнтації мовчки обрізається поза 2024-2025. Раунд 2: модель виміряної дальності VALIDATED в окремому рядку (2,81 м); ряд тепер охоплює 2014-2030 і видає помилку поза ним.
• Зв'язок релятивістської швидкості годинника з системою відліку: член власного потенціалу на 3.18e-4 вищий за опубліковане значення (допуск 1e-4); стаття обчислює інший потенціал, тож опублікованого значення цієї замкненої форми не існує. Замінено в раунді 2: екваторіальний потенціал ступеня 2 VALIDATED проти тієї самої статті.
• Фізичні сталі кожного тіла Сонячної системи: 12 з 84 сталих доданих тіл розходяться з NAIF pck00011 і gm_de440 (старіші елементи супутників Марса; інші розв'язки GM для Урана, Нептуна та Плутона). Раунд 2: сталі тепер слідують NAIF (транскрипція, не враховується), а обчислена орієнтація збігається зі SPICE; рядок лишається MODELLED.
• Вибірні моделі ефемерид LEO: 22-параметрична підгонка лишає 1.71× і 1.86× опублікованої похибки вздовж треку на дугах 20 хв, понад 1.5×. Замінено в раунді 2: 22-параметрична модель і підгонка VALIDATED в окремому рядку.
• Спільне позиціонування GNSS і LEO: міжсистемне зміщення збігається з RTKLIB, але 93,2 % епох лежать у межах 3 м від ITRF2020 проти 95 %; сам RTKLIB досягає 88,2 % на цих даних (93,6 % після виправлення групової затримки в раунді 2).
• Сліпота цілісності до спільної моди і карти покриття та DOP: обидва порівняння пройшли, але їх відхилено під час перегляду, бо навмисно хибний рушій їх теж проходить (перше перевіряє лише внутрішню тотожність; опубліковані мінімуми другого не бачать подвоєного PDOP). Раунд 2: сліпота цілісності до спільної моди VALIDATED на входах із паритетом; карти покриття лишаються знахідкою (див. нижче).

Раунд валідації 2#

Другий раунд охопив кожен рядок, який перший раунд лишив придатним до маршрутизації, зі свіжими попередніми реєстраціями, закомічченими до того, як було отримано будь-який еталонний файл чи запущено будь-який оракул, змагальним другим рецензентом, який повторно виконав кожне порівняння, і навмисною мутацією рушія, що мусить зробити кожен тест червоним. Власник прийняв виправлене формулювання рядка про межу поза Omega 2026-10-02 до його підвищення (старий текст суперечив коду).

Підвищено до VALIDATED (17). Вид оракула в дужках; допуск визначено до прогону.

• Зв'язок релятивістської швидкості годинника з системою відліку (Reference): L_m з Ashby і Patla 2024 у межах 2.8e-6 (поріг 1e-4) за екваторіальним потенціалом ступеня 2 двох полів, які цитує стаття; гравітація pyshtools ступеня 350 для радіального входу (8.3e-5); місячна швидкість DE441 (2.5e-3).
• Типовий офлайн-вхід параметрів орієнтації Землі (Library): astropy 8.0.1 і IERS Bulletin A № 039 підтверджують 30 остаточних, 54 швидких і 90 прогнозних рядків заново нарізаного витягу.
• Спільна похибка UT1 і руху полюса (Library): повні обертання astropy і pyerfa відтворюють спільну таблицю (UT1 і полюс у межах 6e-16, комбінація в межах 1.9e-7); реалізовані похибки з IERS Annual Report 2019 дають відношення від 1,001 до 1,100.
• Слід і покриття корисного навантаження EO (Library): Orekit 12,2 і GeographicLib 2,1 на кожному заздалегідь зареєстрованому порозі, з вековою регресією вузла J2, тепер урахованою в інтервалі між вузлами.
• Відносний рух Клохессі–Вілтшира (Library): із замкненою поправкою другого порядку, у межах 1.2e-7 м від нелінійного руху Orekit проти 1e-3 м; лише лінійна матриця лишається охарактеризованою (від 1,2 до 6,3 мм).
• Націлювання в B-площині та гравітаційний маневр у наближенні зістикованих конік (Library): B-площина GMAT R2026a, асимптоти, C3 і геліоцентричні елементи; sbpy 0.6.0 і Kasuga та Jewitt 2019 для параметра Тіссерана.
• Зростання похибки інерціально-рельєфної навігації в режимі інерційного руху (Library): дев'ятистанна модель похибки Шулера в межах 5 % від виправлених прогонів інерційного руху NaveGo в усіх 48 точках (найгірше 3,70 %).
• Сліпота цілісності до спільної моди (P2): numpy lstsq на 1464 входах із паритетом у межах 1e-12 (найгірше 1.06e-14).
• Спільне багатотехнологічне визначення орбіти та годинника для Місяця (P2): numpy перераховує кожен крок Гауса–Ньютона, сигму та похибку станції на шести мережах (у межах 2.4e-11) після виправлення розв'язку QR.
• Коваріація координат станцій місячної VLBI (Library): якобіан, побудований за SPICE, відтворює розклад, спектр, сигми та нуль-простір у межах 1 % і 0,1 град.; numpy до 2e-13.
• Невиявлювана межа спільної моди для залишку поза Omega (P2, формулювання виправлено рішенням власника): numpy LAPACK на 256 випадках у межах 1e-12, шість точних нескінченностей.
• Інваріантна до базису класифікація нуль-простору (P2): перетин підпросторів SciPy і NumPy на 72 сконструйованих матрицях, цілі числа точні, норма проєктора в межах 6.0e-15.
• Одночастотні іоносферні та UTC-послуги навігаційного повідомлення LEO (Library): GNSSTk 15.3.1 для Klobuchar, азимута та дрейфу UTC; ERFA для трьох випадків високосної секунди.
• Межа позиціонування 5G нетерестріальної мережі (P1): межі одного SSB за Bachl, Lei і Nabeel 2026 у межах половини надрукованої цифри; numpy для коваріацій визначення позиції.
• Модель виміряної дальності LLR (Measured, новий рядок, відокремлений від підложки датума LLR): 192 нормальних точок ILRS для Місяця з 2,81 м RMS проти порогу 10 м, з барицентричним світловим часом IERS 2010; складові нижче порогу не розв'язуються по одній, і рядок про це прямо каже.
• Місячна геодезична VLBI, шлях через ядра (Library, новий рядок, відокремлений від рядка місячної VLBI): збіжні світлові часи SPICE у межах 1 пс і частинні похідні в межах 1e-6 на епохах поблизу J2000; типовий аналітичний шлях лишається MODELLED.
• 22-параметрична модель ефемерид LEO за Liu et al. 2025 та її підгонка (Measured, новий рядок, відокремлений від рядка вибірних моделей): справжні точні орбіти в межах 1.5× опублікованої статистики на днях зі статті та відкладених днях (від 0,683 до 1,186); конвенцію масштабу n_dot транскрибовано й цим порівнянням не перевірено, а правило зупинки — це правило збіжності параметрів Kshana, а не правило зміни RMS зі статті. Поліном ATOMIC і таблиця п'яти висот лишаються MODELLED.

Наявні рядки VALIDATED перепідкріплено (кількість не змінюється).

• Положення планет за елементами JPL Standish і світловий час між тілами Сонячної системи: апостеріорні подвоєні номінальні пороги замінено заздалегідь зареєстрованими порівняннями з JPL Horizons DE441 (RMS не більше значення з Explanatory Supplement, таблиця 8.10.1, найгірше 0,778, з урахуванням розділення Землі та обертання ICRF; світлові часи в межах 1e-6 с від Horizons на позиціях DE441, найгірше 6.7e-9 с). Їхні позначки «межу встановлено після порівняння» прибрано.
• Цілісність (RAIM/ARAIM/SBAS): рядок більше не спирається на перевірки правдоподібності. Тепер він стверджує: розділення розв'язків за множиною гіпотез ARAIM з ADD v4.2 збігається зі Stanford MAAST для ARAIM 2 на 270 справжніх випадках (найгірша різниця VPL 2.2e-3 м проти 0,05 м); виявлення та виключення за миттєвим RAIM збігаються з RTKLIB raim_fde у 2016 з 2016 рішень, а рівень захисту за нахилом — у межах 2.7e-12 м; рівні захисту SBAS DO-229E L1 збігаються зі Stanford MAAST на справжніх трансляціях WAAS (2868 пар у межах 1.6e-5 м). Він прямо зазначає, що функції з однорідною сигмою raim::araim_raim і raim::araim_dual_raim НЕ узгоджуються з ADD (розбіжності за узгодженого входу 0.75/4.04 м і 0.39/1.93 м VPL/HPL, знахідка), що порівняння DFMC L5 SBAS є знахідкою (308 пар без GEO у видимості захищає Kshana, а MAAST ні) і що для raim::solution_separation_raim зовнішнього порівняння немає. Його самопозначку прибрано.
• Підганяч бортових ефемерид LEO: інтегровану істинну орбіту додано до перевіреної частини (Orekit 12,2 у межах 4,55 мм за 6 год, поріг 2 см); поліноми поправок, підгонка годинника та компроміс щодо періоду оновлення лишаються змодельованими.

Знахідки та заблоковані рядки (лишаються MODELLED). Текст оракула кожного рядка містить знахідку та її закріплений тест.

• Модуляція навігаційних сигналів (Betz 2001, Hein 2006): спектри та кореляції збігаються; бічні пелюстки 24 МГц і кожне зміщення від багатопроменевості (на 11–15 % менше) — ні, причину не з'ясовано.
• Геолокація TDOA/FDOA: межі збігаються з Ho і Chan та Ho і Xu, а також з кодом авторів до 3e-12; коефіцієнти Оттави, надруковані за Монте-Карло, розходяться на 1,3 % і 4,4 %.
• ГНСС Землі на місячній відстані: середні в зеніті GENESIS збігаються з Montenbruck et al. 2023 у 5 з 6; середні в надирі вищі на від 1,0 до 2,4 супутника.
• Карти покриття та DOP: проєкти для Землі збігаються з Orekit, gnss_lib_py і numpy на кожному порозі; проєкти для Місяця та Марса перевищують 1e-9 лише на майже сингулярних комірках.
• Спільне позиціонування GNSS: двочастотне 79,9 % і за точними продуктами 94,2 % у межах 3 м проти 95 % (RTKLIB 67,9 % і 94,1 %); розбіжність ISB за точними продуктами — це те, що RTKLIB ігнорує зміщення антен.
• Контури відстежування (GNSS-SDR 0.0.19): збігаються за 35–45 дБ-Гц; за 30 дБ-Гц PLL +21 %, DLL -32 %, пороги +1,5 дБ; часи проковзування коротші на від 0,5 до 2 декад.
• Місячний обсяг обслуговування (Orekit і Hipparchus): 155 зі 160 значень збігаються; вимога найгіршого відліку не виконується на майже сингулярній геометрії LNCSS B.
• Квантовий інерціальний датчик: поріг лише за QPN на від 21 до 31 % нижчий за виміряний шум Gauguet 2009 (поріг 30 %, не досягнуто на 0,5 пункту).
• Пресети генераторів: виміряні блоки перевищують пресети holdover рубідію, короткострокового цезію та найгіршого блока CSAC; для пресета OCXO виміряного запису немає.
• Густина космічної погоди: Jacchia 1971 у межах коефіцієнта 2 від густин за акселерометрами в максимумі Сонця, але приблизно в 1.7 раза щільніша в мінімумі 2008.
• Косий TEC без геометрії: 33 з 36 дуг у межах 3 TECU від карти CODE (найгірше 6,84).
• Виявлення спуфінгу та TPL проти офіційного журналу JammerTest 2024: 4 з 10 початків виявлено вчасно; TPL перевищено в 4 з 10.
• Фільтр годинника на свіжих годинниках IGS: два з 11 супутників не відповідають критерію суми інновацій.
• Предиктор EOP за методом найменших квадратів з авторегресією: UT1 від 1,73 до 2.11× Bulletin A за 2–10 діб.
• Верхня межа реалізованого зміщення UTC(k): сукупне перевищення 0,0333 проти 1e-2.
• Датум місячної системи відліку з кампанії: гілка SPICE збігається; гілка P2 з оцінюваними станціями не досягає 1e-9 на задачі з числом обумовленості 2.1e8.
• Датум місячної системи відліку зі справжньої LLR: 15 з 16 показників збігаються зі SPICE; сигма z-зсуву на 1,03 % висока проти 1 %.
• Вхід в атмосферу (Аллен-Еггерс): розв'язок для матеріальної точки збігається з реконструкціями агентств (лише перехресна перевірка); порівняння з акселерометром заблоковане через відсутність читабельного джерела Hayabusa2.
• Маски ITU-T: надруковані розв'язані значення збігаються; для граничних значень класів G.8273.2 їх немає (заблоковано).
• Геометрія вікна запуску: швидкість майданчика за справжнім полюсом з епохою збігається з Orekit (4.9e-8); типова швидкість без епохи все ще не відповідає (1.12e-6). Не підвищено; подальша робота очікується.
• Фізичні сталі кожного тіла: тепер 0 з 84 розходяться з NAIF (транскрипція), а обчислена орієнтація збігається зі SPICE до 1.4e-10 рад. Не підвищено; подальша робота очікується.
• Заблоковано рішенням власника щодо обсягу, кожне із закомічченим узгодженим порівнянням: спостережуваність абсолютних станцій на Місяці, DOP поверхневих маяків, експорт поза віссю, потужність виявлення між модальностями, статистика узгодженості спільної моди та полярне покриття LEO.
• Заблоковано даними: бюджетування похибки передавання часу (потрібне зведення справжніх даних), C/N0 JammerTest (положення антени та розподіл потужності не задокументовано).

Ревізії (опубліковані числа, що змінилися, старе -> нове).

• Рівні захисту snapshot_raim тепер задано на геодезичному локальному рівні замість радіального: до 0,31 м HPL і 0,14 м VPL на ABMF (16 град. пн. ш.); жоден еталонний файл не змінився, але записаний підсумок підручника gnss-sim змінюється із середнього HPL 22,1 м / VPL 40,0 м на 22,2 м / 39,9 м (docs/tutorials/scenarios/gnss-sim.toml).
• Типові значення зв'язку місячної системи відліку за швидкістю: d_alpha/d_scale 3.139807e-11 -> 3.138801e-11; d_alpha/d_radial 1.807187e-17 -> 1.806185e-17 на метр.
• Типовий офлайн-прогін EOP (realtime-frame-eop, комірки перелічено в docs/revisions/M035-default-eop-recut-cell-changes.md): predicted_rows 12 -> 90; поріг полюса 0,06776 -> 0,05550 мсд; eop_term_m 14,01601 -> 14,01583; total_m 20,09759 -> 20,09746; total_time_ns 67,03834 -> 67,03790; рядки таблиці 2 у tests/golden/realtime-frame-eop.csv; збіг оперативного предиктора 0.256/0.695/1.252/3.885 мс -> 0.133/0.421/0.839/2.786 мс.
• docs/LEO-NAVMSG.md liu22 SISRE орбіта/з годинником: 60 с 0.011/0.046 -> 0.014/0.046 см; 300 с 0.068/0.139 -> 0.074/0.142 см; 600 с 0.269/0.299 -> 0.258/0.290 см.
• Таблиця висот Liu, Kshana (відношення): GRACE-A 5,40 (0,61) -> 4,25 (0,48); GRACE-C 4,12 (0,66) -> 2,87 (0,46); Sentinel-2A 2,95 (1,03) -> 2,20 (0,77); HY-2A 2,38 (1,13) -> 1,25 (0,59); Sentinel-6A 0,70 (0,94) -> 0,51 (0,67).
• Масштаб nDot навігаційного повідомлення LEO 2^-60 -> 2^-58 (не зареєстровано заздалегідь, розкрито; поза порівнянням підгонки); CRC кадру зразка liu22 0x62373A -> 0xDED99C.
• Таблиця верифікації docs/LEO-NAVMSG.md: рядок Liu та ATOMIC розділено на 22-параметричний рядок VALIDATED і рядок ATOMIC та п'яти висот MODELLED.
• Текст рядка орієнтації місячних головних осей DE440: проміжок 2024-2025 / 731 рядків -> 2014-2030 / 6 209 рядків; «мовчки обрізається» -> помилка поза його проміжком.
• Сценарій eo-coverage: equatorial_ground_track_spacing_km 2756,37 -> 2752,17 км; нові поля inclination_deg (98,19) і nodal_period_min (98,893).
• constellation-multi-gnss-coverage (еталонний годинник TDOP/GDOP тепер угруповання з найменшим номером у видимості): глобальний GDOP макс. 2,2236 -> 2,1205, середнє 1,122 -> 1,131, медіана 1,115 -> 1,125, p90 1,255 -> 1,265, p95 1,305 -> 1,315, p99 1,41 -> 1,42 і карта GDOP для кожної комірки; mean_visible_by_constellation підсумовано як цілі числа (близько 1e-12 відносно, непомітно за 4 десяткових знаків).
• Спільне одночастотне визначення GNSS після виправлення групової затримки бортової передачі: 93,2 % -> 93,6 % у межах 3 м; медіана ISB -0.351 -> -0.114 нс.
• tracking-loop jitter_table log10_mean_time_to_cycle_slip_s (контур Костаса, ВСШ rho/4): на порозі 25,47 дБ-Гц 11,58 -> 2,10; за 25 дБ-Гц 9,55 -> 1,60; за 22 дБ-Гц 2,24 -> -0.14.
• ins-trn-coast: кожен вихід рухається разом із моделлю похибки Шулера; пік TRN у постачуваному сценарії 52,932679 -> 44,711834 м (tests/conflict_resilience_architecture_guard.rs).
• Звіт lunar-vlbi: новий ключ geometry_path («analytic» у типовому прогоні, жодне числове значення не змінилося); нові необов'язкові поля planetary_kernel_path, earth_orientation_kernel_path і moon_orientation_kernel_path, з epoch_partials на шляху через ядра; опис виду переписано. Оракул шляху через ядра в рядку верифікації — SPICE (0,06 пс); ANISE (0,12 пс) стає перехресною перевіркою обчислення ядер.
• Сталі тіл: Phobos GM 7.087e5 -> 7.087546066894452e5; Deimos 9.62e4 -> 9.615569648120313e4; Uranus 5.7939506103e15 -> 5.793951256527211e15; Neptune 6.83509997e15 -> 6.835103145462294e15; Pluto 8.69326e11 -> 8.696138177608748e11 (м^3/с^2); екваторіальний радіус Phobos 13,1 -> 13,0 км; полюс і початковий меридіан Phobos і Deimos з pck00011; prime_meridian_deg Сонячної системи тепер містить квадратичні та періодичні члени.
• europa-surface-pnt (body-pnt на Європі), за повною орієнтацією Європи з pck00011 (7cfd66b4; орієнтація збігається зі SPICE pxform до 1.4e-10 рад), що зсуває посадковий апарат в інерціальному просторі: доступність лише ретрансляторів / із земною дальністю 0,485 / 0,725 -> 0,480 / 0,719 (83 -> 82 з 171 епох лише ретранслятори), медіана PDOP 5,266 -> 5,360, середньоквадратична похибка визначення 129,516 / 100,983 м -> 112,742 / 86,147 м, медіана формальної сигми 5,266 / 4,272 м -> 5,360 / 4,239 м. Таблиця в docs/SOLAR-SYSTEM.md і закріплення в mcp/kshana-mcp/tests/round_trip.rs слідують за цим; mars-orbit-pnt не змінюється.
• space-weather (f107 180, f107a 165, kp 4), калібрований коефіцієнт замінено на Jacchia 1971: activity_density_kg_m3 на 300/400/500/600/800 км 2.602e-11 -> 3.608e-11, 4.176e-12 -> 6.929e-12, 8.136e-13 -> 1.618e-12, 1.769e-13 -> 4.189e-13, 1.544e-14 -> 3.781e-14; activity_factor 1.076/1.121/1.168/1.216/1.320 -> 1.492/1.860/2.322/2.881/3.232; reference_exospheric_temperature_k прибрано, mean_exospheric_temperature_k додано (1186,7 K); tests/space_weather_reference.rs: розмах сонячного циклу на 800 км тепер 10.4× (NRLMSISE-00 13.6×), а твердження про висоту слідує за зростанням NRLMSISE до 500 км і спадом на 800 км.
• ntn-5g-positioning toa_median_sigma_3d_m: NR 5 МГц 2,0903959 -> 2,0903962 м; NB 200 кГц 25,938613 -> 25,938839 м (текст підсумку незмінний: 2,09 / 25,94 м).
• lunar-joint-od-clock (розв'язок QR): with_vlbi.station_pos_err_m 3,541344 -> 3,541350 м; without_vlbi.station_pos_err_m 2183,119 -> 2183,558 м.
• docs/field-units-schema.json згенеровано заново для нових і вилучених полів, зазначених вище.

Пакети валідації#

D12, розширена точність і розв'язувач із квадратним коренем (два нові рядки VALIDATED: 226 -> 228 рядків, 110 -> 112 перевірених).

Частина 1, оракул розширеної точності:

• Датум місячної системи відліку з оцінюваними станціями: 50-розрядний оракул розширеної точності mpmath (заздалегідь зареєстровано 804662d5, пороги, масштабовані за обумовленістю, за апріорною формулою зворотної похибки) збігається на новій даті кампанії (2026-03-18) та на початковому сценарії 2024-01-01; новий рядок VALIDATED під P2. Він розв'язує попередню суперечку щодо подвійної точності: сигми датума рушія відхиляються до 9.7e-6, обернений і власний маршрути NumPy — до 6.2e-6, а його маршрути Холецького та QR — приблизно на 1e-8. Рушій лежить у межах своєї межі похибки, але приблизно в тисячу разів менш точний, ніж маршрут факторизації.
• Середовище оракула: додано mpmath 1.3.0.
• Ревізії: немає. Жоден еталонний файл чи опублікований рисунок не змінюється; рядок «Датум місячної системи відліку з кампанії спостережень» лишається MODELLED (рішення засновника 2026-10-02, варіант A: він не запозичує статусу окремого рядка); текст його тестів цитує новий тест і його знахідку.

Частина 2, розв'язувач датума з квадратним коренем інформації:

• Новий додатковий розв'язувач із квадратним коренем інформації (linalg_sr; solver = "srif" у сценарії lunar-frame-campaign): QR Хаусхолдера, маргіналізація через трикутний множник, SVD Якобі для спектра та компенсовані добутки лише з коректно округлених операцій. Проти 50-розрядного оракула (заздалегідь зареєстровано b41908c9) його сигми датума збігаються до 3e-13 на новій даті (2026-06-09); на входах 2026-03-18 і 2024-01-01 типовий розв'язувач відхиляється до 1e-5. Новий рядок VALIDATED під P2. Типовий розв'язувач і його вивід не змінюються. Заздалегідь зареєстровані пороги засвідчують похибки лише понад приблизно 2e-7 відносно: вони відхиляють типовий розв'язувач, але не перевернутий знак Хаусхолдера, некомпенсований скалярний добуток чи спектральне кінцеве обернення, і рядок про це каже.
• Додаткові шляхи з квадратним коренем поряд із незмінними типовими: fim::crlb_srif, batch_ls::gauss_newton_srif, orbit_determination::determine_orbit_batch_srif, lunar_combination::formal_covariance_srif, precise_od::fit_srif і cislunar_srif::srif_cross_validation_sqrt, на нових linalg_sr::weighted_lstsq і covariance_from_sqrt_information. Кожен збігається зі своїм типовим там, де обидва точні (внутрішня перевірка, без рядка; для них не заявляється жодної валідації). precise_od::fit тепер делегує спільній процедурі; його вивід і типовий вивід кожного сценарію не змінюються.
• Рішення щодо рангу кампанії місячної системи відліку: заздалегідь зареєстрована перевірка розширеної точності за 40 діб підтверджує кожне визначне рішення щодо блока станцій і повноранговості Гельмерта. Апріорна межа не може засвідчити 20 днів Гельмерта з дефіцитом рангу; у точній арифметиці їхній дефект геометричний, з порогом 1e-9 усередині природного діапазону відношень власних значень кампанії. Рядка немає.
• Твердження рядка кампанії з розширеною точністю звужено до «в межах межі найгіршого випадку», а його перевірка найслабшого напрямку із закріпленими станціями тепер вимірює справжній кут (6.6e-16 рад; компаратор змінився з acos на хорду, поріг не змінився).
• Ревізії: немає. Жоден еталонний файл чи опублікований рисунок не змінюється; рядок «Датум місячної системи відліку з кампанії спостережень» не змінюється й лишається MODELLED (рішення засновника 2026-10-02, варіант A).

D4, основа ефемерид ядер JPL, фаза 1 (чотири нові рядки VALIDATED: з 228 до 232 рядків, з 112 до 116 перевірених за зовнішнім еталоном).

• Зчитувач ядер NAIF має власний рядок. naif_kernel (контейнер DAF, SPK типу 2, двійковий PCK типу 2) збігається зі SPICE Toolkit (CSPICE N0067 через spiceypy 8.2.0) та з ANISE 0.10.6 на всіх 600 станах DE440 і 200 обертаннях місячної орієнтації випадкової сітки, добутої з власного хешу коміту попередньої реєстрації (abcd9133), у межах порогів, заздалегідь виведених із обчислення Чебишова з подвійною точністю (найгірше 0,6 % порогу, 1.95e-3 м). Рядок стверджує, що рушій правильно зчитує ядра JPL, а не що DE440 або аналітичний ряд є точним (tests/naif_reader_spice_oracle.rs).
• ephem_provider::KernelEphemeris: положення за DE440 (або будь-яким SPK типу 2) через власний зчитувач рушія, з двочастинними епохами TDB і SHA-256 ядра, збереженим для звітів; він ніколи не підставляє барицентр системи замість планети. LunisolarSource дає змогу шляху геометрії вибрати аналітичний ряд (типово) або ядро.
• Додатковий (opt-in) Місяць із ядра для lunar-llr-datum і lunar-vlbi-fim: ключ planetary_kernel_path зчитує геоцентричний центр Місяця з ядра; більше нічого не змінюється, а звіт отримує блок moon_ephemeris із назвою ядра та його SHA-256. Без ключа обидва звіти побайтово ідентичні попереднім.
• Коваріація точки на місячній поверхні на шляху ядра (новий рядок VALIDATED): із закріпленими всіма станціями та маяком на Місяці за DE440 коваріація маяка збігається з якобіаном світлового часу SPICE (найгірше 1.7e-3 проти порогу 1 %) і з оберненою матрицею NumPy (4e-14 проти 1e-9), попередня реєстрація 4a51256 (tests/lunar_vlbi_surface_point_spice_oracle.rs). Рядок аналітичного шляху лишається MODELLED: на аналітичному Місяці його найменша сигма маяка на 3,9 % нижча за оракул.
• Датум місячної системи відліку з реальної кампанії, центр Місяця з ядра (новий рядок VALIDATED): на 447 небачених нормальних точках 2019-Q2, попередньо зареєстрованих 830d945a до отримання будь-якої з них, коваріація датума на шляху ядра збігається з незміненим оракулом SPICE і NumPy в межах 7.6e-5 проти порогів 1 % і 2 % (tests/validate_llr_datum_kernel_moon_fresh.rs). Засновник вирішив, що цей рядок підвищується лише на свіжих точках; діагностика на вже баченому наборі даних (c51f8b2) є висновком, а не доказом. Поріг не розрізняє моделей Місяця: аналітичний Місяць також проходить на тому самому зрізі (найгірше 3.8e-3), заплановану мутацію (місячне ядро із запізненням на одну годину) не виявлено, а на згині центр Місяця, хибний приблизно на 4 650 км (Місяць узято щодо барицентра системи Земля–Місяць), також проходив. Рядок заявляє коваріацію на цьому шляху, а не центр Місяця, і прямо це зазначає.
• Положення Сонця, Місяця, Меркурія та Венери за DE440 на епохи UTC (новий рядок VALIDATED): KernelEphemeris::relative_position_utc збігається зі Skyfield 1,54 на 600 положеннях між 1973 і 2026 роками, найгірше 2,96 м, у межах попередньо зареєстрованого порогу (0bfafe6d), заданого двочленним рядом TDB − TT (tests/kernel_ephemeris_skyfield_oracle.rs). Положення планет отримують цей новий рядок ядра тепер; рядок Standish і рядок планетних супутників не змінено, а супутники чекають на сценарій, якому вони потрібні (рішення засновника).
• Висновки: єдиний промах порівняння датума LLR (сигма z-зсуву 1,025 % проти 1 %) падає до 0,049 %, коли з DE440 зчитується лише центр Місяця, на вже баченому наборі даних (tests/validate_llr_datum_kernel_moon.rs); на свіжому зрізі 2019 року аналітичний Місяць також проходить, тож промах 2015 року був маргінальним щодо геометрії того кварталу. Аналітичні рядки «Датум місячної системи відліку з РЕАЛЬНОЇ спостережної кампанії» і «Коваріація координат точки на місячній поверхні … окремо від коваріації земної станції» лишаються MODELLED; їхні тексти оракулів тепер вказують на рядки шляху ядра.
• lunar_ephemeris більше не стверджує, що в рушії немає зчитувача двійкових ядер; він вказує на рядок зчитувача й пояснює, чому ядра космічних апаратів (типів 13 і 21) і далі надходять через Horizons.
• Зміни: немає. Жоден еталонний файл, опублікований показник чи наявне тестове значення не змінюється; аналітичні звіти lunar-llr-datum, lunar-vlbi-fim і lunar-vlbi-fim з усіма закріпленими станціями побайтово ідентичні попереднім (префікси SHA-256 результатів 9927aac2, cf1d2671, 25c357e4).

D9, бібліотека виміряних годинників «Clock Atlas» (три нові рядки, один VALIDATED: з 232 до 235 рядків, з 116 до 117 перевірених за зовнішнім еталоном).

• Бібліотека виміряних годинників (clock_library). Картки пристроїв (білий шум фази, білий, флікерний і випадкове блукання частотної модуляції, лінійний дрейф частоти та, за потреби, члени фази з одним–чотирма циклами на оберт), підігнані до іменованого виміряного запису годинника й оцінені на відкладених даних; девіація Аллана та дисперсії Адамара з урахуванням пропусків; детектор кондиціонування, що фіксує кожен пропуск, викид фази, стрибок фази, сплеск і стрибок частоти й нічого не знає про межі файлів чи днів; перетворення картки на модель шуму слотової синхронізації, розширену модель годинника Калмана та рівні шуму монітора спуфінгу. Зчитувачі файлів годинників RINEX та IGS, файлів BIPM для окремих лабораторій і розділу 1 Circular T (realdata::clk); сукупна ієрархічна межа старіння для UTC(k) (utck_bound, ще не оцінена).
• Ідентифікація шуму за автокореляцією зі зсувом 1 (allan::lag1_noise_id, Riley і Greenhall 2004), новий рядок VALIDATED (Library): збігається з allantools 2024,6 autocorr_noise_id на 140 випадках, цілі числа ідентичні, найгірша різниця 9.6e-13 проти порогу 1e-9 (попередня реєстрація 2ec76864; tests/clock_library_lag1_noise_id_allantools.rs).
• Виміряні картки пристроїв із прогнозом на відкладених даних, новий рядок MODELLED (висновок): підгонка на одній третині, прогноз девіації Аллана двох інших третин у межах коефіцієнта 1,5 (попередня реєстрація 2ec76864). GPS Block IIF на свіжому вікні IGS (з 2026-03-01 по 14): 10 із 11; G27 оптимістичний на двогодинному масштабі (найгірший коефіцієнт 1,510). Цезій (у межах, 1,070), OCXO (поза межами, 2,348) і стронцій (у межах) повідомляються, але не наосліп. Картка приймача JammerTest та картки мазера Galileo і Deep Space Atomic Clock заблоковані. Клас моделей TCXO приймача ZED-F9P на 12 статичних станціях у Вроцлаві (Zenodo 6488497) не проходить: 1 із 11 станцій наосліп у розкритому виправленому повторному прогоні (tests/clock_library_device_cards_oracle.rs, tests/clock_library_f9p_cards_oracle.rs).
• Картки GPS Block IIF із членами за оберт, новий рядок MODELLED (висновок): на другому свіжому вікні (з 2026-04-01 по 14) 9 із 11 у межах порогу; G03 (1,947) і G25 (1,581) оптимістичні, бо їхні відкладені записи шумніші за підгоночні третини; відкидання періодичних членів не проходить у всіх 11 (попередня реєстрація fb475550; tests/clock_library_periodic_cards_oracle.rs).
• M002, оцінювання стану бортового годинника, раунд 3 (висновок, лишається MODELLED): після замороженого детектора кондиціонування розширений фільтр раунду 2 із незмінними налаштуванням і критеріями вперше виконує (a) і (c) на всіх 11 супутниках; (b) не виконується на G09 (0,894) і G26 (0,876) (попередня реєстрація fb475550; tests/clock_state_ext_igs_conditioned_oracle.rs).
• M010, виявлення спуфінгу, раунди 3 до 4b (лишається MODELLED): раунд 3 заблоковано (167 навчальних епох з інших сеансів пристрою JammerTest проти 3600); із карткою класу моделей ZED-F9P (раунди 4 і 4b) монітор годинника дає нуль хибних тривог до початку на всіх 10 зафіксованих початках (раунд 2: 86) і 6 із 10 початків виявлено в межах 10 с (раунд 2: 4); ті самі чотири залишаються запізнілими (tests/clock_library_tcxo_card_jammertest_oracle.rs).
• M083, завищена межа UTC(k), раунд 3: проспективно попередньо зареєстровано (fb475550) на випусках Circular T з 465, ще не запущено (tests/utck_bound_prospective_oracle.rs).
• Середовище оракулів: запис Wroclaw ZED-F9P залежить від даних у $KSHANA_ORACLES/data/wroclaw_f9p (CC BY 4,0, близько 1,5 ГБ); фікстури годинників IGS постачаються разом (продукти IGS, із зазначенням авторства).
• Зміни: немає. Жоден еталонний файл, опублікований показник чи наявне тестове значення не змінюється; M001 (повторне прив'язування holdover) не виконується, бо жоден клас годинників не підвищився.

D8, один перевірений за зовнішнім еталоном шлях поширення, системи координат і часу (три нові рядки VALIDATED і підвищений M131: з 235 до 238 рядків, перевірених за зовнішнім еталоном з 117 до 121).

Різновиди навколоземних орбіт, які мали власні двотільні моделі, секулярні моделі J2 або моделі лише із зоряним часом, тепер мають спільний шлях: набори елементів SGP4/SDP4 з двочастинними юліанськими датами, перенесені в GCRS і ITRS (Міжнародна земна система відліку) через ланцюжок IAU (Міжнародний астрономічний союз) 2006/2000A, з додатковими параметрами орієнтації Землі.

• Нові sgp4::MeanElementSet, sgp4::SgpOrbit, sgp4::Eop, sgp4::teme_to_itrs_matrix[_eop] і sgp4::gcrs_to_itrs_matrix[_eop]; Sgp4::new_at і Sgp4::propagate_at приймають двочастинні епохи. Нові jd2::Jd2::from_utc_calendar (конвенція SOFA dtf2d для діб із високосною секундою), jd2::utc_to_tai, tai_to_utc, utc_to_ut1 (через TAI, як SOFA utcut1), tai_to_tt і двочастинний jd2::earth_rotation_angle.
• Полярний режим leo-pvt поширює за допомогою SGP4 на 2026-01-01T00:00:00 UTC за ланцюжком IAU (leo_fusion::polar::latitude_sweep_at приймає будь-яку епоху); генератор Волкера SGP4 повертає в земну систему координат через ланцюжок IAU.
• Різновид passes запускає новий предиктор видимих проходів (passes::predict_passes_apparent, apparent_look_angles): SGP4 за ланцюжком IAU, рефракція ITU-R P.834-9 і світловий час низхідної лінії (нові перемикачі refraction і light_time, типово ввімкнені), параметри орієнтації Землі (ut1_minus_utc_s, xp_arcsec, yp_arcsec, типово 0), перетини, розв'язані до 1e-7 с, а кульмінація — пошуком золотого перерізу. Геометричний passes::predict_passes не змінено.
• tests/no_private_models.rs не дає ядрам геометрії, часу та поширення пакета нести приватне кеплерове поширення, секулярні швидкості J2 чи обертання лише із зоряним часом; іменовані швидкі рівні та фізика, що є предметом рядка, є обґрунтованими винятками.
• Новий рядок VALIDATED «Двочастинні юліанські дати та високосні секунди на часовому шляху навколоземної орбіти»: pyerfa 2.0.1.5 dtf2d/utctai/taiutc на 224 моментах навколо всіх 27 високосних секунд у межах 1e-6 с (попередня реєстрація e947e69d); найгірше 1.9e-11 с.
• Новий рядок VALIDATED «Єдиний навколоземний шлях»: позиції TEME 232 наборів елементів проти python-sgp4 2,24 (еталонний SGP4 Валладо) у межах 6.1e-8 м (поріг 1 см), а обертання GCRS -> ITRS і TEME -> ITRS проти ERFA c2t06a, pnm06a і ee06a у межах 2.9e-6 мс дуги та 0,41 мс дуги (пороги 0,1 і 2 мс дуги), з параметрами орієнтації Землі (попередня реєстрація 72ea9eb0). Розкрито: перший запуск не пройшов на 2016-12-31T23:59:59,5 на одну секунду обертання; UT1 брали з квазіюліанської дати UTC у добу з високосною секундою, тепер рушій іде через TAI, і другий запуск збігається за незмінними порогами.
• M131 «Покриття LEO та геометричний чинник DOP для полярних і арктичних користувачів порівняно з MEO GNSS» стає VALIDATED: Orekit 13.1.8 бере стани GCRS рушія, повертає їх і обчислює видимість і DOP (NumPy для груп із кількома годинниками); положення в межах 6.8e-5 м (поріг 0,2 м), кількості в зоні видимості ідентичні на 4040/4040 вибірок, медіана DOP у межах 2.3e-11 відносно.
• Новий рядок VALIDATED «Видиме передбачення проходів над наземною станцією з рефракцією та світловим часом»: Orekit 13.1.8 поширює ті самі набори елементів у TEME, який він будує за заданим означенням, з рефракцією ITU-R P.834 і його вимірювальною моделлю світлового часу, на 60 випадках для станцій на рівні моря: 1210 проходів, перетини в межах 3.4e-6 с (поріг 5 мс), максимальна висота в межах 5.5e-7 град, видимий напрямок у межах 8.8e-7 град (поріг 1e-4 град).
• Висновки, що лишаються зафіксованими: перші порівняння повного твердження з Orekit наскрізно не досягли порогів за положенням і напрямком не через рушій, а тому, що SDP4 в Orekit 13.1.8 відхиляється від еталонного SGP4 для колових (e = 0) орбіт далекого космосу (до 67 м), а його типовий TEME побудовано на нутації IERS 1996 (IAU 1980), що приблизно на 72 мілідугових секунд відрізняється від ланцюжка IAU 2006/2000A (2,7 м на LEO). Коефіцієнт h*theta0^2 в ITU-R P.834 в Orekit становить 0,011380, тоді як у Рекомендації надруковано 0,01380; порівняння на рівні моря, де цей член зникає, а різниця вище нього зафіксована.
• «Передбачення проходів над наземною станцією (наземний сегмент)» лишається VALIDATED із заявою, звуженою до геометричного passes::predict_passes; різновид passes належить новому рядку.
• Середовище оракулів: Orekit 13.1.8 з Hipparchus 4.0.3, pyerfa 2.0.1.5, python-sgp4 2,24 (xval/d8-orekit13/setup.sh).
• Зміни: вбудований scenarios/passes.toml загальний доступ 1675 с -> 1659 с (п'ять проходів, як і раніше; найкраща максимальна висота 73,25 град -> 70,08 град), і кожен вивід passes змінюється з новим шляхом (надрукований рядок у docs/examples/multi-tool-pipeline.md і запис passes у docs/CAPABILITY.md тепер про це кажуть); вбудований polar-arctic-leo-coverage VDOP ГНСС на екваторі 1,19669 -> 1,19710, на 89,9 град 1,50645 -> 1,50590, об'єднаний VDOP на 89,9 град 1,14388 -> 1,14250 (опубліковані показники із двома десятковими 1,20, 1,51 і 1,14 не змінено). Жоден еталонний файл не змінюється.
• Ще не маршрутизовано: leo_pass, режими доплера, спільний і синхронізації leo-pvt та істинна орбіта leo_navmsg (їхні моделі містяться в leo_link::geometry і leo_fusion::geom), а також земні конструкції в constellation-design (іменований двотільний швидкий рівень).

D6, еталонний генератор LunaNet AFS, LSIS V1.0 (чотири нові рядки, два VALIDATED: з 238 до 242 рядків, з 121 до 123 перевірених за зовнішнім еталоном).

• Еталонний генератор LunaNet Augmented Forward Signal (AFS) (lunar_afs), закріплений за LunaNet Signal-In-Space Recommended Standard (LSIS) V1.0 від 29 січня 2025 року й із зазначенням цієї версії в кожному виводі: несівна 2492,028 МГц; канал даних AFS-I BPSK(1) на 500 символів за секунду з його кодом Голда з 2046 чипів; пілотний сигнал AFS-Q BPSK(5) з первинним кодом Вейля з 10230 чипів, вторинним з 4 чипів і третинним з 1500 чипів; кадр з ідентифікатором кадру 0 (синхронізаційний шаблон, підкадр 1 за BCH (51, 8), CRC-24, підкадри 2–4 з LDPC зі швидкістю одна друга, блоковий перемежувач 60 на 98) з вичерпним декодером підкадру 1 і декодером LDPC за мінімальною сумою, написаним лише за матрицею перевірок парності; та синтез IQ у базовій смузі з істинними мітками, записаний як запис SigMF. Коди генеруються зі зсувних регістрів і побудов Лежандра/Вейля зі стандарту. Нічого, скопійованого зі стандарту, не поширюється повторно (він не містить умов повторного використання): первинні індекси AFS-Q беруться з IS-GPS-800J, а те, що визначають лише додатки стандарту (затримки G2 для AFS-I, третинні коди, підматриці LDPC), зчитується під час запуску з локального кешу, який xval/lunar-afs/fetch_lsis.sh заповнює з розміщеного NASA PDF, причому кожен файл перевіряється за закріпленим SHA-256 (lunar_afs::lsis). Ця модель є еталоном відповідності, а не моделлю каналу, поширення чи бюджету лінії.
• sigmf::meta_to_json_with_extensions і sigmf::annotation_extension_fields: запис може нести поля розширень з іменними просторами, оголошені в core:extensions.
• Новий рядок VALIDATED «Відтворення AFS LunaNet у базовій смузі проти незалежного генератора за заданого стану його каналу»: проти LANS-AFS-SIM (BSD-2-Clause, коміт 480c6bf3, збірка для S-діапазону) нуль розбіжностей чипів у кодах PRN від 1 до 210, нуль розбіжностей символів у трьох кадрах прогону та нормалізована комплексна кореляція 0,999990 на 23,9 с власних відліків (найгірший блок у 2 мс — 0,999948), у межах порогів, зафіксованих до порівняння (попередня реєстрація 986ac280). Він запускає засіб відтворення зі станом каналу самого симулятора й не охоплює розподіл потужності за відношенням несівної до густини шуму та запис SigMF і 8-бітний запис.
• Новий рядок VALIDATED «Канальне кодування кадру AFS LunaNet, FID 0»: кадри з 6000 символів дорівнюють кадрам LANS-AFS-SIM символ у символ (попередня реєстрація 986ac280); код підкадру 1 відтворює робочий приклад з рис. 8 LSIS, а CRC-24 — контрольне значення каталогу CRC-24/LTE-A.
• Обидва підвищені рядки залежать від даних кешу LSIS: їхній тест оракула пропускається з повідомленням, доки не буде запущено xval/lunar-afs/fetch_lsis.sh.
• Висновок (новий рядок MODELLED), «Генерація розширювальних кодів AFS LunaNet»: із 2 937 232 згенерованих чипів і бітів, порівняних із таблицями стандарту та файлами додатка 3, один відрізняється: «останні 24 чипи», які таблиця E-5 друкує для третинного PRN 147 і які дублюють комірку PRN 151, тоді як власний файл додатка 3 стандарту збігається з генератором. Критерій нульових розбіжностей не досягнуто.
• Висновок (новий рядок MODELLED), «Замкнена декодованість AFS LunaNet»: три попередньо зареєстровані прогони проти PocketSDR-AFS; третій повністю досяг порогів стеження та декодування, але не досяг свого захисту, за яким збірка приймача лише з друком відтворює журнал закріпленої збірки, бо два запуски незміненого приймача вже відрізняються записами захоплення.
• Виправлено: типова несівна lunar_service (export_antenna.carrier_hz), lunar_jamming і attack_surface була округленими 2,4 ГГц; тепер це несівна AFS за LSIS-020, 2492,028 МГц. За старого типового значення втрати у вільному просторі були занижені на 0,327 дБ.
• Зміни: немає. Кожен вбудований сценарій називає свою несівну, а результати всіх 138 файлів сценаріїв побайтово ідентичні попередньому main.

D7, реальний місячний IQ і GPS LNAV (сім нових рядків, жоден не VALIDATED: з 242 до 249 рядків, перевірених за зовнішнім еталоном 123 без змін).

• portable_math::FftPlan: мішаноосновне швидке перетворення Фур'є (FFT), вивід якого є тими самими бітами на кожній платформі; закріплення SHA-256 перетворень на 8000 і 24000 точок проходить на x86_64 і wasm32-wasip1 (запускач у xval/portable-fft-wasm/).

• acquisition: паралельний пошук фази коду на дискретизованому IQ (pcps_acquire, pcps_grid) з когерентним згортанням, некогерентним накопиченням, порогом хі-квадрат для ймовірності хибної тривоги в усьому пошуку та статистикою з усередненням за комірками для шуму з обмеженою смугою; refine, prompt_series з кодовим Доплером, а також оцінювачі відношення несівної до густини шуму (C/N0) M2M4 і за піком сітки.

• gps_lnav: кодувальник застарілого навігаційного повідомлення (LNAV) IS-GPS-200 для підкадрів 1–3 із парністю таблиці 20-XIV і декодером полів.

• realdata::ion_sdr: зчитувач ION GNSS SDR Metadata Standard (.sdrx) і його файлів відліків, із to_mid_rise для рівнів у доповняльному коді.

• realdata::lugre: пакетний заголовок IQS LuGRE (Lunar GNSS Receiver Experiment), телеметрія RAW, ACQ і NAV та файли CLK, а також перевірка, що перелічує, де метадані .sdrx суперечать двійковому заголовку.

• antenna::GainPattern2D і, в earth_gnss_lunar, система координат корпусу за керуванням рисканням, азимут передавання та кути від надиру, а також transmit_side_db для відносного C/N0 із виміряними діаграмами.

• Кодування навігаційного повідомлення GPS LNAV (новий рядок, лишається MODELLED після постверифікації інтегратором): на широкомовному файлі IGS від 2 березня 2025 року, розібраному та декодованому RTKLIB v2.4.2-p13, усі 960 слів проходять перевірку парності, усі 96 підкадрів декодуються й усі 608 широкомовних цілих чисел дорівнюють числам Kshana (tests/gps_lnav_rtklib_integer_oracle.rs), але попередня реєстрація (d4d9eb9d) потрапила до публічної гілки через дві секунди після коміту з результатом, тож порядок «зареєстровано до отримання файлу» показати не можна, і рядок не підвищено.

• realdata::ion_sdr заповнює слова зі старшого біта (I у старшій тетраді байта LuGRE; попереднє зчитування давало спряжений сигнал), зберігає старе зчитування як SdrLayout::fill_lsb_first і зчитує відліки, ширші за слово.

• acquisition::refine_doppler_coherent: фазово-когерентне уточнення Доплера (0,2 Гц RMS за 30 dB-Hz упродовж 200 мс у симуляції).

• GPS L1 C/A проти gps-sdr-sim: чипи та біт парності збігаються до біта; 230 із 1152 полів LNAV відрізняються на одну одиницю, бо gps-sdr-sim усікає там, де широкомовне ціле число потребує округлення.

• LNAV, декодований RTKLIB: усі перевірки парності та підкадри проходять, а кожен параметр у межах половини кванта; 41 масштабованих значень відрізняються на кілька одиниць в останньому розряді через десяткову сталу RTKLIB 2^-43, понад зареєстрований поріг.

• Захоплення LuGRE проти GNSS-SDR 0.0.19: 266 із 266 рішень збігаються, 250 виявлено в тій самій комірці; більшість позитивних результатів є артефактами середнього −0,5 у голих 4-бітових рівнях; ланка C/N0 не мала одночасних льотних даних. Два пакети (OP5, OP12) було виключено помилково: їхні метадані збігаються із заголовками, але зчитувач тоді не міг зчитати відлік, ширший за слово.

• Захоплення LuGRE проти Доплера, передбаченого за орбітою: за рішення за потужністю відліків кожен пошук перетинає поріг на шумі з обмеженою смугою; за рішення з усередненням за комірками найсильніші пари збігаються за модулем із протилежним знаком, що показує: зареєстрований порядок I/Q є спряженим до даних.

• Сліпе захоплення на пакетах місячної поверхні: чотири пакети захоплюють по одному супутнику (передбачено видимий, без хибної тривоги на 1e-7), жоден не захоплює двох, тож для порогу різниці Доплера немає пари для оцінювання.

• Відносний C/N0 на місячній відстані (M039 переформульовано): 15 записів Block IIR/IIR-M і одна пара, замало для зареєстрованого порогу.

• Зміни: немає; жодне опубліковане число, еталонний файл чи показник у документації не змінено.

• Рядок M039 «Earth-GNSS на місячній відстані» переформульовує свою заяву на місячній відстані як відносний C/N0 між супутниками на одну епоху плюс видимість (абсолютний C/N0 не заявляється); він лишається MODELLED. Загальне повідомлення NOTICE верхнього рівня містить зазначення авторства LuGRE за CC BY 4,0.

Виправлено#

• Орієнтація головних осей Місяця за DE440 тепер інтерполюється вздовж геодезичної між добовими вузлами. Попередня поелементна інтерполяція мала похибку до 2.0e-4 рад (340 м на місячній поверхні) поблизу чвертьточок кожної доби, а не «близько 14 м», як стверджував рядок. Її користувачі (геометрія місячної лазерної локації, місячний датум, спостережуваність місячних збоїв) отримують виправлену орієнтацію.
• Виправлення рушія раунду 2, кожне повторно запущене за своїм незміненим попередньо зареєстрованим допуском: вік версії IERS у рядку EOP зчитується з його прапорців I/P, а не з порожнього блоку Bulletin B; snapshot_raim використовує геодезичний місцевий рівень; зв'язок системи відліку місячної швидкості використовує екваторіальний радіус, J2 та обертання; підгонка liu22 починається з нульових поправок без апріорних значень і використовує швидкість середнього руху з роботи; крок вузлів EO враховує вузлову регресію J2; час стрибка циклу Костаса використовує rho/4; спільне визначення застосовує широкомовну групову затримку пари; місячне спільне розв'язання використовує крок QR; межу NTN оцінюють в істинному положенні; еталон годинника для проєктування угруповань є найнижчим угрупованням у зоні видимості; ряд орієнтації DE440 охоплює 2014-2030 і видає помилку поза ним замість фіксації.

Додано#

• leo_navmsg::truth::TruthOrbit::from_ecef_states, істинна орбіта, побудована за табульованими земними станами, використовується для порівняння з підгонкою реальної орбіти.
• Тестові файли та фікстури наведених вище порівнянь, кожен зі своїм генератором і NOTICE.md із зазначенням джерела, ліцензії, дати отримання та SHA-256.
• Раунд 2: araim_reference::add_v42_protection_levels і _ecef (виявлення збоїв ADD v4.2 за Stanford MAAST для ARAIM 2, повідомлення BSD-3 у джерелі); raim::snapshot_raim_fde; cw_dynamics::second_order_correction і propagate_second_order; дев'ятистанна модель похибок INS inertial::coast::ErrorDynamics; частинні похідні lunar_vlbi::KernelGeometry і входи lunar-vlbi шляху ядра; naif_kernel, зчитувач ядер SPK типу 2 і двійкових PCK; lunar_llr_geometry::llr_bcrs_one_way_m зі станціями ITRF2020; густина Jacchia 1971; solar_system::link_on над будь-яким провайдером ефемерид; launch::site_rotation_speed_at; eo_payload::j2_nodal_period і ground_track_spacing_equator_j2; batch_ls::gauss_newton_qr; precise_products (зчитувачі годинників RINEX, ANTEX і DCB).

[0.29.3] - 2026-10-01#

Патч-випуск на основі 0.29.2. Kshana Studio перебудовано навколо двох подань: простого, яке спершу дає відповідь і пояснює її звичайними словами, та розширеного з повною панеллю. Разом із ним вийшли два невеликі виправлення на kshana.dev. Рушій не змінюється: кожен вбудований сценарій дає результат, байт у байт ідентичний до 0.29.2, окрім позначки версії.

Змінено#

• У Kshana Studio є просте подання. Саме воно відкривається в Studio за замовчуванням.
  • Відповідь іде першою: сценарій відкривається на своєму результаті, викладеному одним простим реченням. Кожен вбудований сценарій має власне речення, написане під те, що цей сценарій вимірює.
  • Показано щонайбільше п'ять параметрів, тих, що найсильніше впливають на відповідь. Решта лежить у розділі «Розширені параметри», згорнутому, доки ви його не відкриєте.
  • Розділ «Як це обчислюється» пояснює метод кількома рядками, а «Для дослідників» дає власні показники рушія, файл сценарію та докази, що стоять за результатом.
• Повна панель — це розширене подання. Усі панелі, діаграми, експорти та звіти попередньої версії Studio — там.
• Перемикач переносить між двома поданнями й зберігає ваше місце. Сценарій, подання, на якому ви були, і всі змінені вами параметри зберігаються. Studio запам'ятовує, яким поданням ви користувалися востаннє. Посилання з сайту та документації відкривають просте подання; посилання з view=advanced відкриває розширене подання, а кожне попереднє посилання на Studio, як і раніше, відкриває той самий сценарій і те саме подання.
• Швидше перше подання за повільного з'єднання. Записана відповідь для сценарію малюється ще до завантаження решти Studio, тож на повільному мобільному з'єднанні відповідь з'являється приблизно за дві секунди замість приблизно дев'яти.
• Кращий пошук. Тепер пошук спершу виводить сценарії, у яких із цими словами збігається область або назва, а вже потім сценарії, що лише згадують їх в імені файлу чи тексті.

Виправлено#

• Глобус на головній сторінці більше не стає порожнім за ввімкненого зменшення анімації. Коли було ввімкнено системний параметр зменшення анімації, зміна розміру вікна могла залишити головний глобус порожнім, доки сторінку не прокрутять. Тепер глобус перемальовується в тому самому кадрі, що й зміна розміру.
• L-діапазонна консоль на головній сторінці пояснює свій порожній діапазон. У сценарії «Спостерігайте, як глушник захоплює діапазон» панель GPS L5 / Galileo E5a залишалася темною всю хвилину, що виглядало як поломка. У цьому сценарії жоден глушник не передає в цьому діапазоні, а сигнали супутників лежать нижче рівня шуму, тож там нічого не здіймається над ним. Тепер ненав'язлива позначка повідомляє про це на будь-якому відрізку панелі, де нічого немає над рівнем шуму (панель L5 / E5a і панель L2C до запуску її шумового глушника), разом із C/N0 і станом захоплення кожного діапазону з того самого прогону. Її розміщено лише там, де нічого немає над рівнем шуму, тож вона ніколи не закриває енергію глушника.

0.29.2 - 2026-10-01#

Патч-випуск на основі 0.29.1. Він прибирає дубльований код у модулях навігаційного повідомлення LEO, злиття та спектра, додає світлу тему на kshana.dev, переносить Kshana Studio на власну адресу, робить сайт придатним для читання пошуковими системами та ШІ-асистентами, виправляє кілька дрібниць у Studio і дозволяє публікувати випуски npm без збереженого токена. Вихідні дані рушія не змінюються: кожен вбудований сценарій дає результат, байт у байт ідентичний до 0.29.1, окрім позначки версії.

Додано#

• Світла тема для kshana.dev. Кожну сторінку можна читати у світлій або темній темі. Сайт дотримується системного параметра читача і має перемикач для його зміни.
• Пошукові системи та ШІ-асистенти можуть читати сайт. Кожна сторінка тепер має власні заголовок, опис, канонічну адресу, теги соціальних карток і структуровані дані schema.org, а також звичайний текст для розділів, які малює скрипт. Сайт публікує robots.txt, sitemap.xml із датою останньої зміни кожної сторінки, llms.txt і llms-full.txt (короткий і повний текстові посібники для ШІ-асистентів), а також ключ IndexNow, щоб під час розгортання можна було повідомити пошуковим системам, що змінилося.
• Випуски npm можна публікувати без збереженого токена. Завдання npm тепер працює на Node 24 і npm 11.5.1 або новішому, які підтримують довірену публікацію npm: npm обмінює ідентичність GitHub завдання випуску на короткочасні облікові дані. Секрет NPM_TOKEN і далі працює та використовується, поки його задано, тож нічого не змінюється, доки для пакета на npmjs.com не ввімкнено довірену публікацію. Кроки наведено в docs/RELEASING.md.

Змінено#

• Заголовок головної сторінки читається поверх глобуса. Тепер за заголовком і його текстом лежить м'яка тінь, що приглушує лінії орбіт і точки супутників анімованого глобуса там, де вони його перетинають.

• Kshana Studio має власну адресу: https://kshana.dev/studio/. Усі посилання на сайті та в документації вказують туди. Стара адреса, /playground/, як і раніше працює та переспрямовує на нову із збереженням у посиланні сценарію, подання та інших параметрів.

• Виправлення в Studio. Файл рушія тепер завантажується один раз, а не двічі. Поки він завантажується, Studio одразу показує записаний результат сценарію з позначкою «записано» замість порожнього екрана. На телефоні заголовок займає один компактний рядок. Ключові показники переносяться по два в рядок, тож жоден не ховається за краєм екрана. Підписи полів використовують власні слова сценарію, а поруч стоїть ім'я поля, і пошук знаходить поля за будь-яким із них.

• Менше дубльованого коду. Таблиця одиниць навігаційного повідомлення LEO записувала одні й ті самі десять рядків статистики SISRE для чотирьох зведень підгонки. Тепер їх один раз записує макрос. Дві діаграми-водоспади спектра використовують спільну вісь часу, колірну шкалу та панель шкали C/N0. Зниження дискретизації головної сітки повторно використовує downsample_grid, а інтеграл Сімпсона повторно використовує navsignal::simpson. Дві точки входу виду проходу LEO використовують один крок налаштування. leo_link::geometry імпортує допоміжні векторні функції leo_fusion::geom замість їх копіювання. Розширений звіт імпортує екранування HTML зі звіту API замість копіювання. Кожен із 139 файлів сценаріїв у scenarios/ було запущено на 0.29.1 і на цьому коді, і кожен вихідний файл ідентичний байт у байт.

• Таблиці одиниць leo-navmsg і leo-pvt мають власні файли. Їх винесено з модулів, що містять також логіку, до src/leo_navmsg/units.rs і src/leo_fusion/pvt_units.rs. PVT_UNITS зберігає свій публічний шлях. Лише ці два файли таблиць додано до винятків із виявлення копіпасту для декларативних каталогів у sonar-project.properties, які перевіряє tests/sonar_cpd_exclusions_are_justified.rs.

Виправлено#

• Бейдж CI у README показує результат пушів у main. Бейдж враховував запуски всіх подій у main, тож міг показувати «failing», хоча всі запуски пушів були зеленими; тепер він запитує лише запуски пушів (event=push).

0.29.1 - 2026-10-01#

Патч-випуск на основі 0.29.0: виміряний показник покриття, рядок із назвою проєкту на kshana.dev, швидше завдання покриття та оновлений README. Вихідні дані рушія не змінюються: кожен сценарій дає той самий результат, що й у 0.29.0.

Перегляд опублікованих чисел#

• Покриття рядків: ~96 % → ~95 %. Завдання покриття повторно виміряло код випущеної версії 0.29.0 (коміт db796dd, запуск CI 36809850252, 2026-10-01): 95.35 %, 55 970 із 58 697 рядків у src/. Опублікований показник становив 95,63 % (37 697 із 39 419 рядків), виміряний на b1d350d до 0.28.0; він округлювався до ~96 %. Новий показник округлюється до ~95 %, тож усі поверхні, які фіксує tests/coverage_figure_doc_sync.rs, змінюються разом: docs/COVERAGE.md, бейдж README, рядок Evidence і таблиця CI, бейджі crates.io, PyPI та npm, технічний звіт і сторінка покриття на kshana.dev. Нижня межа 85 % не змінюється.

Додано#

• Рядок із назвою на kshana.dev. «Kshana · क्षण · the precise instant» тепер відкриває головний блок Home і стоїть під брендом у футері кожної сторінки. kshana.dev, як і раніше, не робить жодного запиту до іншого хоста: деванагарі — це власне розміщена підмножина Noto Sans Devanagari із трьох літер क्षण (1 692 байт, web/fonts/, з текстом ліцензії SIL Open Font License та її SHA-256 у web/fonts/FONTS.json). web/tools/fetch_third_party.py навчився зберігати підмножину Google Fonts text= під файлом з іменем, адресованим за вмістом.

Змінено#

• Посилання сайту потрапляють туди, куди вказують, за чистими адресами. Посилання на розділ тепер ставить цей розділ одразу під заголовком, на телефоні й на комп'ютері: посилання на сектор у Missions відкриває цей сектор із його панеллю нагорі; посилання на Capabilities і Editions тримають своє місце, поки малюються діаграми над ними; Editions більше не додає другого відступу заголовка; а посилання на згорнуту частину сторінки документації розгортає її. Кожна сторінка має посилання за чистою адресою (/evidence#research, /docs/changelog, / для Home), і канонічні посилання, мапа сайту та перенаправлення зі старих адрес називають те саме; адреси з .html і далі працюють. Research має власне посилання в заголовку, між Evidence і Developers, і у футері. Документація більше не показує дорожню карту (ROADMAP.md лишається в репозиторії): група Project — це Changelog, Licensing, Security, Contributing, Governance і Code of conduct, а Glossary перенесено до Get started.
• Завдання покриття швидше. На 0.29.0 воно тривало 143 хвилини проти звичайних 91 до
  94. Фазер tests/property.rs, причина минулого разу, забирав 4 із них. Вбудований корпус зріс із 74 до 139 сценаріїв, і три тестові бінарники проходили його повністю по одному файлу (determinism двічі, advanced_report та animation по разу): разом 37 хвилин під інструментуванням покриття проти 3 на 0.27.2. Тепер вони спільно використовують tests/support/corpus.rs, який виконує роботу для кожного сценарію на всіх ядрах і повертає результати у відсортованому порядку; кожен сценарій і кожне твердження залишаються. На ноутбуці arm64, збірка debug: determinism займає 143 с на 14 ядрах проти 612 с із KSHANA_CORPUS_THREADS=1 (старий послідовний обхід).
• README оновлено. Він відкривається тим самим рядком із назвою, що й сайт; знімки екрана Studio зроблено заново зі Studio 0.29.1, з новим знімком Studio на телефоні та його нижньою панеллю кроків; нова стрічка «The site» показує три сторінки kshana.dev зі збірки 0.29.1 (tools/capture_site_shots.mjs, складена tools/readme_shots.py і записана в docs/assets/readme/site/SHOTS.json); показник покриття становить ~95 %; а альтернативний текст рисунка про дослідження, який повторював текст рисунка про архітектуру, тепер описує статті. Бейджі в заголовку менші й коротші (18 px заввишки; «~95%», «83/223», «quality», «AGPL-3.0», «zenodo.20528627»), тож усі одинадцять вміщуються у два рядки; кожне посилання й альтернативний текст зберігають свій повний зміст.
• Завдання образу контейнера отримує 90 хвилин. На v0.29.0 емульована збірка linux/arm64 образу kshana-mcp вичерпала старий ліміт у 45 хвилин під час компіляції свого останнього крейта, тож образ, запис у реєстрі MCP і перевірка каналу не були опубліковані. Тепер ліміт становить 90 хвилин; сам образ не змінився.
• Вісім літералів з рухомою комою згруповано заново у src/ephem.rs і src/sgp4.rs (0.323_273_64 → 0.323_273_640): SonarQube Cloud сприймав останню групу _64 або _32 як відсутній суфікс f64 або f32 (правило S7454). Значення — ті самі числа, тож жоден результат не змінюється.

0.29.0 - 2026-10-01#

Дванадцять нових видів сценаріїв і три нові способи прочитати прогін. Рушій тепер охоплює радіоспектр, усю Сонячну систему, орбітальні угруповання навколо будь-якого тіла, кампанії, що ланцюжком з'єднують сценарії в одну місію, і позиціонування, навігацію та час (PNT) з низької навколоземної орбіти (LEO) від сигналу до визначення місцеположення. Кожен прогін також можна записати як анімацію, повний звіт і набір файлів сумісності для інших інструментів.

Навколо рушія: перероблений kshana.dev (багатосторінковий сайт і нова панель Kshana Studio, що запускає кожну можливість у браузері), переписаний README, чотирнадцять інструментів на сервері Model Context Protocol (MCP), збірка для браузера, що дає ті самі числа, що й нативна, і публічна сторінка для Kshana Pro.

Звідки береться зростання:

Можливість LEO не залежить від системи: вона працює із загальних заданих параметрів і не потребує названої системи. Названі системи — необов'язкові пресети, кожен у власному файлі з публічним джерелом. Один пресет, Celeste IOD (демонстрація на орбіті), використовує показники, представлені на семінарі ESA NAVISP LEO-PNT, 2026 (ESA — Європейське космічне агентство; NAVISP — його Програма підтримки навігаційних інновацій); він міститься в одному файлі, src/celeste_iod.rs, разом зі своїми п'ятьма сценаріями лише для репозиторію, тож його можна вилучити без правки джерела, і жодного з показників семінару в цьому журналі змін не повторено.

Прочитайте «Перегляд опублікованих чисел» перед оновленням. Змінюється один вихід рушія (стовпці інерціальної системи відліку виду ephemeris після виправлення знака в матриці нутації), а аудит документації виправив показники, надруковані в попередніх документах.

Скорочення, використані в цьому записі

Статуси: VALIDATED означає перевірку за незалежним зовнішнім оракулом (опублікованою таблицею, програмним забезпеченням іншої групи або виміряними даними); MODELLED означає задану модель, перевірену лише на внутрішню узгодженість; PARTNER означає, що для перевірки потрібні апаратура або дані партнера.

Скорочення	Значення
3GPP, 5G, NTN	3rd Generation Partnership Project; мобільна мережа п'ятого покоління; нетеррестріальна мережа
AD, BC	календарні ери (від Різдва Христового, до Різдва Христового)
AIAA	Американський інститут аеронавтики та астронавтики
AltBOC, BOC, BPSK, MBOC	альтернативна двійкова зсувна несівна; двійкова зсувна несівна; двійкова фазова маніпуляція; мультиплексована двійкова зсувна несівна (модуляції сигналу)
ATOMIC	Autonomous Time and Orbit Determination for Microsatellite Constellations (опублікована модель ефемерид LEO)
C/A, L1, L2, L2C, L5	грубий код захоплення (coarse/acquisition) і назви несівних та цивільних сигналів Глобальної системи позиціонування
C/N0	відношення потужності несівної до спектральної густини шуму
CIO	небесний проміжний початок (Celestial Intermediate Origin)
CLI	інтерфейс командного рядка
CRC-24Q	24-бітна циклічна перевірка надмірності (поліном Qualcomm)
CSAC	мініатюрний атомний годинник
CSS, HTML, SVG, XML	каскадні таблиці стилів; мова гіпертекстової розмітки; масштабована векторна графіка; розширювана мова розмітки
CSV, JSON, PDF, TOML, URL	значення, розділені комами; об'єктна нотація JavaScript; портативний формат документа; Tom's Obvious Minimal Language; уніфікований локатор ресурсів
CW	неперервна хвиля
CZML, KML, GeoJSON	Cesium Language; Keyhole Markup Language; географічний JSON (формати карт і глобусів)
DE441	Development Ephemeris 441 Лабораторії реактивного руху
DOI	цифровий ідентифікатор об'єкта
DOP, GDOP, PDOP, HDOP, VDOP	геометричний чинник погіршення точності: геометричний, у позиції, горизонтальний, вертикальний
E1, E5, E5a, E5b	назви сигналів Galileo
E3F	назва слота в таблиці орбітального угруповання Глобальної системи позиціонування
ECEF	геоцентрична, жорстко пов'язана із Землею
EE	рівняння рівнодення
EGM2008	Earth Gravitational Model 2008
EIRP	еквівалентна ізотропно випромінювана потужність
ERFA, SOFA	Essential Routines for Fundamental Astronomy; Standards of Fundamental Astronomy (бібліотеки еталонної астрономії)
ESA, NAVISP	Європейське космічне агентство; його Програма підтримки навігаційних інновацій
FDMA	множинний доступ із частотним розподілом
GCRF, GCRS	геоцентрична небесна система відліку (Geocentric Celestial Reference Frame); геоцентрична небесна референцна система (Geocentric Celestial Reference System)
GLONASS	глобальна навігаційна супутникова система Росії
GNSS, GPS	глобальна навігаційна супутникова система; Глобальна система позиціонування
IAU	Міжнародний астрономічний союз
ICD, OS SIS ICD, OS SDD	документ керування інтерфейсом; документ керування інтерфейсом сигналу в просторі відкритого сервісу Galileo; документ визначення відкритого сервісу Galileo
ICRF	Міжнародна небесна система відліку
IMO	Міжнародна морська організація
INS, MEMS	інерціальна навігаційна система; мікроелектромеханічна система
IOD	демонстрація на орбіті
IQ	синфазна та квадратурна складові
IS-GPS-200	специфікація інтерфейсу Глобальної системи позиціонування
ISS	Міжнародна космічна станція
ITRF, ITRS, PEF, TEME	Міжнародна земна система відліку (International Terrestrial Reference Frame); Міжнародна земна референцна система (International Terrestrial Reference System); псевдоземна жорстко пов'язана (pseudo-Earth-fixed); істинний екватор, середнє рівнодення (системи відліку)
ITU, ITU-R	Міжнародний союз електрозв'язку; його Сектор радіозв'язку
J/S	відношення потужності глушника до потужності сигналу
J2 до J6, J2000	зональні гармоніки гравітаційного поля; епоха 2000-01-01 12:00
JPL	Лабораторія реактивного руху
LEO, MEO	низька навколоземна орбіта; середня навколоземна орбіта
MBSE	системна інженерія на основі моделей
NEES	нормалізований квадрат похибки оцінювання
NeQuick-G	іоносферна модель Galileo
OEM, SP3, TLE	Orbit Ephemeris Message; Standard Product 3 (точні орбіти); дворядковий набір елементів орбіти
PNT, PPP	позиціонування, навігація та час; точне позиціонування окремої точки
PSD, SSC	спектральна густина потужності; коефіцієнт спектрального розділення
RAIM, SQM	автономний контроль цілісності в приймачі; контроль якості сигналу
RINEX, RTCM	формат обміну даними, незалежний від приймача; Радіотехнічна комісія морських служб
RMS	середньоквадратичне значення
RTKLIB	бібліотека позиціонування GNSS з відкритим кодом, яку тут використано як оракул
SGP4	Simplified General Perturbations 4 (орбітальна модель дворядкових наборів елементів орбіти)
SHA-256	безпечний гешувальний алгоритм, 256-бітний
SigMF	формат метаданих сигналу
SISRE	похибка дальності сигналу в просторі
SPS PS	Стандарт характеристик стандартної служби позиціонування
SRTM	Радарна топографічна місія «Шаттла»
STK	Systems Tool Kit (його формат файлів ефемерид .e)
STL	Satellite Time and Location
SVID	ідентифікатор космічного апарата
T/P/F	загальна кількість супутників, площин і фазування орбітального угруповання Волкера
TEC	повний електронний вміст
UHF	ультрависока частота
UTC	всесвітній координований час
WGS 84	Всесвітня геодезична система 1984
X1, X5	назви сигналів системи Xona Pulsar

Перегляд опублікованих чисел#

Змінене опубліковане число — це перегляд, і його записують, а не виправляють мовчки. Цей випуск містить один перегляд вихідних даних рушія та кілька переглядів показників, надрукованих у документації.

Вихідні дані рушія

• Редукція TEME→GCRS була повернута на 2·Δψ: у матриці нутації знак Δψ був оберненим. nutation::numat будувала Rx(−(ε̄+Δε))·Rz(Δψ)·Rx(ε̄), тоді як iauNumat у SOFA будує Rx(−(ε̄+Δε))·Rz(−Δψ)·Rx(ε̄), тож nutation_matrix, nutation_matrix_2000a, teme_to_gcrs і gcrs_to_teme повертали на подвійну нутацію за довготою, приблизно 25 кутових секунд. Кожна перевірка ланцюжка була властивісним тестом (власне обертання, зворотний перехід, ненульовий внесок нутації), який помилка знака проходить; наскрізний тест Валладо охоплював TEME→PEF, TEME→ITRF і GCRS→ITRS, але не TEME→GCRS. На прикладі Валладо (AIAA 2006-6753, 2004-04-06) ланцюжок розходився з опублікованою GCRF на 1 145 м; тепер він потрапляє на 0,11 м від неї, а матриця дорівнює numat з ERFA з точністю 1e-14. tests/frame_reference_vectors.rs::teme_to_gcrs_matches_vallado_gcrf і nutation::tests::nutation_matrix_matches_erfa_numat обидва падають на старому знаку. Тест узгодженості CIO (небесного проміжного початку) у src/cio.rs списував утворену розбіжність ~130 м на «≈ 2·EE»; залишок тепер становить 5 см, а його межу звужено з 250 м до 1 м. Це змінює опубліковані числа, що записано тут як перегляд: стовпці gcrs_r_m і gcrs_v_m_s виду ephemeris (приблизно 0,8–1,0 км для вбудованого сценарію МКС (Міжнародної космічної станції); його стовпці TEME, жорстко пов'язані із Землею, траси на поверхні, кутів огляду й Доплера не змінюються), а також Propagator::position_in_frame / state_gcrs для систем відліку GCRS та ITRS. Жоден підсумковий рядок, діаграма чи еталонний геш вбудованого сценарію не читає цих стовпців. Нові експорти для сумісності використовують виправлений ланцюжок: позиція CZML першого супутника orbit-sgp4-gps узгоджується з редукцією ERFA того самого TLE (поширеного пакетом Python sgp4) з точністю 2,3 см.
• Вид leo-navmsg, нативно та в збірці для браузера. Тепер цей вид обчислює кожну трансцендентну функцію через одну портативну математичну бібліотеку, тож його кадр складається з тих самих байтів на кожній платформі та в кожній збірці (за Fixed). Разом із цим змінюється кожен показник leo-navmsg і етап navmsg у leo-pnt-chain. Цей вид новий у цьому випуску, тож нічого з попередніх випусків не змінюється, але змінюються показники, надруковані до виправлення: контрольне значення docs/LEO-NAVMSG.md для сценарію кодування та декодування було 0x110315, а тепер 0x19105F, і SISRE декодованого повідомлення становить 0,129 см. На kshana.dev картка Missions для leo-navmsg-fit-interval-trade показувала найгіршу похибку дальності 1,6 мм за підгонки на 60 с і 40,3 мм за підгонки на 900 с; тепер сайт зібрано з рушія цього випуску, і він показує 1,8 мм і 46,6 мм.
• Карта зони глушіння на kshana.dev (Missions). Кожна з її 875 комірок — це один прогін maritime-strait-jamming, у якому змінено лише позицію приймача. Тепер комірки обчислюються з тих самих координат із трьома десятковими знаками, які посилання комірки «відкрити цей прогін» передає в Kshana Studio, тож комірка показує точно те, що відтворює її посилання. Середнє відношення потужності глушника до потужності сигналу (J/S) для 30 комірок змінюється на 0,1 дБ, у більший або менший бік; доступність відстеження не змінюється в жодній комірці. Рушій дає однакові результати для кожної комірки у 0.28.0 і 0.29.0.
• Передвибірка із зерном (seed) у пакеті WebAssembly (WASM). Збірка для браузера з того самого зерна (за Fixed) брала інші індекси бутстрепу й перемішування, ніж нативна. Інтервал quantum-anomaly-detect площі під кривою в браузері становив [0.9901265, 0.9938305], а тепер дорівнює нативному [0.99035875, 0.993861]. Жодне нативне число не змінюється.

Показники, надруковані в документації

Документацію було перевірено слово за словом за прогонами рушія цього випуску. Там, де надрукований показник не збігався з прогоном, документ виправляли, і кожне виправлення наведено тут у вигляді «було → стало». У кожному випадку нижче вихідні дані рушія не змінилися; документ був прочитаний хибно, округлений хибно або застарів.

• Аудит документації сторінок про спектр, орбітальні угруповання, кампанії, анімацію, звіти та сумісність і новий docs/SOLAR-SYSTEM.md. Кожен показник було повторно отримано цим рушієм. Змінюються два опубліковані числа: docs/CONSTELLATION-DESIGN.md наводив тест покриття для 5 000 супутників як «приблизно 0,13 с у збірці debug»; це не відтворилося (1,24 с на завантаженому ноутбуці), тож тепер сторінка наводить частку попереднього фільтра, яку друкує тест (9,9 % із 19 440 000 перевірок пар), і 0,14 с випускного бінарника для вбудованого leo-pnt-mega-shell. Та сама сторінка вказувала перетин E3F як «відхилення на 0,050 град»; жоден тест не друкує цього показника, тож тепер сторінка наводить лише поріг 0,06 град, який забезпечує тест, і виведення 7,30 проти 7,36 град, що за ним стоїть. Вихідні дані рушія не змінюються.
• Документи LEO-PNT: переглянуті опубліковані показники (повторно отримані рушієм цього випуску). docs/LEO-SIGNAL.md, вибір діапазону: іоносферна затримка першого порядку для generic-s становить 3,24 м (було надруковано 3,25 м), а для generic-c-wide — 0,77 м (було 0,78 м). docs/LEO-NAVMSG.md, кодування й декодування: SISRE декодованого повідомлення було надруковано як 0,119 см, тоді як прогін дав 0,122 см; тепер сторінка друкує 0,129 см, показник після виправлення незалежності від платформи за Fixed нижче. docs/LEO-PASS.md, прохід LEO порівняно з GNSS: на 32 дБ менше втрат у вільному просторі на піку проходу (було «від 26 до 32 дБ»). Щодо показників сигналу й проходу, вихідні дані рушія не змінилися; документи були прочитані або округлені хибно.
• Навчальні посібники, приклад наскрізного конвеєра та команда /kshana-run, перевірені за рушієм цього випуску. Перегляди опублікованих показників, «було → стало»: видів, що записують <scenario>.table.csv, шість, а не чотири (leo-navmsg і telecom-timing бракувало; docs/tutorials/README.md, commands/kshana-run.md); перетин холодних атомів ½bT² у посібнику 3 становить 18 443 с, а не 18 440 с; похибка кругового проходу oem-interop у docs/examples/multi-tool-pipeline.md становить виміряні 4.88e-7 км, а не «~1e-7 км»; смуга holdover CSAC у посібнику 2 становить 2000–3200 с, які стверджує тест, а не «~2600–4400 с»; посібник 1 наводить рядки SP3 і блок геометрії з тією точністю, з якою їх записує рушій. Вихідні дані рушія не змінилися.
• Сторінки про перевірку, квантові системи, SGP4, анімацію, твердження та цілісність. docs/VALIDATION.md: примусовий поріг для змодельованої односекундної девіації Аллана годинника з білим частотним шумом становить 20 % (було надруковано 25 %; поріг 25 % — той, що стосується кривої при 1, 10 і 100 с); рядок блукання швидкості з випадковою складовою тепер указує свій примусовий поріг 20 % поряд зі спостережуваними приблизно 12 %; а доступність чипового атомного годинника в orbit-gnss-challenged становить приблизно 0,73 (було надруковано приблизно 0,83). docs/QUANTUM.md: обмежений вібраціями шум за один постріл у робочому прикладі холодних атомів на сторінці перевищує свій поріг дробового шуму приблизно в 46 раза (було «~45×»; перераховано 46,49), а діапазон «1–50 мкг/√Гц» для польових пристроїв, що суперечив пристрою, який сама сторінка цитує, замінено опублікованими показниками двох цитованих пристроїв. docs/SGP4-VALIDATION.md: найгірша різниця позицій становить 4,12 мм (було «≈ 4 мм») із зазначенням супутника. docs/ANIMATION.md: приклад відеокодера читав кадри з частотою 24 кадри на секунду як 12; тепер він використовує 24, частоту, яку вказує маніфест кадрів. docs/CLAIMS-VS-REALITY.md: модель глушіння має 10 тестів (було 8), а «2,97 м проти 48,8 м» для зв'язаного фільтра замінено тим, що стверджує його тест (похибка позиції зв'язаного фільтра менша за 0,6 від похибки незв'язаного, із перемогою щонайменше в 90 зі 100 випробувань). docs/INTEGRITY.md: позначка «Today» читала v0.22.0; тепер вона називає цей випуск, а дві можливості, створені відтоді (режим несправності всього орбітального угруповання та допоміжне повідомлення цілісності), виходять зі списку прогалин.

Додано#

Спектр

• Вид сценарію spectrum: модель спектра L-діапазону та водоспад (src/spectrum.rs, src/sigmf.rs, docs/SPECTRUM.md). Увесь L-діапазон GNSS як одна спектральна густина потужності (PSD): GPS L1 грубого коду захоплення (C/A) і L2 цивільний (L2C) (BPSK(1)), Galileo E1 (мультиплексована двійкова зсувна несівна, MBOC(6,1,1/11), або BOC(1 1)), GPS L5 і Galileo E5a (BPSK(10)), шумовий поріг kT із коефіцієнтом шуму приймача, а також глушники неперервної хвилі (CW), вузькосмугові, чирп і зі зіставленим шумом за сценарним графіком. Кожен глушник оцінюється для кожного діапазону за своїм коефіцієнтом спектрального розділення (SSC), що дає відношення потужності глушника до потужності сигналу (J/S) і ефективне відношення потужності несівної до спектральної густини шуму (C/N0) для кожного діапазону в кожному рядку. Діаграма — це водоспад у форматі SVG зі стовпчиками C/N0; result.json містить сітку, усереднену блоками за потужністю. Необов'язковий [iq] малює модель як відліки IQ, записує та читає запис у форматі метаданих сигналу (SigMF) (cf32_le, ci16_le) і порівнює оцінку Велча з моделлю; необов'язковий [recording] оцінює справжній файл SigMF. Вбудований приклад scenarios/l-band-waterfall-jamming.toml: чирп захоплює L1 C/A та E1 на 10 с, тон CW на несівній L1 утримує C/A на 17,98 дБ-Гц після завершення чирпу, тоді як E1, спектр якого має там нуль, відновлюється; L5 і E5a не зачеплено.
  • Новий рядок VALIDATED: PSD сигналів і SSC, зіставлені з головною пелюсткою BPSK(n) шириною 2n x 1,023 МГц, пелюстками BOC(1 1) із центрами на +/-1.023 МГц, замкненими формами Парсеваля, що стоять за опублікованими SSC -61.8 / -64.8 / -67.8 дБ/Гц, і підручниковими Q = 1 (CW) та 1,5 (зіставлений шум). Максимум PSD BOC(1 1) лежить на +/-0.759 МГц, а не в центрі пелюстки; тест фіксує обидва.
  • Два нові рядки MODELLED: водоспад і часова лінія C/N0, які точно зводяться до ланцюжка виду jamming (перехресно перевіряється в кожному звіті), а також кодек SigMF і оцінювач Велча. У репозиторії немає жодного запису від третьої сторони.
  • navsignal: варіант MBOC і spectral_separation_coeff_offset.
  • Звіт друкує C/N0, яке дала б репрезентативна таблиця Q виду jamming, поряд із виведеним зі спектра; для тону CW на несівній C/A вони розходяться на 1,8 дБ. Три нові рядки матриці: один перевірений за зовнішнім еталоном (спектри сигналів і коефіцієнти спектрального розділення) і два обчислені за моделлю.

Сонячна система

• Ефемериди Сонячної системи та позиціонування навколо будь-якого тіла. Два нові види сценаріїв.
  • solar-system: Сонце, вісім планет, Плутон, Місяць, Фобос, Деймос, Іо, Європа, Ганімед, Каллісто й Титан на одну епоху: геліоцентрична позиція та швидкість у Міжнародній небесній системі відліку (ICRF), гравітаційний параметр, радіуси, J2 (друга зональна гармоніка), де опубліковано, зоряне обертання, полюс і початковий меридіан за Міжнародним астрономічним союзом (IAU), траса орбіти за один оберт, а також світловий час, односторонній і двосторонній діапазон, сонячна затримка Шапіро й кутова відстань від Сонця для тіла-спостерігача та для будь-якого додаткового зв'язку. Планети беруться з кеплерових елементів Лабораторії реактивного руху (JPL) від Стендіша та Вільямса (таблиця 1, від 1800 AD до 2050 AD; таблиці 2a/2b, від 3000 BC до 3000 AD); супутники — із середніх елементів JPL із синхронною швидкістю обертання за IAU, а Титан — із моделі обертання IAU. Приклад: scenarios/solar-system-tour.toml.
  • body-pnt: орбітальний апарат або поверхневий посадковий модуль навколо будь-якого з цих тіл, що навігує за псевдодальностями від орбітального угруповання Волкера навколо тіла та за двостороннім діапазоном із Землі, вільним від годинника; геометричний чинник погіршення точності, формальна невизначеність і розв'язки найменших квадратів із зерном із зв'язком із Землею та без нього. Приклади: scenarios/mars-orbit-pnt.toml, scenarios/europa-surface-pnt.toml.
  • Body отримує Меркурій, Венеру, Юпітер, Сатурн, Уран, Нептун, Плутон і сім супутників, пошук за назвою та фізичний запис; AnalyticSolarSystem дає будь-яке тіло відносно будь-якого іншого через наявний шов EphemerisProvider.
  • VALIDATED за JPL Horizons (Development Ephemeris DE441; еталонні дані та запити в tests/fixtures/solar_system/): від Меркурія до Сатурна та Земля з таблиці 1 у межах подвійної заявленої номінальної похибки (найгірше 1,87 раза), усі вісім планет із таблиць 2a/2b (найгірше 1,71 раза) і світловий час Земля — Марс та Земля — Юпітер. MODELLED: Уран і Нептун із таблиці 1, які перевищують заявлену похибку відносно DE441 (2,0 і 5,2 раза), Плутон, супутники, константи тіл і результати body-pnt.
  • Знахідка: місячний ряд Монтенбрука та Гілла в src/ephem.rs уже приведений до рівнодення J2000 власним членом прецесії (0,05 градуса від Horizons), тож його використовують без додаткового обертання прецесії. Шість нових рядків матриці: два перевірені за зовнішнім еталоном (позиції планет, світловий час) і чотири обчислені за моделлю.

Орбітальні угруповання навколо будь-якого тіла

• Проєктування орбітальних угруповань у великому масштабі (вид constellation-design, src/constellation.rs). Візерунки Волкера «дельта» та «зірка» (T/P/F), явні списки елементів і багатошарові конструкції, кілька угруповань за прогін, навколо Землі, Місяця, Марса чи будь-якої іншої планети, Плутона або великого супутника за константами тіл, які додав вид solar-system. Пресети з опублікованих номінальних елементів: базове й розширюване 24-слотове угруповання Глобальної системи позиціонування (GPS) (Стандарт характеристик стандартної служби позиціонування, SPS PS, 2020), Galileo Walker 24/3/1 (Open Service Service Definition Document, випуск 1,1), BeiDou середньої навколоземної орбіти Walker 24/3/1 плюс геостаціонарні та нахилені геосинхронні супутники (Open Service Performance Standard 3,0) і GLONASS 24/3/1 (Interface Control Document 5,1). Покриття та геометричний чинник погіршення точності (DOP) за сіткою широти й довготи: супутники у видимості, GDOP, PDOP, HDOP і VDOP (геометричний, у позиції, горизонтальний, вертикальний) та доступність у кожній комірці, глобально та в найгіршому місці, з одним годинником приймача на угруповання. Попередній фільтр видимості (половинний кут покриття плюс смуга широт підсупутникової точки, точний на сферичному тілі) опрацьовує 5 000 супутників на сітці 10 град приблизно за 0,13 с у збірці debug.
  • VALIDATED: генератор Волкера відтворює таблицю 23 Galileo OS SDD і формулу слотів GLONASS ICD; пресет GPS відтворює стовпець перетину екватора SPS PS (35 із 36 місць у межах 0,0108 град; E3F у межах 0,06 град, оскільки власний рядок таблиці суперечливий); глобальний розподіл HDOP базового GPS збігається з додатком B до SPS PS (медіана 0,940 проти 0,94, 95 % — 1,255 проти 1,25, середнє 0,965 проти 0,96; поріг 0,03).
  • MODELLED: довільні конструкції, інші тіла, фазові та нахилені геосинхронні вузли BeiDou, двотілові орбіти з необов'язковим J2, лише геометрія.
  • Сценарії: constellation-multi-gnss-coverage (102 супутники, доступність 100 %, медіана PDOP 0,95, 31,0 у видимості вище 10 град), leo-pnt-mega-shell (5 000 супутників, доступність 99,22 % за PDOP 3 або менше вище 20 град, 0 % на полярних шапках, попередній фільтр залишає 11,5 % перевірок пар), lunar-relay-constellation (14 супутників навколо Місяця, доступність 21,33 % загалом і найвища над південним полярним районом). Усі три вбудовано для kshana example. Примітки: docs/CONSTELLATION-DESIGN.md. Три нові рядки матриці: два перевірені за зовнішнім еталоном (генератор Волкера та пресети GNSS, глобальний DOP GPS) і один обчислений за моделлю.
• Кампанія, керована моделлю спектра, та орбітальні угруповання навколо будь-якого тіла. scenarios/campaign-spectrum-holdover-integrity.toml з'єднує вид spectrum із утриманням годинника (holdover) та монітором цілісності (чирп захоплює L1 C/A та E1; тоді тон CW утримує C/A пригніченим, поки E1 відновлюється, а приймач переходить на небо лише з Galileo), зіставлений із самостійним прикладом водоспаду в tests/campaign_composition_reference.rs. constellation-design тепер визначає свій центральний об'єкт через Body::by_name, тож орбітальне угруповання можна розмістити навколо будь-якої планети, Плутона чи великого супутника за константами, які використовує вид solar-system.

Кампанії

• Кампанії: багато сценаріїв, складених в один прогін. Новий вид campaign (src/campaign.rs, описаний у docs/CAMPAIGNS.md) запускає члени наявних видів через ту саму диспетчеризацію, що й командний рядок, і зчитує числа з їхніх результатів. Чотири розділи в будь-якому поєднанні:
  • [[phases]]: ланцюжкова місія на одній часовій шкалі. Пресети для окремих видів зіставляють похибку часу годинника з її межею, середнє ефективне відношення потужності несівної до спектральної густини шуму (C/N0) із порогом відстеження, вертикальний рівень захисту з межею тривоги, похибку позиції, кількість супутників у відстеженні та прапорці тривог, утримані на спільній сітці з межами фаз і подіями. Стан передається через carry, handoff і end_at.
  • [sweep]: від одного до трьох ключів із крапками будь-якого виду, за бажання із ансамблем із зерном у кожному вузлі.
  • [monte_carlo]: реалізація k із базовим зерном + k, із середнім, розкидом, перцентилями та бутстреп-довірчим інтервалом 95 % із фіксованим зерном.
  • [compose]: спільні значення, прив'язані до кількох членів, зі зведенням найкращого та найгіршого. Кожен результат містить геш кампанії та дайджест за результатами всіх членів. Чотири вбудовані сценарії: campaign-jam-spoof-holdover-integrity (номінальний режим, глушіння, спуфінг, що закінчується на виявленні монітором годинника на 370 с, holdover із зсувом 37,0 нс від спуфінгу під час інерціального руху, тривога цілісності, відновлення), campaign-sweep-jammer-power, campaign-shared-jammer-sea-road і campaign-monte-carlo-clock-holdover. tests/campaign_composition_reference.rs фіксує тотожності композиції: однофазова кампанія відтворює самостійний прогін біт у біт для трьох видів, ансамбль із фіксованим зерном стабільний на рівні байтів, а для годинника з білим частотним шумом середнє ансамблю лежить усередині повідомленого інтервалу, а розкид — усередині інтервалу хі-квадрат для sqrt(q_wf * tau) = 16,459 нс. Три нові рядки матриці, обчислені за моделлю.

Анімація

• Експорт анімації (--animate svg|html|frames|all, src/animation.rs, docs/ANIMATION.md). Будь-який прогін, чий результат містить часовий ряд, тепер можна записати як анімований файл масштабованої векторної графіки (SVG) (ключові кадри каскадних таблиць стилів, без скрипта: криві домальовуються за рухомим курсором часу), єдиний самодостатній програвач мовою гіпертекстової розмітки (HTML) (відтворення й пауза, перемотування, швидкість, усі панелі на одному синхронізованому курсорі, маркери подій, що перемотують за кліком; без зовнішніх ресурсів) або пронумеровану послідовність кадрів SVG із manifest.json, що вказує кадри на секунду, тривалість і моменти кадрів для відеокодера. Кампанія програється як її фази з позначеними тривогами; прогін спектра анімує свій водоспад рядок за рядком. Програвач дотримується prefers-color-scheme, а за prefers-reduced-motion і SVG, і програвач показують завершену картинку замість руху. --animate-fps і --animate-duration задають відтворення; kshana::api::animate_toml і kshana::animation::animate_result — точки входу бібліотеки, а result.json отримує блок animation лише тоді, коли виконується --animate. Вихід — чиста функція результату й параметрів, ідентична байт у байт за повторного запуску, без позначки часу. Вид без дискретизованої осі часу відхиляється з повідомленням «no time series to animate», і нічого не записується. Експортер малює власні відліки прогону і не додає жодного числа, тож він MODELLED (внутрішня узгодженість) і не має рядка матриці верифікації; жодне опубліковане число не змінюється. Тести: tests/animation.rs (детермінізм, кількість кадрів, відсутність зовнішньої адреси, коректно сформований XML, шлях зменшеної анімації та анімування кожного вбудованого сценарію з часовим рядом).

Звіти

• Розширені звіти про прогони (src/advanced_report.rs, docs/REPORTS.md). Кожен прогін через інтерфейс командного рядка (CLI) тепер записує <scenario>.report.html, друкований звіт мовою гіпертекстової розмітки (HTML), і <scenario>.report.json, той самий вміст як машинозчитуваний документ в об'єктній нотації JavaScript (JSON). Розділи: підсумок для керівництва; кожен вхід сценарію з його одиницею, прочитаною зі схеми одиниць полів (блок units результату), інакше із суфікса імені поля, інакше позначений як не вказаний; результати з діаграмою прогону, кожним скаляром і зведенням кожного числового стовпця; для кампанії — таблиця вузлів перебору, середнє Монте-Карло, стандартне відхилення, 5-й / 50-й / 95-й перцентилі та бутстреп-довірчий інтервал із гістограмою для кожної метрики, таблиця фаз ланцюжка або члени композиції та зведення (і сітка прогону sweep або sweep-nd); часова лінія подій; позначка VALIDATED / MODELLED / PARTNER, оракул і тестові докази кожного рядка матриці верифікації, який задіюють види прогону, прочитані з матриці через відповідність виду до рядка (рядок, що оцінює один шлях входу, наприклад шлях Simplified General Perturbations 4 (SGP4) для orbit або шлях виміряного запису для slot-timing, наводиться лише тоді, коли прогін пішов цим шляхом, а рядок читача Радарної топографічної місії «Шаттла» (SRTM) не наводиться для жодного виду, оскільки жодне поле сценарію не читає плитку SRTM); твердження про те, що не змодельовано, і припущення, кожне з цитуванням свого джерела; і запис відтворюваності (версія рушія, коміт джерела, коли збірка задає KSHANA_GIT_COMMIT, дайджести безпечного гешувального алгоритму 256-бітного (SHA-256) для файлу сценарію й документа результату, зерно, платформа та точна команда). Звіт не читає годинника: той самий сценарій, зерно та збірка рушія дають звіт, ідентичний байт у байт, а єдина позначка часу, яку він може показати, — та, що вже записує --study-name. Таблиця стилів друку вміщується на A4 і US Letter, повторює заголовки таблиць і не розриває рядки й рисунки між сторінками; файл у переносному форматі документа (PDF) створюється через «Зберегти як PDF» у браузері. Параметра --report pdf немає, бо відтворення діаграм у PDF потребувало б нової важкої залежності. Тести: tests/advanced_report.rs звітує про кожен вбудований сценарій (жодного порожнього розділу, жодного тексту-заповнювача, позначки дорівнюють матриці, дайджест сценарію дорівнює дайджесту файлу, ідентичність байт у байт за повторного запуску), а tests/advanced_report_cli.rs повторно виконує записану команду в новій теці й вимагає result.json, ідентичного байт у байт. Жодне опубліковане число не змінюється, а кількість видів, файлів сценаріїв і рядків матриці лишається тією самою.
• Звіт, анімація та експорти працюють разом. Розширений звіт отримує розділ «Animation and exports»: анімований малюнок прогону, вбудований як інертне зображення (або причина його відсутності), посилання на файли анімації та експорту, записані поруч, і кожен формат сумісності з указівкою, чи він застосовний, чому ні, і його специфікацією; report.json містить той самий блок companions. HTML-програвач анімації перелічує файли експорту, записані поруч. Інтерфейс командного рядка (CLI) тепер виконує експорти до запису звіту, тож обидва можуть називати файли.

Експорти для сумісності

• Експорти та імпорти для сумісності (--export, src/interop/, docs/INTEROP.md). kshana <scenario.toml> --export <format> записує геометрію сценарію як CZML (Cesium Language), KML (Keyhole Markup Language 2,2, стандарт Open Geospatial Consortium, із часовими треками gx:Track), GeoJSON (Internet Engineering Task Force Request for Comments 7946) та ефемериди Ansys STK (Systems Tool Kit) .e (EphemerisTimePosVel, метри, один файл на рухомий об'єкт), а синтезований знімок IQ (синфазна та квадратурна складові) виду spectrum — як пару SigMF (формат метаданих сигналу) через наявний src/sigmf.rs. --export all записує кожен застосовний формат і друкує, чому інші не застосовні; --export list звітує без запуску. Рухомі об'єкти записуються в Геоцентричній небесній референцній системі (CZML INERTIAL, STK ICRF) і в довготі, широті та висоті Earth-fixed WGS 84 (Всесвітня геодезична система 1984) (KML, GeoJSON); нерухомі пункти в CZML — FIXED. Вид jamming додає два сліди глушника за власними рівняннями зв'язку. --import-route <file.geojson> записує GeoJSON LineString у входи треків terrain-nav, terrain-slam, gravity-map і combined-altpnt. Експорти детерміновані на рівні байтів і не містять позначки часу. tests/interop_formats.rs перевіряє кожен експорт за його опублікованою специфікацією, порівнює експортовані стани супутників із власними станами рушія з точністю до 1 мм і пропускає кожен вбудований сценарій через кожен формат, при цьому кожен або експортується, або вказує, чому ні (таблиця в docs/INTEROP.md). Жодне опубліковане число не змінюється: синтез IQ виду spectrum перенесено до однієї спільної функції, а його документ результату ідентичний байт у байт, і PassesScenario отримує propagator() та epoch_calendar(), що їх використовує власний прогін. Кількість видів, файлів сценаріїв і рядків матриці верифікації не змінюється. Сценарій орбіти чи цілісності без epoch датується власними даними своїх супутників: t = 0 — найраніша епоха TLE (дворядкового набору елементів орбіти), бортових ефемерид або SP3 (Standard Product 3), і кожен такий супутник обертається в системи GCRS та жорстко пов'язану із Землею в його власний момент; 2000-01-01T00:00:00Z використовується лише тоді, коли жоден супутник не має епохи. Експорти SP3 і OEM (Orbit Ephemeris Message) зберігають мітку 2000-01-01. Для цього додано Sgp4::epoch_jd_utc, Sp3Interpolator::jd_ut1 і Propagator::own_jd_utc; нічого з наявного їх не читає.

Навігація низькою навколоземною орбітою: сигнал

• Конструкції сигналів LEO-PNT і багатодіапазонний спектр. Новий вид leo-signal і вид spectrum, що виходить за межі L-діапазону: один вид, чотири файли сценаріїв (три вбудовані; файл Celeste IOD лише для репозиторію) і чотири рядки матриці (два VALIDATED, два MODELLED).
  • leo-signal: параметризовані конструкції сигналів позиціонування, навігації та часу (PNT) низької навколоземної орбіти (LEO) для будь-якої системи (діапазон, ширина смуги передавання, виділення ITU; компоненти захоплення, даних і пілотні з BPSK(n), BOC(m,n), MBOC або плоскими спектрами, частками потужності, піднесучими FDMA, довжинами кодів і швидкостями даних), зі скомпільованих публічних файлів пресетів у data/leo-signals/ (Xona Pulsar X1/X5, Iridium STL, сигнал нагоди Starlink, CentiSpace, репрезентативна конструкція C-діапазону та репрезентативні конструкції UHF/L/S/C/широкого C, кожна із зазначенням URL свого джерела) або записаних безпосередньо. Для кожного сигналу: обмежена діапазоном PSD і частки потужності в смузі, габорівська ширина смуги, обмежений діапазоном флуктуаційний шум відстеження коду «випереджальний-запізнювальний» залежно від C/N0 та інтервалу (Betz & Kolodziejski 2009) і точність визначення дальності, простір пошуку захоплення, ймовірність виявлення та середній час послідовного й кодово-паралельного захоплення, SSC до та від GPS L1 C/A, Galileo E1, GPS L5, Galileo E5a, E5b і AltBOC із втратою C/N0, допуски J/S для CW, широкосмугового та зіставленого шуму за кодом SSC виду spectrum, вибір діапазону (іоносферна затримка, втрати у вільному просторі, визначення дальності за однакового C/N0 і однакової EIRP, стійкість до глушіння) і необов'язкові перевірки форми за описаним вимірюванням. Приклади: scenarios/leo-band-trade.toml, scenarios/xona-pulsar-signals.toml, scenarios/celeste-iod-classical-pilot-signals.toml (діапазони й конфігурація сигналів Celeste IOD, представлені на семінарі ESA NAVISP LEO-PNT, 2026; вилучаються разом із пресетом Celeste IOD, див. «LEO-PNT end to end» нижче). Примітки в docs/LEO-SIGNAL.md.
  • spectrum: діапазони тепер можуть бути пресетом конструкції сигналу (кожен компонент намальовано, обмежено діапазоном, C/N0 і J/S віднесено до відстежуваного компонента) або власною несівною та модуляцією; [[panels]] додають водоспади за іншими діапазонами частот на одній часовій шкалі; глушник wideband (загороджувальний) приєднується до чотирьох форм сигналу. Звіт додає bands[].tracked_power_dbw, bands[].design і panels та один запис not_modelled. Прості діапазони дають ті самі числа, що й раніше. Приклад: scenarios/multi-band-jamming-waterfall.toml.
  • navsignal отримує інтегральний синус, замкнені форми потужності BPSK в смузі та габорівської ширини смуги, обмеженої діапазоном, флуктуаційний шум «випереджальний-запізнювальний», обмежений діапазоном, для будь-якого спектра та його габорівську межу, замкнену форму SSC зсунутого BPSK, спектр Galileo E5 AltBOC(15 10) і розбирач міток модуляції; Modulation::label друкує BPSK(1/3) як дріб.
  • Чотири рядки матриці: VALIDATED замкнені форми, обмежені діапазоном (90,3 % потужності BPSK в головній пелюстці, флуктуаційний шум, що зводиться до когерентної форми Каплана та Гегарті, 0,0039564 чіпа за 45 дБ-Гц, B_L 1 Гц, d 1 чіп, T 20 мс, і до своєї габорівської межі, а також власний SSC BPSK 2/(3 R_c); габорівська замкнена форма та зсунутий SSC відносно його форми Парсеваля викладено як внутрішні перехресні перевірки); VALIDATED максимальний доплерівський зсув LEO (Xona X1 33,2 кГц усередині опублікованих від 32 до 34 кГц, Iridium у межах 0,5 кГц від 36 кГц); MODELLED leo-signal; MODELLED багатодіапазонний спектр.

Навігація низькою навколоземною орбітою: лінія зв'язку

• Прохід LEO-PNT і бюджет лінії зв'язку за діапазонами: вид leo-pass. LEO-PNT — це позиціонування, навігація та час із супутників на низькій навколоземній орбіті (LEO). Користувач (наземний, морський, повітряний або в приміщенні, нерухомий чи рухомий) і один або кілька супутників LEO із розрахованого проходу, явних елементів, дворядкового набору елементів орбіти (TLE) через SGP4 або орбітальне угруповання Волкера за кодом constellation-design. Для кожного супутника, діапазону та епохи: кути огляду, дальність, замкнена форма швидкості зміни дальності та прискорення дальності (перевіряється під час кожного прогону за центральними різницями), доплерівський зсув і його швидкість, втрати у вільному просторі, EIRP (еквівалентна ізотропно випромінювана потужність) із ізофлюксною, гауссовою або плоскою діаграмою супутника, патч-антена користувача, газове загасання за ITU-R P.676, загасання в дощі за ITU-R P.838/P.618, тропосферна сцинтиляція за P.618, втрати на проникнення в будівлю за ITU-R P.2109 для користувача в приміщенні, поляризаційна розузгодженість, шумова температура системи та C/N0 (відношення потужності несівної до спектральної густини шуму); іоносферна затримка першого порядку для кожного діапазону з нахиленого TEC (повного електронного вмісту) за Клобучаром або за вертикальним TEC під супутником, а також безіоносферні пари діапазонів з їхнім підсиленням шуму. Супутники Galileo або GPS оцінюються тим самим приймачем за прийнятими потужностями з документів інтерфейсу, тож дзвоноподібний прохід LEO та плоскі несівні MEO (середньої навколоземної орбіти) ділять один графік. Розділ [iot] дає час до першого визначення місцеположення, енергію на визначення та час роботи від батареї залежно від скважності (MODELLED).
  • Незалежність від системи: рушієві не потрібен жоден пресет. Необов'язкові пресети, кожен у власному файлі та позначений PUBLIC (з URL), REPRESENTATIVE або WORKSHOP: загальний багатодіапазонний (UHF, L, S, C), загальний C-діапазон, Xona Pulsar X1/X5 (arXiv 2509,19551), Iridium STL, Starlink як сигнал нагоди лише з Доплером, CentiSpace і Celeste IOD (демонстрація на орбіті), параметри сигналів якого було представлено на семінарі ESA NAVISP LEO-PNT, 2026, і які містяться в src/celeste_iod.rs, щоб їх можна було вилучити (див. «LEO-PNT end to end» нижче).
  • Публічні будівельні блоки в src/leo_link/ (geometry, antenna, itu, iono, energy, presets), які можуть викликати інші модулі.
  • Сценарії: leo-pass-vs-gnss-cn0, leo-indoor-uhf, leo-iot-energy, leo-pass-xona-pulsar, leo-pass-iridium, leo-pass-celeste-iod-multiband.
  • Дев'ять рядків матриці. VALIDATED (6): коефіцієнти ITU-R P.838-3 відносно його таблиці 5; загасання в дощі та сцинтиляція за P.618-14 відносно прикладів перевірки Групи досліджень ITU-R 3; втрати на проникнення в будівлю за P.2109 відносно робочої книги Групи досліджень 3; іоносферне масштабування першого порядку відносно відношення групових затримок IS-GPS-200 разом із втратами у вільному просторі; максимальний доплерівський зсув кругової орбіти для нерухомого користувача відносно таблиці 1 з arXiv 2509,19551. MODELLED (3): прохід і бюджет лінії зв'язку, пресети та бюджет визначення місцеположення з малою витратою енергії. Один вид і шість файлів сценаріїв. Примітки в docs/LEO-PASS.md.

Навігація низькою навколоземною орбітою: навігаційне повідомлення

• Навігаційне повідомлення LEO (вид leo-navmsg, src/leo_navmsg/). Широкомовне повідомлення ефемерид і годинника супутника позиціонування, навігації та часу (PNT) на низькій навколоземній орбіті (LEO) для будь-якої орбіти, несівної та моделі; названі пресети — необов'язкові дані, і кожна можливість працює без них. Один вид, п'ять файлів сценаріїв і дев'ять рядків матриці (три VALIDATED, шість MODELLED). Див. docs/LEO-NAVMSG.md.
  • Вміст повідомлення: SVID, випуск даних, діапазон і справність сигналу; тиждень, час тижня та поліном годинника другого порядку; ефемериди в одній із чотирьох моделей — 16-параметричний кеплерів набір Galileo OS SIS ICD, цей набір плюс поліноми поправок за напрямком руху, поперек треку й радіальні, 22-параметрична модель Liu et al. 2025 (doi 10.3390/rs17162894) або поліном ECEF ATOMIC з нульовим годинником — а також набір Клобучара, коефіцієнти NeQuick-G з ефективним рівнем іонізації та параметри переходу від системного часу до UTC зі випадками ICD щодо додаткової секунди.
  • Підганяч: істинна орбіта, проінтегрована із зональною гравітацією J2–J6 або EGM2008 і опором, вільний або керований годинник із зерном (seed), підгонка Левенберга–Марквардта на неособливих елементах, потім лінійні поліноми поправок за найменшими квадратами та годинник, підігнаний з вирахуванням релятивістського члена користувача.
  • Чотири аналізи та сценарії: leo-navmsg-fit-interval-trade (похибка дальності сигналу в просторі (SISRE) залежно від інтервалу підгонки та періоду оновлення), leo-navmsg-model-comparison (чотири моделі, біти та 22-параметрична підгонка Kshana на висотах Liu et al. поряд з опублікованими показниками, MODELLED), leo-navmsg-midpass-update (безперервність за кожного перемикання повідомлення в проході) і leo-navmsg-encode-decode (власний документований двійковий кадр Kshana з CRC-24Q і бюджетом квантування, блок у стилі RINEX-4 з позначкою розширення Kshana та таблиця CSV).
  • VALIDATED: глобально усереднені ваги SISRE відносно опублікованої таблиці середньої орбіти та геостаціонарної орбіти Монтенбрука та ін. 2018; користувацький алгоритм Galileo відносно RTKLIB на чотирьох справжніх широкомовних ефемеридах Galileo (tests/leo_navmsg_reference.rs); CRC-24Q відносно контрольного значення каталогу та прикладу кадру RTCM 10403 1005.
  • Пресети, по одному файлу з джерелами: Xona Pulsar і Pulsar-0, Iridium, Starlink, CentiSpace, репрезентативна система C-діапазону, ATOMIC і Celeste IOD (єдиний пресет, що використовує матеріал, представлений на семінарі ESA NAVISP LEO-PNT, 2026, збережений у src/celeste_iod.rs разом зі своїми сценаріями, щоб його можна було вилучити).

Навігація низькою навколоземною орбітою: злиття

• Злите позиціонування, навігація та час MEO + LEO: leo-pvt, leo-ppp і ntn-positioning. Три нові види сценаріїв у src/leo_fusion/, незалежні від системи: кожне орбітальне угруповання — це шари Волкера, набори елементів або пресет GNSS, кожен сигнал — несівна, чіпова швидкість і огинаюча відношення потужності несівної до спектральної густини шуму (C/N0), кожен бюджет похибок — явна одна сигма, а названі системи низької навколоземної орбіти (LEO) — необов'язкові пресети, по одному файлу з їхніми джерелами, позначеними як публічні, семінарські або виведені (Xona Pulsar X1/X5, Iridium Satellite Time and Location (STL), сигнали нагоди Starlink, CentiSpace, репрезентативна система C-діапазону, модель ефемерид ATOMIC з нульовим годинником і один пресет ESA Celeste для демонстрації на орбіті, параметри якого, виведені із семінару, містяться в src/celeste_iod.rs, щоб їх можна було вилучити).
  • leo-pvt має чотири режими: доплерівське позиціонування (пакетний метод найменших квадратів за швидкістю зміни дальності зі станами дрейфу годинника та швидкості, режим сигналів нагоди лише з Доплером, точність за один прохід вздовж і поперек треку, а також огинаюча Доплера, швидкості Доплера та ривка); спільний зважений метод найменших квадратів GNSS + LEO з одним годинником на систему (міжсистемне зміщення) або відомим зсувом, окремими сигмами для кожного вимірювання як входами та DOP залежно від кількості супутників LEO; полярне й арктичне покриття залежно від широти; і передавання часу LEO до всесвітнього координованого часу (UTC) залежно від C/N0 та генератора приймача з виразом IS-GPS-200 для переходу від системного часу до UTC.
  • leo-ppp: розширений фільтр Калмана для плаваючого точного позиціонування окремої точки (PPP) за безіоносферним кодом і фазою, лише GNSS і з доповненням LEO, із часом збіжності та перевіркою узгодженості NEES (нормалізованого квадрата похибки оцінювання) методом Монте-Карло. Вбудований сценарій дає 7,4 хв із чотирма системами MEO та 4,8, 3,2, 2,7 і 2,3 хв із 60, 96, 192 і 288 супутниками LEO, поряд із 9,6, 7,0, 3,2, 2,1 і 1,3 хв у Li et al. (J. Geod. 93:749, 2019) як порівняння тренду, MODELLED.
  • ntn-positioning: позиціонування в нетеррестріальній мережі (NTN) 5G у мобільно-супутниковому S-діапазоні 3GPP n256 за межею Крамера–Рао для часу прибуття та Доплера.
  • Сценарії: leo-doppler-positioning, starlink-sop-doppler-positioning, meo-leo-fused-pvt, leo-ppp-convergence, ntn-5g-positioning, polar-arctic-leo-coverage, leo-timing-utc (вбудовані) і celeste-iod-fused-pvt (лише для репозиторію, вилучається разом із пресетом Celeste IOD).
  • Вісім рядків матриці: огинаюча доплерівського зсуву LEO VALIDATED відносно опублікованих показників Iridium (±36 кГц: 35,9 кГц, у межах 5 %) і Xona Pulsar X1 (від 32 до 34 кГц: 33,6 кГц від оболонки 97 град, без розширення) (tests/leo_doppler_reference.rs); доплерівське позиціонування, спільне позиціонування за псевдодальностями, збіжність PPP, межі NTN, синхронізація часу LEO, полярне покриття та пресети MODELLED. Три види та вісім файлів сценаріїв. Документація: docs/LEO-PNT-FUSION.md.
• LEO-PNT наскрізно: вид leo-pnt-chain і зв'язані між собою етапи LEO. Одна система позиціонування, навігації та часу (PNT) на низькій навколоземній орбіті (LEO) простежується від конструкції сигналу до позиції користувача, кожен етап — власний вид рушія на власній таблиці сценарію, зі значеннями, що передаються далі в коді (docs/LEO-PNT.md):
  • Діапазони leo-pass можуть називати конструкцію leo-signal (signal = "xona-x5"): діапазон бере центр, ширину смуги передавання та чіпову швидкість відстежуваного компонента з конструкції, розподіляє свою EIRP (еквівалентну ізотропно випромінювану потужність) між компонентами конструкції та повідомляє для кожної епохи C/N0 (відношення потужності несівної до спектральної густини шуму) відстежуваного компонента та флуктуаційний шум відстеження коду, обмежений діапазоном (похибку визначення дальності; шум пари iono_free також його використовує). Діапазон без конструкції дає той самий вихід, що й раніше.
  • leo-pnt-chain виконує сигнал -> прохід -> навігаційне повідомлення -> злитий спільний розв'язок leo-pvt -> необов'язковий leo-ppp. Кожна система LEO етапу позиціонування, що залишає їх незаданими, бере лінію C/N0 за sin(висота), підігнану до проходу, похибку дальності сигналу в просторі повідомлення (SISRE: його похибку подання на орбіті супутника проходу із заданим членом визначення орбіти od_sisre_m у кореневій сумі квадратів), а також несівну й чіпову швидкість конструкції; випадки точного позиціонування окремої точки (PPP) беруть SISRE. Кожну передачу значення перелічено з її значенням і одиницею, а tests/leo_pnt_chain.rs перевіряє, що кожна дорівнює виходу попереднього етапу і що зміни попереднього етапу зсувають показники наступного. LeoNavmsgScenario::broadcast_sisre — нова точка входу повідомлення.
  • Сценарії: leo-pnt-end-to-end (загальне угруповання на 1080 км і репрезентативний сигнал generic-l), xona-pulsar-end-to-end (публічний сигнал X5), обидва вбудовані, та необов'язковий celeste-iod-end-to-end лише для репозиторію.
  • Пресети Celeste IOD (демонстрація на орбіті) областей проходу, повідомлення та злитого позиціонування тепер містяться в одному файлі, src/celeste_iod.rs, який build.rs компілює лише тоді, коли він існує (прапорець конфігурації kshana_celeste). Його п'ять сценаріїв (scenarios/*celeste-iod*.toml) лише для репозиторію, тож видалення цього файлу та цих сценаріїв вилучає кожне число, представлене на семінарі ESA NAVISP LEO-PNT, 2026, без правки джерела; tests/workshop_preset_isolation.rs перевіряє, які файли можуть називати пресет або містити числа його частотного плану.
  • Кожен вид LEO у відповідності розширеного звіту, з рядками для окремих шляхів, що наводяться лише тоді, коли прогін пішов цим шляхом (інтенсивність дощу, будівля, аналіз або режим, що виконувався). Доплерівські вікна leo-pvt отримують t_s, а випадки leo-ppp отримують t_min, тож обидва анімуються; leo-pass і leo-pnt-chain експортують ефемериди CZML, KML, GeoJSON та STK, а інші види LEO вказують, чому формат не застосовний.

Навігація низькою навколоземною орбітою: стійкість, цільові області та сценарії кінцевого користувача

• Стійкість LEO-PNT, один сценарій на кожну цільову область експерименту й один на кожну вертикаль кінцевого користувача, а також docs/LEO-PNT.md як огляд кожного виду та сценарію LEO. Кожен сценарій працює без жодних даних Celeste і вбудований.
  • leo-pass отримує розділ [spoofer]: спуфер підробляє, узгоджено за дальністю та швидкістю зміни дальності, сигнали заявленої позиції, що стрибком і/або поступово віддаляється від істинної після початку (для кожного діапазону LEO та для сигналу GNSS MEO), з іоносферою або без неї. Два монітори працюють із заданою ймовірністю хибної тривоги: узгодженість Доплера та геометрії проходу (виміряні швидкості зміни дальності порівняно з прогнозованими за орбітами та незалежною попередньою позицією й швидкістю; узагальнений хі-квадрат найменших квадратів у вікні, за каналами GNSS, LEO та всіма каналами, шум петлі автопідстроювання частоти від C/N0) і міждіапазонна узгодженість (стрибок геометрично вільної комбінації кожної пари діапазонів LEO з поправкою моделі). Результат дає статистики для кожної епохи (тож він анімується), кожну пару та момент, коли кожен монітор виявляє. Будівельні блоки в leo_link::spoof. За відсутності розділу вихід не змінюється.
  • Кожна пара діапазонів leo-pass також повідомляє нахилений повний електронний вміст (TEC), який відновлює її геометрично вільна комбінація на піку проходу, та сигму кодового шуму цієї оцінки (зондування іоносфери). Це додає два поля до кожного багатодіапазонного результату leo-pass; жодне наявне число не змінюється.
  • Режим синхронізації часу leo-pvt приймає trace = true: тоді кожен рядок повідомляє свою похибку часу та прогнозовану сигму в кожній епосі з тими самими вибірками, тож статистики рядків не змінюються, а прогін анімується та вписується в ланцюжок кампанії.
  • Кампанія тепер експортує кожен сценарій-член, що має геометрію (прогони фаз, базові сценарії перебору та Монте-Карло, складені члени з прив'язаними спільними значеннями), як власний набір файлів, а мітка члена входить в ім'я файлу; раніше кампанія нічого не експортувала. Таблицю сумісності в docs/INTEROP.md відповідно змінено.
  • Ключ перебору кампанії може індексувати масив таблиць за позицією (system.2.sisre_m).
  • Сценарії стійкості: leo-resilience-multiband-diversity (загороджувальний сигнал в L5-діапазоні шириною 50 МГц із переборою потужності: кожен сигнал L-діапазону падає, а сигнали LEO в UHF, S- і C-діапазонах зберігають свій C/N0), leo-resilience-js-margin (запас J/S за прийнятою потужністю: GPS L5, Galileo E5a і Xona X5 втрачені на -105, -100 і -95 дБВт, загальний сигнал LEO на -135 дБВт усе ще відстежується на -90 дБВт), leo-resilience-spoof-doppler (стрибок на 30 м, пропущений доплерівським тестом лише за GNSS і виявлений тестом за всіма каналами через 105 с після початку), leo-resilience-spoof-monitors (чотири спуфери проти обох моніторів) і leo-resilience-gnss-jammed-leo-carries (GNSS заглушено, шар LEO в S- і C-діапазонах відстежується, автономний контроль цілісності в приймачі лише за шаром LEO сигналізує тривогу в 2 із 30 епох).
  • Сценарії цільових областей: leo-focus-ppp-altitude, leo-focus-ntn-bandwidth, leo-focus-iot-eirp, leo-focus-science-iono-sounding, leo-focus-data-services, leo-focus-indoor-uhf, leo-focus-fused-pnt-sisre (стійкість в L, S та C — це leo-resilience-multiband-diversity).
  • Вертикальні кампанії, кожна з анімацією та експортом своїх проходів LEO: leo-vertical-autonomous-vehicle, leo-vertical-rail-maritime (вбудовані морські та залізничні сценарії плюс LEO), leo-vertical-critical-infrastructure-timing, leo-vertical-polar-arctic, leo-vertical-5g-network-timing, leo-vertical-asset-tracking-iot. Однорядкові результати в docs/LEO-PNT.md.
  • Три рядки матриці MODELLED: монітор спуфінгу за Доплером і геометрією проходу, міждіапазонний монітор спуфінгу та зондування іоносфери. tests/leo_resilience_verticals.rs перевіряє монітори (мовчать до початку, статистика Доплера квадратична за стрибком, іоносферний стрибок наземного спуфера й відсутність його в спуфера, що враховує іоносферу), тотожність зондування, слід синхронізації часу відносно статистик рядків і те, що експорт кампанії дорівнює власному експорту кожного члена.
  • Сторінка leo-pass переїжджає до docs/LEO-PASS.md; docs/LEO-PNT.md — це огляд.

Морські, дорожні та залізничні сценарії

• Морські, дорожні та залізничні сценарії. П'ять вбудованих прикладів на наявних видах, щоб кораблі, дорожні транспортні засоби та потяги мали по робочому випадку. Кожен показник MODELLED; жоден не перевірений за виміряними даними.
  • scenarios/maritime-strait-jamming.toml (jamming): широкосмуговий глушник потужністю 50 Вт на щоглі висотою 30 м за 30 км від корабля над відкритою водою. Середнє відношення потужності глушника до потужності сигналу (J/S) становить близько 48 дБ, а доступність падає з 1,00 до 0,00.
  • scenarios/maritime-port-approach-coast.toml (ins-trn-coast): інерціальна навігаційна система (INS) навігаційного класу на 12 вузлах із втраченим GNSS і без підтримки. Вона перетинає 10 м через 281 с і 100 м через 833 с — показники заходу в гавань і океанських вод із Резолюції A.1046(27) Міжнародної морської організації (IMO), які тут використано як бюджети.
  • scenarios/maritime-spoof-position-push.toml (spoof-detect): спуфер на +2 дБ без вирівнювання за несівною, який зсуває чотири супутники, щоб відтягнути корабель на 500 м. Злитий монітор виявляє його (оцінка 0,70 проти порога 0,50) за автономним контролем цілісності в приймачі (RAIM) і контролем якості сигналу (SQM); моніторинг лише потужності його пропускає.
  • scenarios/automotive-urban-canyon.toml (gnss-ins): автомобіль, що проїжджає підземний перехід тривалістю 15 с і пропадання сигналу від придорожнього глушника тривалістю 60 с, проти бюджету півсмуги 1,5 м. Середньоквадратична (RMS) похибка під час пропадання сигналу із злиттям становить 1,9 м для блока мікроелектромеханічної системи (MEMS) автомобільного класу та 0,7 м для порівняльного блока тактичного класу; у вільному дрейфі блок MEMS відхиляється на 850,8 м.
  • scenarios/rail-tunnel-coast.toml (ins-trn-coast): INS тактичного класу на потязі зі швидкістю 160 км/год у тунелі. Вона перетинає 2 м (розрізнення колій) через 35,8 с, приблизно на 1,6 км у тунелі, і 20 м через 107,3 с. Це лише INS: у рушія немає моделі одометра, тож це песимістична межа. Кількість файлів сценаріїв у README змінюється з 77 до 82. Усі п'ять вбудовано для kshana example і перелічено в браузерному playground.

Сервер Model Context Protocol

• Сервер Model Context Protocol (MCP) охоплює кожен вид і кожне подання прогону: сім нових інструментів, чотирнадцять загалом. run_scenario уже диспетчеризував кожен вид; агентові бракувало шляху до коректного сценарію виду та до трьох виходів, які командний рядок записує поруч із результатом. Нові інструменти:

  • list_example_scenarios і get_example_scenario віддають вбудовані еталонні сценарії (таблиця kshana example), кожен із його видом і першим реченням його власного заголовка, байт у байт як файл у scenarios/. Сценарій, що є в репозиторії, але не вбудований, відхиляється з указанням причини. Кожен вид, окрім lunar-llr-datum (зріз даних якого постачається лише з репозиторієм), має щонайменше один приклад.
  • report_scenario повертає звіт про прогін як JSON (об'єктну нотацію JavaScript) або як друковану сторінку HTML (мови гіпертекстової розмітки) (docs/REPORTS.md).
  • animate_scenario повертає часовий ряд прогону як анімований малюнок SVG (масштабованої векторної графіки), програвач HTML або пронумеровані кадри, після підсумку JSON про те, що було намальовано (docs/ANIMATION.md). Відповідь містить щонайбільше 120 кадрів; командний рядок записує будь-яку кількість.
  • list_export_formats, export_interop і import_route віддають експорти для сумісності та імпорт маршруту GeoJSON (docs/INTEROP.md): CZML (Cesium Language), KML (Keyhole Markup Language), GeoJSON, ефемериди STK (Systems Tool Kit) .e і SigMF (формат метаданих сигналу), з індексом файлів у JSON (суфікс, розмір і SHA-256, дайджест безпечного гешувального алгоритму 256-бітного) та двійковим файлом відліків SigMF у base64.

  Бібліотека отримує вимкнену за замовчуванням можливість bundled-scenarios, що надає таблицю еталонних сценаріїв як kshana::bundled_scenarios; лише сервер MCP вмикає її, тож колесо Python і модуль WebAssembly, як і раніше, не містять тексту сценаріїв. Набори досліджень (--study) лишаються лише в командному рядку, бо набір називає файли на диску, а сервер жодного не читає. Тести кругового проходу запускають кожен новий інструмент на вбудованих сценаріях і перевіряють числа рушія: спектр, Сонячна система, орбітальні угруповання навколо Місяця та Європи, перебір кампанії та види низької навколоземної орбіти (LEO): сигнал, прохід, навігаційне повідомлення, злите позиціонування, точне позиціонування окремої точки, нетеррестріальна мережа та наскрізний. Кожна поверхня, що вказує кількість інструментів MCP або перелічує інструменти, тепер каже «чотирнадцять», окрім сторінки playground у web/, яку замінено сайтом.

kshana.dev, Kshana Studio і README

• Перероблений kshana.dev. Єдину сторінку playground замінено багатосторінковим сайтом: Home, Missions, Capabilities, Evidence, Developers, Editions і Docs, а Kshana Studio — за один клік. Кожна діаграма, карта й число на ньому — це записаний прогін рушія цього випуску, зі сценарієм і посиланням, що знову відкриває той самий прогін у Studio; збірка сайту відхиляє запис, зроблений іншим комітом рушія. Сторінки документації генеруються з docs/ репозиторію, а варіанти встановлення — з його каналів. Шрифти та бібліотеки скриптів віддаються з самого kshana.dev, тож жодна сторінка нічого не запитує в стороннього хоста. Старі адреси (/#playground, /#ledger, посилання для поширення /#s=<scenario>, посилання для вбудовування /?embed=1&… та решта) переспрямовують на нове місце, а невідома адреса отримує сторінку 404.
• Kshana Studio, панель для кожної можливості. Studio відкривається на початковому екрані з плитками областей і добрими першими прогонами, а потім проводить прогін п'ятьма пронумерованими кроками: Choose a scenario, Set its parameters, Run the engine locally in the browser, Read the results (спершу ключові показники, кожен із позначкою PASS або FAIL, де прогін указує поріг, потім панелі) і Share or export. Одне поле пошуку знаходить сценарії, області та поля в них і переходить до елемента керування; прогони можна закріплювати й порівнювати; навігаційний ланцюжок каже, де ви; на телефоні кроки перетворюються на панель кроків. Кожен вид сценарію має своє подання, зокрема водоспад спектра, Сонячну систему, покриття орбітальних угруповань, кампанії, анімацію, звіт про прогін, експорти для сумісності та ланцюжок низької навколоземної орбіти. Глибоке посилання (?scenario=…&tab=…) відкриває той самий прогін на названій панелі.
• Дослідження та цитування. Сторінка Evidence перелічує п'ять статей Kshana на arXiv (2606,22054, 2606,24210, 2607,02566, 2607,05415 і 2607,06212), кожну зі зведенням, показником, обчисленим цим рушієм, командою, що його відтворює, посиланням на Studio та BibTeX, поряд із тим, як цитувати програмне забезпечення. README отримує той самий розділ Research.
• Публічна сторінка для Kshana Pro. docs/PRO.md і сторінка Editions сайту повідомляють, що додає власницьке накладення Pro до того самого рушія (оптимізатор конструкції, невизначеність і чутливість, досьє місії, спостереження за кампанією, співіснування спектра, локальна служба завдань, простежуваність вимог), що кожен із них видає і чого не робить. Кожен показник Pro, який показує сайт, викладено на цій публічній сторінці. Pro не додає жодної фізичної моделі, а відкритий рушій лишається цілісним і безкоштовним.
• Переписаний README. Короткі розділи, одне зображення на розділ, знак Kshana, два ряди бейджів, згенеровані зображення архітектури, потоку сценаріїв, ланцюжка низької навколоземної орбіти та верифікації (tools/gen_readme_assets.py, що падає на застарілому зображенні) і знімки екрана Studio, зроблені із запущеного Studio за допомогою tools/capture_studio_shots.mjs. README для crates.io, PyPI, npm і сервера MCP дотримуються того самого оформлення. Довгі довідкові матеріали згорнуто або перенесено до docs/.

Змінено#

• <scenario>.report.html тепер є розширеним звітом про прогін, описаним у розділі «Додано», а рядок wrote … у CLI називає також <scenario>.report.json. Односторінкову картку оцінок, яку він замінив, не змінено, вона лишається як RunOutput::html_report(), і прив'язки Python і WebAssembly і далі повертають саме її. OracleKind::modelled_reason() надає речення, яке docs/MODELLED-RATIONALE.md друкує для кожного рядка MODELLED; цей документ не змінено.
• README пояснює, на чому будується Kshana Pro. Розділ «Видання» та рядок про Kshana Pro в розділі «Підтримка та професійні послуги» тепер викладають, що робить інструментарій Pro для системної інженерії на основі моделей (MBSE) і програмного керування, які з опублікованих виводів відкритого рушія він зчитує (result.json і report.json кожного прогону, файл сценарію, схема польових одиниць і мітки матриці верифікації), а також на чому в відкритому рушії ґрунтуються цифрові двійники годинників, торгові дослідження та пакети доказів. Лише формулювання: жоден вивід рушія і жодне опубліковане число не змінюються.
• Сумісність. Публічне перерахування navsignal::Modulation отримує варіант Mboc, що є несумісною зміною для виклику, який зіставляє його вичерпно. Стовпчики gcrs_r_m і gcrs_v_m_s різновиду ephemeris змінюються (див. «Зміни опублікованих чисел»). Прогін і далі відтворюється версією рушія, яка його створила.

Виправлено#

• export_table_csv на сервері MCP називав чотири різновиди як єдині, що мають таблицю CSV (значення, розділені комами); шість її публікують. Інструмент завжди повертав таблицю для telecom-timing і для leo-navmsg (його аналіз encode-decode на моделі повідомлення kepler16 або kepler-rac), але його опис, його повідомлення про відмову та документи, що перелічують різновиди, пропускали обидва, тож агентові казали не просити. Тепер їх названо, а тест повного циклу отримує обидві таблиці.

• Кадр навігаційного повідомлення для низької навколоземної орбіти (LEO) не мав однакових байтів на кожній платформі, ані в кожній збірці однієї платформи. scenarios/leo-navmsg-encode-decode.toml закодував кадр із циклічним контролем надлишковості 0x110315 у релізній збірці на aarch64 macOS, 0x898BD8 у налагоджувальній збірці того самого коду на тій самій машині та 0x6A82D9 у збірці WebAssembly (WASM); leo-navmsg-celeste-iod.toml дав 0x6EDB2D у рідному виконанні проти 0xC6E4F0 у браузері. Три причини, кожну простежено до першого значення, що розійшлося:

  • Між платформами. Істинна орбіта була побітово ідентичною на обох; початкова точка підгонки — ні. truth::state_to_elements бере оскулюючий нахил із acos, а аргумент перигею з atan2, і дві математичні бібліотеки округлюють їх по-різному в останньому розряді (на 20 000 аргументів вони розходяться для 781 синусів, 858 косинусів, 1 931 експонент і 1 899 двоаргументних арктангенсів).
  • Між профілями збірки. Оптимізована збірка на macOS зливає синус і косинус одного аргументу в один виклик комбінованої системної процедури, і її синус не збігається з окремим sin для 379 із 200 000 аргументів; неоптимізована збірка робить два виклики. Цей різновид бере синус і косинус разом у тринадцяти місцях.
  • У годиннику. Нормальний семплер rand_distr викликає exp і ln хоста у двох своїх рідкісних гілках: з чотирьох мільйонів зернових вибірок три відрізнялися в останньому біті між рідною та WASM-збіркою.

  Підгонка Левенберга–Марквардта, яка на цій дузі зупиняється на своєму ліміті у 80 ітерацій, а не в мінімумі, переносить одну одиницю в останньому розряді в різні квантовані поля. Різновид тепер обчислює кожну трансцендентну функцію через нову src/portable_math.rs, яка викликає крейт libm на чистому Rust (уже в дереві залежностей, тепер названий у Cargo.toml), зібраний з одного коду для кожної цілі, а не виклик бібліотеки, який оптимізатор переписує: leo_navmsg::{truth, fit, elements, codec, sisre, services} і код сценарію. Цілі степені на цьому шляху розписано як піднесення через квадрат і множення, бо f64::powi має невизначену точність, а істинний годинник бере свої нормальні відхилення з portable_math::standard_normal (полярний метод Марсальї на сирому виводі генератора). Спільні процедури, через які інтегрується істинна орбіта, написано один раз, узагальнено щодо математичної бібліотеки, з внутрішньокрейтною точкою входу _portable поряд з наявною: прискорення сферичних гармонік, зональні прискорення та прискорення опору, секулярні швидкості J2 і затримка Клобухара. Наявні точки входу не змінено до останнього біта, тож число жодного іншого різновиду не змінюється. leo_navmsg::tests::the_encoded_frame_is_the_same_bytes_on_every_platform фіксує весь кадр з 171 байта та по одному контрольному значенню на модель ефемерид у звичайному (неоптимізованому) профілі тестів, на кожній платформі й без перевірки базового хоста; the_kind_never_calls_the_host_mathematics_library зчитує джерела різновиду з диска і завершується невдачею на власному трансцендентному виклику, на семплері rand_distr або на виклику в модуль, який не переглянуто. Після зміни налагоджувальна збірка, релізна збірка та збірка WASM дають побайтово ідентичні документи результатів для всіх п'яти сценаріїв leo-navmsg. Це змінює числа, що тут записано як зміну. Різновид leo-navmsg у цьому випуску новий, тож нічого, опублікованого в попередньому випуску, не змінюється, але змінюється кожен показник leo-navmsg, у рідній збірці та в збірці WASM, і разом із ним етап navmsg у leo-pnt-chain: показники орбіти — бо підгонка тепер починається з портативних елементів, показники годинника — бо істинний годинник є іншою реалізацією того самого процесу. docs/LEO-NAVMSG.md згенеровано заново з нових результатів; його опубліковане контрольне значення для сценарію кодування й декодування було 0x110315, а тепер 0x19105F (положення в межах 1,126 мм від точного повідомлення, де було 0,665 мм, годинник у межах 0,185 мм, де було 0,451 мм). Розмір змін у субміліметрових показниках — це чутливість підгонки, а не помилка в жодному з наборів: підгонку не змінено, і вона й далі зупиняється на ліміті ітерацій.

• Зернова повторна вибірка отримувала різні індекси на 32-бітовій цілі. Rng::gen_range над usize бере 64 біти з генератора на 64-бітовому хості та 32 біти на 32-бітовому, тож те саме зерно давало інші індекси й залишало потік в іншому місці в збірці WASM. Так відбирали в трьох місцях: процентильні бутстрепи в eval_stats (bootstrap_ci, bootstrap_auc_ci), перемішування перед кожним проходом навчання в impairment_ml і перестановочний тест у impairment_study. Тепер вони відбирають через portable_math::uniform_index, який завжди вибирає як u64: точно те, що робив 64-бітовий хост, тож жодне рідне число не змінюється. Це змінює опубліковані числа пакета WASM, що тут записано як зміну: бутстреп-інтервал quantum-anomaly-detect для площі під кривою (quantum_auc_ci, trade.foms[0].ci95) у браузері був [0.9901265, 0.9938305], а тепер є рідним [0.99035875, 0.993861].

• Імена файлів ефемерид STK з ідентифікаторів рухомих об'єктів. Ідентифікатор рухомого об'єкта із символом / або пробілом (оболонка орбітального угруповання та супутник, Pulsar inclined/S1-0163) спричиняв паніку CLI на --export stk; тепер кожен ідентифікатор проходить через безпечну частину файлу (літери, цифри, -, _).

• Знак нутації TEME→GCRS, описаний вище в розділі «Зміни опублікованих чисел», бо він змінює опублікований вивід.

0.28.0 - 2026-09-26#

Додано#

• Різновид сценарію slot-timing (src/slot_timing.rs): секунди, поки вільно працюючий годинник виходить за захисний інтервал слота маршрутизації чи завдань, індексованого за часом, кожен внесок у цей момент із названим домінантним, залишок часу від останнього визначення та найбільший інтервал визначень, що тримає годинник у межах, за вирахуванням затримки визначення. Годинник береться з типового значення класу, пресету даташиту telecom-timing, вбудованого даташиту (максимуми девіації Аллана, старіння, температурний коефіцієнт) або виміряного запису фази. Вихід за найдовший час усереднення, який підтримує джерело, позначається як екстрапольований. Вбудований приклад: slot-timing-ocxo-leo. Див. docs/SLOT-TIMING.md.
• Виміряна підлога червоного шуму. Перекривна девіація Аллана запису фази підганяється зваженим методом найменших квадратів у базисі білої фази та частотної модуляції за IEEE Std 1139 (slot_timing::fit_weighted), кожна точка зважена за своїми еквівалентними ступенями свободи, тож відповідь щодо holdover може спиратися на власну підлогу годинника, а не на припущення класу. Незважена підгонка накладала хибну флікерну підлогу на тестовий запис із білим шумом і скорочувала вихід за межі на 2 000 с на 30 %.
• Валідація інверсії holdover на реальному годиннику на відкладених даних (tests/slot_timing_cs5071a_holdout.rs): підігнані за першою третиною запису цезію 5071A проти водневого мазера, передбачені виходи за межі на один сигма на шести порогах від 0,5 до 2,5 нс потрапляють у межі від 0,84 до 1,03 від виходів, виміряних на двох інших третинах, проти порогу 1,5, зафіксованого до першого запуску тесту. Контроль (односекундна девіація Аллана, прочитана як білий шум) помиляється приблизно в 1 000 разів і не досягає порогу. Новий рядок реєстру VALIDATED; робочий процес realdata-clock тепер його запускає.
• Той самий прогноз на реальному кварцовому генераторі (tests/slot_timing_ocxo_holdout.rs, scripts/fetch_ocxo.sh): на виміряному кварцовому генераторі з термостатом прогноз на відкладених даних є консервативним, на рівні від 0,59 до 0,70 виміряного виходу за межі та ніколи не пізніше, а здебільшого поза порогом 1,5, бо шумова підлога цього генератора зменшилася вдвічі протягом 5.5-годинного запису; підігнаний у вибірці, він потрапляє в межі від 0,98 до 1,17. Випадок кварцу не перевірено за незалежним зовнішнім еталоном, і він лишається MODELLED. Прогін також виявив відсутній член: частота кварцу блукає, тож модель тепер несе невизначеність частоти, відомої на момент визначення (fix_frequency_sigma); без неї прогноз був оптимістичним до 2,5×.
• Той самий прогноз на атомних годинниках на орбіті (tests/slot_timing_igs_holdout.rs, scripts/fetch_igs_clocks.sh): 14 діб фінальних годинників Міжнародної служби ГНСС (GNSS) для супутників GPS Block IIF, з протоколом, записаним до завантаження даних. Вісім із десяти супутників потрапляють у межі порогу 1,5; G25 і G30 прогнозують виходи за межі до приблизно вдвічі пізніше за виміряні. Протокол вимагає, щоб проходив кожен супутник, тож орбітальний випадок не перевірено за незалежним зовнішнім еталоном, і він лишається MODELLED; результат зафіксовано.
• Класи годинників: кварцовий з температурною компенсацією (TCXO), кварцовий з термостатом (OCXO) і рубідієвий атомний еталон частоти (RAFS) (ClockClass::Tcxo, Ocxo, Rafs), деталі, які літають на комерційній шині малого супутника або наземному шлюзі, кожна з посиланням на один публічний даташит (ClockClass::source). Додано ClockClass::ALL, id і from_id. baseline_clock_class в quantum-trade приймає три нові ідентифікатори. Додавання варіантів до публічного перерахування є несумісною зміною для виклику, який зіставляє його вичерпно.
• Рівень захисту часу для приймача на орбіті (src/orbital_timing.rs, додатковий розділ spoofing різновиду slot-timing): як довго наземний спуфер може досягати супутника на низькій навколоземній орбіті за прохід, відведення, яке накопичує спуфер із заявленою максимальною швидкістю наростання, поки супутник виходить із його зони досяжності або виконується незалежна перевірка, і чи є кожна перевірка під час наземного контакту або міжсупутникового зв'язку незалежною від цього спуфера. Точно зводиться до tpl::timing_protection_level_ns для годинника без флікерного, білофазового чи випадково-блукального шуму. MODELLED.
• Три примітки: docs/SLOT-TIMING.md (включно з тим, за якою метрикою блукання слот слід приймати: за максимальною абсолютною похибкою часу, а не за максимальною похибкою часового інтервалу чи часовим відхиленням, і чому), docs/DECEIVED-TIME.md (підписана команда, застосована в обманутий час, усе одно хибно маршрутизує) і docs/DEPLOYMENT-TARGETS.md (де працює Kshana; льотне ядро no_std не пропонується).

0.27.4 - 2026-09-26#

Випуск v0.27.3 досяг crates.io (kshana і kshana-mcp) та PyPI, а потім зупинився на npm, тож npm, образ MCP на ghcr.io, реєстр MCP, JetBrains Marketplace і kshana.dev його так і не отримали. 0.27.4 несе той самий рушій із наведеним нижче виправленням випуску до кожного каналу.

Виправлено#

• Крок публікації npm називає тарбол явним шляхом. npm зчитує голе npm-dist/kshana-0.27.3.tgz як скорочення GitHub owner/repo, тож завдання npm випуску v0.27.3 спробувало клонувати github.com/npm-dist/kshana-0.27.3.tgz і завершилося помилкою «Permission denied (publickey)». Сам тарбол було зібрано й засвідчено. Тепер крок публікує ./npm-dist/*.tgz. Усе після npm у порядку випуску (образ MCP, додаток JetBrains, перевірка паритету каналів і сайт) було пропущено, як і задумано.

Змінено#

• Каталоги одиниць telecom-timing і gnss-ins виключено з виявлення копіювання й вставлення за тією самою політикою та перевіркою обґрунтування, що й інші каталоги. Контроль якості SonarCloud став червоним через дублювання в новому коді (4,0% проти 3%), і кожен продубльований блок був рядком одиниць або записом маски ITU-T.

0.27.3 - 2026-09-25#

Додано#

• scenarios/small-uas-jammed-nav.toml: як довго тримається навігація малого дрона після глушіння ГНСС (GNSS). Вона запускає інерціальний блок класу польотного контролера на мікроелектромеханічних системах (MEMS), Bosch BMI088, проти блока тактичного класу. Сигнал ГНСС (Глобальна навігаційна супутникова система) є номінальним протягом 100 с, а потім заблокований протягом 60 с (jamming-demo.toml показує, чому так робить близький глушник). Зміщення BMI088 є залишками після калібрування під час запуску, узятими з температурних коефіцієнтів у його даташиті (BST-BMI088-DS000-19 rev 1,9): 0,015 °/с на K для гіроскопа та < 0,2 µg на K для акселерометра. У файлі позначено два припущення: прогрів на 10 K після калібрування та подальше нагрівання на 1 K за хвилину в польоті. Дрейф у польоті є похибкою, яку фільтр не може вивчити до початку глушіння, і саме вона завершує інерційний політ. Кожен показник змодельовано; щоб це перевірити за незалежним зовнішнім еталоном, потрібні польотні журнали із середовища з глушінням. kshana example small-uas-jammed-nav друкує це.

• Кожен датчик gnss-ins може задати власне апріорне значення фільтра ([imu_quantum.filter_prior] або [imu_classical.filter_prior], з sigma_accel_bias і sigma_gyro_bias). Типове значення не змінено, тож кожен наявний сценарій дає той самий результат. Залишкове зміщення гіроскопа блока споживчого класу лежить приблизно на 26 сигма поза типовим значенням тактичного класу, де фільтр ніколи б його не вивчив. Апріорне значення, яке не є скінченним і додатним, відхиляється, а результат повторює апріорне значення, коли його задано.

• kshana example [<name>] дає користувачеві реєстру сценарій для запуску. Користувач cargo install kshana має виконуваний файл і не має каталогу scenarios/, тож перша команда кожного швидкого старту в нього не спрацьовувала. Інтерфейс командного рядка (CLI) тепер містить 75 еталонних сценаріїв, що запускаються самостійно, байт у байт, скомпільованих із scenarios/ (src/bundled_scenarios.rs; таблиця міститься в бінарному файлі CLI, тож колесо Python і модуль WebAssembly не збільшуються). kshana example перелічує їх; kshana example clock-holdover > clock-holdover.toml записує один. Два інші файли є лише в репозиторії: lunar-llr-datum зчитує архівні дані місячної лазерної локації, що постачаються лише з репозиторієм, а quantum-pnt-demonstrator.suite є маніфестом дослідження, який запускає три сусідні файли за допомогою --study. Запит будь-якого з них пояснює причину і завершується кодом 2, а не друкує те, що не може запуститися самостійно. tests/cli_first_run.rs тримає таблицю у відповідності з каталогом в обидва боки, тож новий файл сценарію, який не вбудовано й не названо лише-репозиторним, завершується невдачею.

• Кожен показник якості в результаті для годинника, орбіти, hybrid або fusion тепер повідомляє, чи є він VALIDATED, чи MODELLED, у самому результаті. Документ результату отримує блок figure_tiers, завжди його останній ключ. Він перелічує кожен повідомлений показник (наприклад, quantum.fom.timing_p95_ns) з його рівнем — VALIDATED означає перевірено за незалежним зовнішнім оракулом, MODELLED означає модель із перших принципів, яку перевірено внутрішньо — і рядок матриці верифікації, з якого прочитано рівень. Рівень береться з src/verification.rs через src/fom_label.rs, тож немає другої таблиці, що могла б розійтися. До цього слова «перевірено за зовнішнім еталоном» і «обчислено за моделлю» з'являлися в результаті holdover годинника нуль разів, і читач сирого JSON (JavaScript Object Notation) не мав способу розрізнити їх. Показники положення hybrid і fusion не мають матричного рядка-власника, тож їх перелічено під untiered, а не наділено рівнем. Блок не містить чисел. Доведено, що він адитивний, а не припущено: його вилучення повертає документ до змін байт у байт для всіх п'яти різновидів (тест рушія), а обидва еталонні набори (tests/registry_golden.rs, tests/cross_platform_golden.rs) тепер відкидають саме цей ключ і лише тоді, коли він останній, а потім хешують решту за своїми незміненими замороженими константами. Перелік у кожному наборі фіксує, які сценарії мусять містити блок, тож виняток не може непомітно розширитися.

• Різновид telecom-timing відповідає в одиницях інженера синхронізації: похибка часу, максимальна похибка часового інтервалу (MTIE) і часове відхилення (TDEV), кожне з PASS або FAIL і запасом щодо масок Сектора стандартизації електрозв'язку Міжнародного союзу електрозв'язку (ITU-T). Маски переписано з редакцій, що діють: G.8272 (07/2025) для класів A і B первинного еталонного годинника часу (PRTC), G.8272.1 (2024) Amd. 1 (07/2025) для розширеного PRTC у заблокованому режимі та в holdover (включно з обвідною його похибки часу, що зростає від 30 нс до 100 нс за період holdover, заданий тим, як довго годинник був заблокований), G.8273.2 (2023) Amd. 2 (11/2025) для граничних і підлеглих годинників часу телекомунікацій, класи від A до D, та G.8271.1 (2022) Amd. 3 (05/2025) для мережевих меж у еталонній точці C. Кожен запис, який ці Рекомендації залишають «для подальшого вивчення», відсутній, а не оцінений, і docs/TELECOM-TIMING.md перелічує кожне число з його таблицею чи пунктом та кожен пропущений елемент. Звіт також дає час до перевищення кожного бюджету похибки часу: типово 100 нс — типове значення holdover для ePRTC, 400 нс — мережеве виділення для holdover, 1 100 нс — межа в точці C і 1,5 мікросекунди — наскрізна вимога класу 4.

  Вхідними даними є або синтетичний holdover, або ваш власний ряд. Синтетичний використовує один із чотирьох пресетів генератора (кварцовий генератор із термостатом, рубідієвий еталон, цезієвий еталон і чіпових розмірів атомний годинник), кожен з показниками стабільності, старіння й температури з іменного даташиту Microchip. Те, як ці показники стають білим, флікерним шумом і шумом випадкового блукання частоти, старінням і температурним членом, зазначено в кожному звіті й позначено MODELLED. Ваш власний ряд — це пари [time_s, time_error_ns], вбудовані (так він працює в браузері) або, у рідних збірках, з файлу зі значеннями, розділеними комами. Таблиця MTIE/TDEV із межею кожної вибраної маски поряд записується як артефакт CSV прогону.

  scenarios/telecom-prtc-holdover-24h.toml є 24-годинним holdover рубідія зі старінням, флікером і добовим температурним циклом: його найбільша похибка часу становить 603,2 нс, він перетинає 100 нс через 8 206 с після втрати й увесь день лишається в межах 1,5 мікросекунди, і він не проходить обвідну holdover розширеного PRTC, як і має бути для годинника, що не належить до класу цезію. scenarios/telecom-tie-ingest.toml показує вбудований вхід. MTIE і TDEV, що їх повідомляє різновид, перевірено за пакетом allantools на закоміченому ряді holdover з 2 048 відліків, точно для MTIE і до 1.1e-15 для TDEV, тож матриця отримує один рядок VALIDATED і два MODELLED (транскрипція масок і пресети) і тепер налічує 171 рядок — 65 VALIDATED, 102 MODELLED, 4 PARTNER. Охоплення польовими одиницями зростає з 60 із 61 різновидів до 61 із 62 і з 1 742 до 1 788 описаних полів. Різновид новий і адитивний: жоден наявний сценарій, закріплення чи опублікований показник не змінюється.

• Майданчик запускає рушій у фоновому Web Worker, тож повільний сценарій більше не заморожує сторінку. web/engine-worker.mjs розміщує рушій WebAssembly, а web/engine.mjs передає йому кожне виконання сценарію — прогони, перебори параметрів і експорти SP3 / OMM / OEM / CSV. Прогін, що триває довше за 150 мс, показує стан зайнятості (Run вимкнено, «Running… N s») і кнопку Cancel, яка завершує та знову запускає воркер; браузер, який не може запустити модульний воркер, повертається до старого шляху в головному потоці. cislunar-arc-recovery, виключений з каталогу, бо заморожував сторінку, повернувся до нього з позначкою «повільний»: він займає близько 13 с у Chrome (чотири виклики рушія приблизно по 3 с кожен), протягом яких сторінка лишається чуйною.

• Кожна повідомлювана величина cislunar-observability тепер має одиницю, клас походження та означення — це другий з кінця різновид у загальнокрейтному списку винятків. Усі 41 числових полів документа RELEASED описано, тож охоплення польовими одиницями зростає з 59 із 61 різновидів до 60 із 61 і з 1 698 до 1 742 описаних полів, а черга без означень лишається незмінною на 239.

  Цьому заважало закріплення, що заморожує випущений документ, яке називало units ключем, якого документ ніколи не повинен отримати. Додавання означало б видалення цього твердження та перезаписування базових рівнів трьох хешів у трьох файлах — форма, яку не відрізнити від приховування регресії. Натомість два закріплення, що вимірюють цей документ, тепер доводять, що додавання адитивне: кожне знову відкидає блок units і хешує заново проти константи, зафіксованої до появи блока, і обидві константи не змінено. Мутація підтверджує, що гарантія справжня: змініть випущене значення й перезапишіть базовий хеш усього документа так, як зробило б недбале виправлення, і відкидання з повторним хешуванням усе одно завершиться невдачею. Третє закріплення в загальному наборі реєстрових еталонів перезаписано разом із шістьма сусідніми, які перезаписували саме з цієї причини, а його літерал expect_summary, що несе значення, не змінюється.

• realtime-frame-eop повідомляє, за якою істиною оцінювався кожен рядок орієнтації Землі та як часто спрацьовував запасний варіант. table3_joint_eop[].{ut1, polar_motion,combined} отримують truth_source і truth_fallback_rows. Підлога final оцінюється за фінальним Bulletin B і може використовувати лише епохи, що його публікують; кожен рядок dN оцінюється за truth_pm()/truth_ut1(), які повертаються до швидкого значення Bulletin A. На вбудованому витягу за 2026 рік це 12 із 31 відліків на одну добу, проти 0 на підлозі — тож рядок підлоги та рядки прогнозу поряд із ним спираються на помітно різну істину, що тепер зазначає звіт, а не залишає виводити з кількості відліків, яка зростає там, де вкладені горизонти кажуть, що не може.

• moonlight-service-volume видає кеплерову базову лінію того самого розміру. ephemeris_comparison.keplerian_matched повторно запускає ілюстративне орбітальне угруповання на власній кількості супутників ОТРИМАНОГО набору, лише коли кількості відрізняються. Кількість є частиною геометрії цього проєкту — RAAN і середня аномалія розподілені як 360k/n — тож без неї п'ятисупутниковий отриманий набір оцінювався проти восьмисупутникового ілюстративного, і проєкт змішувався з розміром. Для п'ятисупутникового еталонного набору LANS 8,68 із 14.24-пунктного розриву покриття виявляється трьома відсутніми супутниками і лише 5,56 пункту — проєктом; для чотирьох космічних апаратів, що справді перебувають на місячній орбіті, спеціально побудований чотирисупутниковий набір досягає 4,86 % там, де вони досягають 0 %. Тест фіксує, що зіставлений рядок є перебудованим угрупованням, а не налаштованим, перейменованим, — саме так його було спершу написано й саме це прогін тоді повідомляв.

• Дев'ять карток можливостей на публічному сайті, що охоплюють 22 рядки матриці верифікації, які постачалися без картки на рівні продукту. Рушій розрісся до родини можливостей — перевірка ARAIM за опублікованими еталонними векторами Working Group C, реальна отримана геометрія місячного орбітального угруповання, місячний контур відмови з виміряною смугою C/N₀, крок від розкладу VLBI до коваріації станцій, оптичне та RF-передавання з міжмодальним введенням збоїв, прогноз орієнтації Землі в реальному часі за архівним Bulletin A, спільне використання апертури навігацією та зв'язком, інерційний політ INS/TRN і охоплення одиницями та походженням — кожна з рядком матриці та вбудованим сценарієм, і жодну не названо на kshana.dev. Охоплення рядків картками зростає з 72 із 168 рядків до 94.

• Вісім сценаріїв додано до каталогу пісочниці. Кнопка запуску на картці можливості з'являється лише тоді, коли файл також є в web/app.js; шість карток називали сценарій, якого там не було, тому вони відображалися без можливості запуску, а одна з них, картка еталона реального лазерного далекомірного вимірювання, перебувала в такому стані з моменту появи. Тепер tests/scenario_examples_doc_sync.rs контролює цю інваріанту в обох частинах: цільовий сценарій run картки має бути вбудований у scenarios/ і запропонований каталогом. Перевірено мутаційним тестуванням для обох видів відмови.

• moonlight-service-volume видає геометрію для кожного супутника як <scenario>.table.csv, коли налаштовано місце експорту (G11). Це найбільший масив, який публікує крейт: 2304 рядків в опублікованій спільній таблиці зв'язку та навігації; і до споживачів він доходив лише всередині JSON, у форматі, який скоротив 57-точкову криву суміжного сценарію до 23 точок під стовпцем, що стверджував, ніби містить усі. Один рядок на лінію зв'язку, кількість рядків на рядку заголовка, стовпці антени лише тоді, коли антену налаштовано. Прогін без місця експорту не змінюється ні на байт і не записує файл.

• SBOM тепер описує те, що постачається: 60 компонентів стало 66. scripts/gen-sbom.sh перелічував кожен пакет розв'язання із типовими функціями, зокрема dev-залежності. Через це в специфікацію матеріалів потрапили sgp4 і chrono, крейти лише для тестів, що не входять до жодного артефакту, а ланцюг --features python, який лінкує колесо PyPI (pyo3, pyo3-ffi, pyo3-macros, pyo3-macros-backend, pyo3-build-config, portable-atomic, target-lexicon, heck) і який є межею зовнішніх функцій цього колеса, випав. Тепер скрипт обходить граф розв'язання від пакета kshana лише за звичайними та збірковими ребрами, на об'єднанні наборів функцій за замовчуванням, python і wasm (пакет npm містить цей самий SBOM), для кожної цільової платформи. Закріплений вердикт відповідності CycloneDX повторно базується через його зафіксований генератор: 60 → 66 компонентів, 53 → 60 складених виразів ліцензій і, як і раніше, нуль помилок схеми після того, як їх подано в стандартній формі expression.

• Таблиця відтворюваності CSV досягає кожного входу, а не лише CLI та колеса Python. Сервер MCP отримує сьомий інструмент, export_table_csv, який запускає сценарій і повертає побайтово стабільну таблицю, яку CLI записує як <scenario>.table.csv, або помилку з переліком видів, що її публікують (realtime-frame-eop, lunar-time-budget, lunar-jamming і moonlight-service-volume лише тоді, коли задано export_site_lat_deg + export_site_lon_deg). Модуль WebAssembly отримує table_csv, що повертає той самий текст або undefined. Тест повного обміну MCP і тести прив'язок Python тепер закріплюють повернений CSV побайтово за tests/golden/realtime-frame-eop.csv, а також закріплюють, що RunOutput.write_csv повертає кількість записаних байтів і 0 без створення файлу для виду без таблиці. Кожна поверхня, що вказує кількість інструментів MCP або перелічує їх, тепер називає сім.

• run_all у модулі WebAssembly: один прогін рушія для всіх виходів. run, chart_svg, summary і table_csv виконують сценарій щоразу з нуля, тож пісочниця за кожен клік платила за чотири повні прогони: близько 12 с замість 3 с для cislunar-arc-recovery у браузері. run_all повертає {json, svg, summary, csv} з одного прогону, і пісочниця тепер його використовує. Результат збігається з чотирма окремими викликами байт у байт.

Виправлено#

• ВИПРАВЛЕННЯ: зв'язок зміщення гіроскопа у фільтрі GNSS/INS мав хибний знак, тому змінюються показники похибки під час перерви в сигналі для gnss-ins. Розширений фільтр Калмана зі станом похибок (EKF) тримає обидва інерціальні зміщення як залишки (істинне значення мінус поточна оцінка, що вводиться зворотним зв'язком додаванням). Стовпець акселерометра керував похибкою швидкості через +C_b^n b_a, але стовпець гіроскопа керував похибкою орієнтації через −C_b^n b_g. Залишкове зміщення гіроскопа насправді повертає обчислену орієнтацію на +C_b^n b_g, тож кожна оцінка зміщення гіроскопа штовхала у хибний бік. Пакет залишався стабільним лише тому, що його типове апріорне значення зміщення гіроскопа (1e-4 рад/с, 1-сигма) було достатньо вузьким, щоб утримувати ці стани нерухомими. За ширшого апріорного значення фільтр розходився, навіть коли справжнє зміщення гіроскопа дорівнювало нулю: 93 м похибки об'єднаного розв'язку під час перерви стали 4,3 км. Опубліковані показники для scenarios/gnss-ins.toml змінюються так:

  gnss-ins.toml	до (≤ 0.27.2)	після
  холодноатомний IMU, середньоквадратична похибка об'єднаного розв'язку під час перерви	96,1 м	1,9 м
  холодноатомний IMU, інерціальний хід у межах специфікації (50 м)	30 с	60 с (вся перерва)
  тактичний IMU, середньоквадратична похибка об'єднаного розв'язку під час перерви	62,5 м	3,1 м
  тактичний IMU, інерціальний хід у межах специфікації (50 м)	37 с	60 с (вся перерва)

  Показники вільного ходу (130,7 м і 314,3 м) не змінюються; вони ніколи не використовували фільтр. Попереднє твердження пакета, що об'єднаний інерціальний хід обмежений нижньою межею орієнтації під час передавання і тому не покращується з кращим датчиком, було артефактом цієї помилки і відкликається. За сталих безшумних зміщень фільтр тепер вивчає їх, поки GNSS доступний, тож об'єднаний інерціальний хід є найкращим випадком. Зовнішній еталон filterpy (tests/gnss_ins_sensor_fusion_reference.rs) перевіряє лише оновлення за вимірами, через що він ніколи не бачив поширення. Два тести тепер перевіряють знак безпосередньо, і обидва не проходять на старому знаку. Перший, у closed_loop.rs, подає відоме залишкове зміщення гіроскопа через стрепдаун і вимагає, щоб фільтр передбачив результуючу похибку орієнтації з точністю до 2 %. Другий вимагає, щоб широке апріорне значення вивчило зміщення гіроскопа 1e-3 рад/с і трималося в межах 6 м. Крос-платформений еталонний знімок gnss-ins перезакріплено з цієї причини і жодної іншої.

• Кожен швидкий старт із реєстру тепер працює як написано на чистій машині. Виміряно до цієї зміни: приклади crates.io і PyPI (Python Package Index) зчитували scenarios/clock-holdover.toml, якого в установленому з реєстру пакеті немає, а приклад npm аварійно завершувався під Node.js з TypeError: fetch failed, бо init() пакета отримує свій двійковий файл WebAssembly, а fetch у Node не може читати локальний файл. Тепер:

  • README.crates.md і README.pypi.md містять цей сценарій вбудованим, як це вже робив README.npm.md. Блок Rust тепер є цілою програмою зі своєю main, бо прихований для rustdoc рядок # Ok::<…>, яким він закінчувався, показується на crates.io і не компілюється після вставлення. tests/readme_code_fences_doc_sync.rs і далі компілює його побайтово, а тепер ще й відхиляє прихований рядок у блоці.
  • README.npm.md розділяє браузер і Node.js та дає рецепт для Node, що читає двійковий файл із диска й передає його до initSync. Тест синхронізації документації приймає initSync як завантажувач, який генерує wasm-bindgen.
  • Усі три вбудовують сценарій з нескороченими рядками походження, тож хеш сценарію є 5ba83a232b94 на кожній поверхні. Приклад npm раніше їх скорочував, через що його хеш відрізнявся від хеша CLI.
  • Відтворено з локальних збірок цього дерева: свіжий проєкт cargo new із залежністю за шляхом від спакованого крейта зібрав і запустив приклад Rust; колесо, зібране maturin зі спакованих джерел і встановлене в нове віртуальне середовище, запустило приклад Python; а пакет wasm-pack --target web, запакований і встановлений через npm, запустив рецепт Node. Усі три надрукували той самий підсумковий рядок.

• cargo run -- <scenario.toml> працює з клону. Cargo.toml задає default-run = "kshana". Без цього cargo відмовлявся з повідомленням «could not determine which binary to run», на яке натрапляв кожен рядок cargo run -- у документації.

• Помилки CLI в першу хвилину підказують, що робити далі. Шлях до сценарію, якого не існує, тепер додає підказку, що вказує на kshana example, а другий позиційний аргумент друкує текст користування, а також називає аргумент. --help, --version, помилка невідомого параметра (вихід 2) і однорядкове ok: від --validate у разі успіху вже були в main. tests/cli_first_run.rs тепер охоплює їх усі, оскільки раніше жоден тест не запускав двійковий файл для жодного з них.

• list_kinds() у Python задокументовано як таку, що повертає один рядок JSON, а не список. Вона повертає ті самі метадані, що й scenario_kinds(), серіалізовані, тож ітерація проходить по символах. Вона зберігає рядкове повернення, щоб не ламати наявних викликачів. kshana.pyi, документаційний коментар прив'язки, docs/PYTHON_API.md і README.pypi.md тепер це зазначають і вказують на scenario_kinds().

• Три README реєстрів розшифровують кожну абревіатуру при першому вживанні. PNT тепер розгорнуто в слогані, де воно з'являється вперше, а CLI, TOML, JSON, SVG, CSV, CSAC, HTML, URL і API розгорнуто у файлах, що їх використовують. Заголовок таблиці оракулів більше не говорить «CI-gated» до того, як визначено CI.

• Виправлено опублікований показник: доступність ARAIM для двох орбітальних угруповань на вбудованих TLE Celestrak GPS + Galileo. docs/CAPABILITY.md стверджував, що додавання Galileo піднімає доступність з 0,21 до 0,67 за VAL 12 м і що режим, стійкий до відмови орбітального угруповання, обмежений за наявності лише двох угруповань. Це випливало з того, що tests/araim_dual_real_data.rs поширював кожен супутник від його власної епохи TLE (parse_propagators відкидає епоху), а епохи в цих файлах охоплюють 70,6 год (GPS) і 335,7 год (Galileo), тож супутники опинялися в узаємно неузгоджені моменти часу. Тепер тест зберігає кожну епоху (parse_tle) і обчислює кожен супутник в один спільний момент UTC, найпізнішу епоху TLE в наборі (2026-06-07T07:21:04). Виміряна доступність на тій самій сітці з 24 год і 289 відліків стає: лише GPS 0,993 (було 0,208), об'єднана 1,000 (було 0,671) і подвійна, стійка до відмови угруповання, 0,990 (було 0,031); за межі APV-I подвійний режим переходить з 0,180 до 1,000. Висновок обертається: на узгодженому небі два угруповання підтримують гіпотезу відмови угруповання за VAL 12 м. Ті самі показники виходять і з найранішою епохою TLE як опорною. Самоперевірка в тесті прив'язує його цикл доступності відлік у відлік до araim_dual_constellation_availability, тож єдина відмінність полягає у вирівнюванні за часом. docs/CAPABILITY.md і docs/REAL_TLE_GUIDE.md §3 містять нові числа; запис 0.13.0 нижче залишено таким, яким він був випущений.

• Публічні поверхні більше не рекламують RINEX 4 як перевірений. Рушій тепер відмовляється від навігаційного файла RINEX 4 за назвою, а не розбирає його хибно, але сітка стандартів досі показувала картку «RINEX 3 / 4» із позначкою перевірено за зовнішнім еталоном, прив'язаною до доказів RINEX-3 навігаційного розбирача. Тепер картка називається «RINEX 3», а README, docs/CAPABILITY.md, docs/STANDARDS.md, ROADMAP.md і підсумок можливостей викладають, як є насправді: файли спостережень RINEX 3.0x розбираються, очікується, що розкладка спостережень 4,00 теж, але жоден файл 4,00 крізь код не читався, а навігаційні файли RINEX 4 відхиляються.

• --validate повідомляє, коли «ok» означає, що перевіряти було нічого. Приблизно дві третини каталогу не публікують жодного обов'язкового поля: ці пакети запускають свою еталонну конфігурацію з порожнього тіла, тож лінтер міг лише друкувати «ok», тими самими словами, що й після перевірки шести полів. Рядок успіху тепер вказує кількість знайдених наявними обов'язкових полів або те, що вид не вимагає жодного.

• scripts/gate.sh відхиляє нечислове значення REPEAT або TEST_THREADS. У bash 3,2 REPEAT=no змушувало числове порівняння видавати помилку й оцінюватися як хибне, тож шлюз оголошував «repeatability loop SKIPPED (REPEAT=0)» для значення, що не було 0, і все одно записував квитанцію. Обидва параметри тепер завершуються з кодом 2, якщо не є звичайними цілими числами.

• MSRV указано як 1,85 скрізь, де його читає людина. Cargo.toml перейшов на 1,85 в останньому випуску; значок у README, текст встановлення й усунення несправностей, codemeta.json і власне обґрунтування крейта MCP досі говорили 1,75.

• RunOutput.__repr__ у прив'язці Python повідомляє байти, а не «chars». Вона друкувала len() рядків UTF-8, що є кількістю байтів: 710 «chars» для таблиці з 708 символів.

• README більше не документує --study --study-name разом. --study-name є прапором для одного сценарію і ігнорується разом із --study (двійковий файл попереджає). Два приклади для копіювання в README.md і README.crates.md тепер показують лише команду дослідження.

• Докази стабільності годинника на сайті називають обидва спостережені допуски. Серію цезієвого 5071A відтворено до ≤ 3e-5, а PHASE.DAT до ≤ 5e-5; абзац давав 3e-5 для обох.

• Два файли виходу рушія більше не відстежуються. scenarios/quantum-pnt-demonstrator.study.{json,html} було позначено рушієм 0.20.0 з порожніми всіма показниками якості, а власна команда дослідження з README перезаписувала їх, забруднюючи дерево й блокуючи шлюз надсилання. *.study.json / *.study.html тепер ігноруються, як і інші чотири виходи рушія.

• Перебір seed у пісочниці більше не завершується помилкою в кожному прогоні. Перебір проходив цілочисельний параметр seed лінійно (1, 10,9, 20,8, …), а рушій, читаючи його як u64, відхиляв кожне дробове значення. Цілочисельні параметри тепер перебирають різні цілі числа.

• Кожне завантаження з пісочниці вказує, який рушій і який вхід його створили. Деякі види (наприклад, realtime-frame-eop) не видають engine_version або scenario_hash, тож їхні завантаження називалися просто kshana-csv.csv. Тепер назва переходить до версії завантаженого рушія і 12-шістнадцяткового відбитка FNV-1a-64 тексту сценарію.

Змінено#

• Опублікований крейт менший за колишній розмір більш ніж удвічі, а cargo install kshana збирає лише CLI. Пакет раніше включав статті, їхні пакети подання, артефакти рисунків статей, зошити, docs/, скрипти супровідників і приклади програм. Жодне з цього не компілюється бібліотекою чи CLI. Він також включав три внутрішні генератори в src/bin/ (crossover_study, gen_validation_artifacts, validation_report), тож встановлення з реєстру компілювало й встановлювало чотири виконувані файли, три з яких корисні лише всередині checkout. Ці дерева й три джерела генераторів тепер виключено. Cargo складає перелік двійкових файлів пакета з файлів, які той містить, тому опублікований маніфест називає лише kshana. У клоні генератори, як і раніше, знаходяться автоматично, тож cargo run --bin <name> і завдання випуску, що запускає validation_report, не змінилися. Виміряно за допомогою cargo package: до — 763 файлів, 16,7 МіБ, 6,8 МіБ стисненого; після — 591 файл, 10,5 МіБ, 3,0 МіБ стисненого. Його збірка перевірки, що компілює лише запаковані файли, проходить. cargo install --path для запакованого крейта встановив один виконуваний файл, kshana.

• Вивід, який може прочитати інженер із синхронізації часу: більше жодного p95 0.0ns, жодного security 0.000 без атаки, а кількості на сайті збігаються з README. Це зміна відображення. Жодне опубліковане число не змінюється; значення JSON ідентичні, що доводять еталонні хеші вище.

  • Однорядковий підсумок друкував 95-й процентиль (p95) похибки часу оптичного годинника як 0.0ns, тоді як таблиця поруч показувала 1.20e-4 нс. Ненульовий показник часу, надто малий для одного десяткового знака, тепер друкується з трьома значущими цифрами (p95 1.20e-4ns); точний нуль, як і раніше, друкується як 0.0. Звіт HTML (HyperText Markup Language), порівняльна таблиця дослідження і звіт для завантаження в пісочниці використовують те саме правило, тож жоден ненульовий показник не друкується і як 0.000.
  • security є аналітичною межею виявлюваності спуфінгу, яка щось означає лише щодо налаштованої атаки. Види clock, orbit, hybrid і fusion не налаштовують жодної, тож їхній підсумок тепер друкує security n/a (no attack) замість числа на кшталт 0.000, яке читається як невдале виявлення. Значення залишається в fom.security, позначене applicable: false з причиною в figure_tiers, а таблиці звітів показують «не застосовується». Вид spoof і далі оцінює виявлення.
  • Два зафіксовані підсумки в tests/registry_golden.rs змінилися саме з цих двох причин і жодної іншої: golden_clock (p95 квантового та обидва значення security) і golden_orbit (обидва значення security; його значення p95 точно нульові). Їхні хеші цілого документа не змінилися. Очікувані підсумки в README, трьох навчальних посібниках і їхніх навчальних сценаріях оновлено відповідно, а tests/tutorials.rs звіряє навчальні копії з рушієм.
  • Екскурсія пісочницею більше не відкривається при першому завантаженні. Її модальне вікно перехоплювало перші кліки, а підсвічування прокручувало сторінку геть від місця, куди потрапив відвідувач. Вона починається з кнопки «Take the 60-second tour» або плаваючої кнопки Tour.
  • Сторінка більше не прокручується вбік на телефоні. За 390 px рядок бренду і кнопка GitHub займали близько 410 px вмісту, тобто переповнення на 4 px; тепер заголовок вміщається від 320 px і більше, а таблиця показників якості прокручується всередині власного блоку, а не розширює сторінку.
  • Оглядач можливостей починався з власної кількості карток («46 карток можливостей … 17 з підкріпленням зовнішнім оракулом»), поряд із README, які говорять 64 із 168. Тепер він починається з матриці верифікації, прочитаної зі згенерованого web/data/verification-matrix.json (тієї самої матриці, до якої прив'язано числа в README), а картки називає потім як підсумковий шар, яким вони є. web/counts.test.mjs, новий крок у робочому процесі безперервної інтеграції (CI), перевіряє арифметику й звіряє README.md та описи сторінки; tests/web_validation_counts_doc_sync.rs закріплює зв'язок із боку Rust.

• Публічний опис тепер починається з синхронізації часу та holdover, найкраще перевіреної області. Початок README і docs/POSITIONING.md подають Kshana як відкритий, відтворюваний рушій доказів стійкості PNT з позначеним походженням: спершу синхронізація часу й holdover критичної інфраструктури (оцінювачі Аллана, модифікованого Аллана, девіації часу та максимальної похибки часового інтервалу, а також інверсія дисперсії ходу holdover є рядками VALIDATED, що за цим стоять), квантовий напрям як нейтральний метод порівняння квантового з класичним, результати якого позначені MODELLED, а місячна / цисмісячна навігація та навігація в далекому космосі як підтримувані можливості, а не головна тема. Обидві сторінки тепер кажуть, чим Kshana не є: не симулятором радіочастотних сигналів і не стендом із апаратурою в контурі, не заміною MATLAB/Simulink, STK чи Orekit, і вказують на новий вид telecom-timing і docs/TELECOM-TIMING.md. Давній рядок «there is no good open tool» зникає: пошук, що нічого не знаходить, не є доказом того, що нічого не існує. ROADMAP.md отримує недатований порядок пріоритетів (спершу синхронізація часу, друге квантове порівняння, місячне підтримується) і прибирає три застарілі пункти (систематичні ефекти Коріоліса та світлового зсуву, початкові умови NRHO і місячний сценарій, усі випущені); рядок README «Coriolis and light-shift remain roadmap» виправлено так само.

• docs/CAPABILITY.md перестав применшувати. Рядок про земні системи координат говорив «none», тоді як матриця оцінює GCRS→ITRS як VALIDATED; тепер там «full», а рядок про базові системи відліку фіксує перехресну перевірку ANISE як виконану. Керований режим був указаний як дорожня карта; пісочниця вже має керовані повзунки та кероване знайомство. Звірка з src/verification.rs виправила ще п'ять рядків, що передували своїм перевіркам: модель сил Cowell і пакетне/послідовне визначення орбіти проти Orekit 12,2, проходження над наземною станцією проти детектора висоти Orekit, ядро геометричного чинника DOP проти gnss_lib_py та імпорт OEM проти незалежного розбирача oem; рядок верифікації й валідації тепер називає запобіжники, що перевіряють існування кожного цитованого тесту.

• Глосарій пояснює, що говорить файл результату. docs/GLOSSARY.md отримує зрозумілі описи для вихідних термінів (holdover, p95, цілісність, оцінка безпеки, PDOP, sigma_y, q_wf), термінів телекомунікаційної синхронізації (похибка часу, max|TE|, cTE, dTE, MTIE, TDEV, PRTC, ePRTC, T-BC, T-TSC, OCXO, CSAC) і трьох рівнів доказів (VALIDATED, MODELLED, PARTNER).

• Абревіатури розшифровано при першому вживанні в кожному написаному вручну публічному документі. README і 24 файли в docs/ мали кілька сотень абревіатур, ужитих до розшифрування або без нього; тепер кожну розгорнуто там, де вона вперше з'являється в цьому файлі. Три згенеровані файли (docs/VERIFICATION-MATRIX.md, docs/MODELLED-RATIONALE.md, docs/SCENARIOS.md) залишено без змін: вони пишуться з src/verification.rs і api::list_scenario_kinds(), тож їхні формулювання треба змінювати в джерелі.

• Покриття рядків має офіційно зафіксований вимір. docs/COVERAGE.md фіксує 95,63 % (37 697 із 39 419 рядків) із завдання CI coverage на b1d350d, а tests/coverage_figure_doc_sync.rs прив'язує до нього п'ять публічних поверхонь із «~96%»: єдине головне число, яке підтримувалося вручну й уже одного разу змінилося непоміченим.

• Нові шлюзи синхронізації документації для поверхонь, які ніщо не читало. tests/readme_code_fences_doc_sync.rs перевіряє кожен import { … } from "kshana" у блоці JavaScript за експортами WebAssembly і закріплює приклад Rust у README.crates.md побайтово до копії, яку компілює тестовий двійковий файл. tests/security_md_doc_sync.rs не проходить, якщо src/lib.rs втрачає #![forbid(unsafe_code)] або SECURITY.md перестає це стверджувати. tests/no_overclaims.rs тепер також сканує web/README.md і три README реєстрів, а кожен стандарт на сайті має явно вказувати свій proof.

• Дві перевірки годинника на реальному обладнанні виконуються на раннері. realdata-clock.yml (щомісяця та за запитом) отримує серії 5071A і PHASE.DAT та запускає обидва тести з KSHANA_REQUIRE_REALDATA=1, тож відсутній вхід призводить до збою, а не до пропуску. Обидва скрипти отримання закріплено на одному коміті allantools і перевіряють SHA-256.

• Типову заглушку Python перевіряють за зібраним колесом (mypy.stubtest у завданні прив'язок), через що csv/write_csv було випущено без заглушки.

• Глосарій визначає URE, EOP, FoM, CTI і TIB, які README і реєстр уживали без розшифрування.

• Опублікований контракт полів кожного виду тепер відповідає дійсності, і тест його утримує. П'ять із 61 видів змінилися. Види з непорожнім required_fields переходять з 21 до 22: ephemeris тепер вимагає tle|orbit+epoch (голий kind = "ephemeris" раніше проходив --validate, а потім провалював прогін), а quantum-trade додає candidate_adev_taus+candidate_adev_values|candidate_clock_class, чого його прогін уже вимагав. Обов'язковий запис може використовувати | (одне з цих) і + (усі ці разом); --validate розуміє обидва. lunar-joint-od-clock, pvt і earth-gnss-lunar публікують 9 справжніх необов'язкових полів, які раніше пропускали. docs/SCENARIOS.md тепер говорить, що kind є обов'язковим для кожного виду, крім clock. tests/required_fields_are_true.rs перевіряє кожен вид за його вбудованим сценарієм: видалення будь-якого обов'язкового запису має призводити до збою прогону, а документ лише з обов'язковими полями має запускатися.

• Нотатки JetBrains Marketplace контролюються шлюзом. scripts/check-version-sync.sh тепер завершується помилкою, якщо найновіший запис <change-notes> у plugin.xml не називає версію, що постачається; сім опублікованих версій несли без змін нотатки 0.22.0.

• Показник покриття в технічному звіті є виміряним. paper/kshana-technical-report.md говорив «near 97 %»; тепер там near 96 % (95,63 % виміряно, docs/COVERAGE.md), і це шоста поверхня, яку прив'язує тест покриття.

• Клієнт рушія поза головним потоком протестовано (web/engine.test.mjs, у CI): список дозволених викликів, скасування та повторний запуск, три резервні маршрути головного потоку та відновлення після збою, на фальшивому воркері.

• Нічого не публікується, доки позначений тегом коміт не пройшов свої тести, а випуск не вважається завершеним, доки кожен реєстр його не віддає. Порядок тепер такий: тег, перевірка, публікація, паритет, сайт, в одному запуску release.yml (docs/RELEASING.md).

  • Публікація чекає на вердикт. publish.yml, mcp-publish.yml і jetbrains-plugin.yml більше не стартують із надсилання тега; release.yml викликає їх із завдань, що мають needs: verify. Раніше вони перегоняли його: для v0.27.2 crates.io, npm і Python Package Index (PyPI) опублікували все протягом 4,5 хв після тега, а verify повернувся через 84 хв після нього; для v0.27.0 npm і PyPI опублікували, тоді як завдання crates.io завершилося помилкою. Ручний повтор на тезі утримує новий scripts/check-release-verdict.sh, який вимагає зеленого verify саме для цього коміту з інтерфейсу Actions і за будь-чого іншого закривається з відмовою.
  • Усе збирається до того, як щось завантажується, а crates.io, чий крок пакування і є тим, що завершився помилкою посеред випуску, публікує першим.
  • Відсутній токен реєстру призводить до збою завдання замість пропуску завантаження зі звітом про успіх.
  • Перевірка паритету після публікації. scripts/check_channel_parity.py опитує crates.io (kshana і kshana-mcp), npm, PyPI (вихідний дистрибутив і всі шість платформних коліс) та ghcr.io, доки кожен не віддасть версію, або завершує прогін помилкою; docs.rs і реєстр Model Context Protocol (MCP) повідомляються, але не обов'язкові. На минулих випусках він виявляє, що 0.22.0 відсутня в npm і PyPI, 0.23.0 у PyPI, а 0.27.0 у crates.io.
  • Зібрані двійкові файли командного рядка для macOS (Apple silicon та Intel) і Windows x86-64, названі за цільовою платформою (kshana-aarch64-apple-darwin тощо), поряд із Linux-файлом kshana, назва якого не змінилася. Файл SHA256SUMS охоплює кожен ресурс, а verify-release перевіряє його та запускає двійкові файли macOS і Windows на їхніх власних системах.
  • kshana.dev показує випуск, а не main. Раніше він розгортався заново після кожного надсилання в main, тоді як його сторінки називали останній випуск. pages.yml тепер збирає лише тег випуску: випуск запускає його один раз, коли кожен канал віддає версію, а ручний запуск повторно розгортає останній випуск (або названий).
  • Одне джерело коліс. Скопійована вручну матриця publish.yml із шести цілей зникла; він викликає wheels.yml, тож шлюз тегів auditwheel і перевірка побайтової відтворюваності тепер оцінюють колеса, які отримує PyPI, а збій в будь-якій із них зупиняє випуск.
  • Закріплені інструменти збирання. Кожен робочий процес запитує Rust 1.93.0 (завдання msrv власну версію); publish.yml і pages.yml запитували @stable, а журнал v0.27.2 показує, що rustup встановлював 1.98.1, а потім компілював за допомогою 1.93.0 лише тому, що rust-toolchain.toml має вищий пріоритет. wasm-pack закріплено на 0.13.1 (версія, що збирала v0.27.2, яку обирав незакріплений скрипт встановлення) із перевіркою контрольної суми, а mcp-publisher на 1.8.1 із його опублікованим SHA-256. scripts/check-toolchain.sh тепер завершується помилкою, якщо робочий процес просить інший компілятор або передає завантажений скрипт в оболонку. Жодне завдання перевірки, еталонне закріплення чи локальний скрипт шлюзу не видалено і не послаблено.

Безпека#

• Кожну сторонню дію GitHub Action закріплено за SHA коміту: 93 посилання у 15 робочих процесах, 92 із них нові, а тег залишено кінцевим коментарем для оновлення Dependabot. Виняток становить dtolnay/rust-toolchain, чий тег є селектором набору інструментів.

• Базові шари образу сервера MCP закріплено мультиархітектурним дайджестом, а Dependabot тепер стежить за Dockerfile mcp/kshana-mcp, тож шари ОС і далі отримують оновлення безпеки через переглянутий PR.

• Перевірка тега проти маніфесту виконується в обох робочих процесах публікації, що постачають версію тега. mcp-publish.yml (образ ghcr, реєстр MCP) і jetbrains-plugin.yml (Marketplace) перегоняють publish.yml, а не чекають на нього, тож хибно створений тег контролювався лише в суміжному. Обидва тепер запускають scripts/check-version-sync.sh перед збиранням.

• Виправлено чотири повідомлення безпеки, які Dependabot підняв у день увімкнення сповіщень. Сервер MCP переходить з rmcp 1,7 на 2,2: три повідомлення проти rmcp < 2,1 (витік таблиці сеансів Streamable-HTTP, відсутня перевірка захищеного ресурсу OAuth, власні заголовки, що слідують за міжвитоковим перенаправленням), жодне з яких тут недосяжне, бо сервер говорить лише через stdio, але опублікований крейт не повинен закріплювати вразливий SDK. Макроси rmcp 2 потребують Rust 1,88, тому лише kshana-mcp тепер оголошує rust-version = "1.88"; бібліотека kshana залишається на 1,85. Єдину зміну API (Content → ContentBlock) застосовано, а тести повного обміну проходять. Дію сканування SonarQube переведено з v5 на v6, що виправляє повідомлення про ін'єкцію аргументів (≥ 4,0, < 6,0).

0.27.2 - 2026-09-22#

Додано#

• Кожен елемент Rust, який цитує рядок матриці верифікації, тепер зіставляється з крейтом. Наявний запобіжник перевіряв цитати у формі шляхів до файлів; 63 зі 164 непартнерських рядків натомість називають свої докази як елемент усередині крейта: navsignal::code_tests, integrity::tpl_scalar::tests, api::tests::tracking_loop_kind_round_trips_through_the_dispatch, а токен без суфікса .rs був невидимий для сканера шляхів. Ці рядки могли б називати перейменований модуль, спорожнений тестовий модуль або функцію, якої ніколи не існувало, і кожен шлюз лишався б зеленим.

  tests/verification_rows_name_a_test_that_exists.rs зіставляє всі 339 таких цитат через дерево модулів, вимагає від кожного непартнерського рядка назвати щонайменше один тест, що справді має #[test], і вимагає від партнерських рядків не називати жодного. Для оцінювання використано чотири мутації: перейменування цитованого модуля, спрямування єдиної цитати тесту в рядку на нетестову функцію, перейменування справжнього mod tests і вилучення з нього атрибутів #[test]; кожна з них червоніє на твердженні, якому належить.

  Один рядок уже був хибним: Alternative / complementary PNT цитував tests/*, глоб, що не є цитатою. Тепер він називає tests/alternative_complementary_pnt_reference.rs і три модулі тестів усередині крейта, що за ним стоять.

• Опубліковані показники перевіряються заново рушієм при кожній збірці (tests/published_figures_still_reproduce.rs). Три демонстраційні діаграми README є власним виходом chart.svg рушія, і ніщо не перезапускало сценарій; два дослідження перетину в статті було створено один раз і зафіксовано; а README викладає чотири показники якості прозою поряд із scenario-fom.png. Усі три тепер прив'язано до живого виходу рушія.

  Звірка принесла корисний результат: демонстраційні діаграми було намальовано рушієм 0.22.0, а JSON перетину статті рушієм 0.20.0, а на 0.27.1 кожне нанесене значення в усіх п'яти артефактах ідентичне: три SVG-діаграми відрізняються від свіжого прогону рівно двома символами кожна, позначкою версії в нижньому колонтитулі. Діаграми перемальовано, щоб колонтитул був правдивим. JSON статті навмисно залишено позначеним 0.20.0: це запис прогону, показник якого вбудовує опублікована стаття, а переоформлення стверджувало б походження, якого PDF не має. Натомість запобіжник стверджує сильнішу властивість: що поточний рушій і далі відтворює кожне опубліковане значення.

Виправлено#

• Аналізи SonarCloud записувалися як VERSION=not provided, тож період нового коду previous_version ніколи не просувався: він і далі був прив'язаний до аналізу від 2026-07-02, оцінюючи вісімдесят два дні роботи як одну дельту та вимірюючи 7877 «нових» дубльованих рядків проти порога 3 %. Тепер сканування передає версію крейта. Основне дублювання є справжнім і цим не приховується: воно зосереджене в декларативних реєстрах FieldUnit, що повторюються в ensemble, hybrid, fusion, inertial і report, та в 168-рядковій таблиці верифікації, і названо тут роботою, а не виключено з вимірювання.

• scripts/gate.sh не мав блокування єдиного записувача, і кожен прогін писав той самий журнал. Це не питання охайності: integration_binaries, tests_passed і tests_ignored квитанції зчитуються НАЗАД із цього журналу, а хук перед надсиланням довіряє квитанції. Шлюз, який було вбито, але чий тестовий двійковий файл ще жив, продовжував писати у файл, який наступний прогін щойно обрізав, тож лічильники одного прогону могли бути засвідчені як лічильники іншого, дозволяючи надсилання на підставі набору, що ніколи не запускався на дереві, яке надсилають. Тепер це один шлюз на checkout (відмова з кодом виходу 75 поряд із живим, очищення застарілого блокування, чий pid зник) і один журнал на прогін, а target/gate-run.log оновлюється із завершального прогону при виході. Обидва напрями протестовано: живий pid відхиляє, мертвий очищується.

• src/verification.rs стверджував, що його тести «do not prove the named test/oracle strings resolve to live code». Два запобіжники тепер роблять саме це, тож документація модуля говорила протилежне правді; тепер вона зазначає, що перевіряється машиною, а що залишено людському судженню. Застаріле посилання на verification::gen, де модуль називається artifacts, виправлено у власній документації суміжного запобіжника.

Змінено#

• main було переписано 2026-09-22 і примусово надіслано. Десять комітів стали чотирма. Переписування злило кожен коміт, що залишав шлюз червоним, у коміт, який його очистив, тож кожен коміт у main тепер має дерево, що проходить, і прибрало скасовані прогони, які групу паралельності на рівні гілки залишала на кожному замінному коміті.

  Нічого не відкинуто. Коміти до переписування залишаються досяжними через теги, що на них вказують, а кінцеве дерево побайтово ідентичне дереву, з якого розпочалося переписування: git diff між старою та новою верхівкою порожній, окрім трьох файлів робочих процесів, які змінює цей випуск.

  Замінені SHA для тих, хто тримає посилання на один із них:

  старий	тема
  9733177	docs(changelog): розкрити переписування авторства та два висячі sha1 крейтів
  5d16ea8	fix(docs): діаграма потоку рушія казала 6 показників якості; рушій оцінює 7
  148d31d	fix(test): ще два крос-платформені закріплення та два мої власні хибні припущення
  a3a2667	feat(web): показати місячний кластер на сайті: сім карток можливостей
  1e8bec6	docs(lunar): задокументувати 42 публічних поля та знизити стелю до 985
  7bba514	chore(release): v0.27.0
  3154548	test(docs): захистити діаграму розповсюдження, останню незахищену
  7864142	chore(release): v0.27.1

  Теги v0.27.0 і v0.27.1 навмисно НЕ переміщено. Вони й надалі вказують на 7bba514 і 7864142, точні коміти, чиї дерева створили артефакти, що тепер доступні на crates.io, npm, PyPI, ghcr.io і в реєстрі MCP. .cargo_vcs_info.json крейта записує sha1, з якого його запаковано, реєстри незмінні, а атестація походження збірки SLSA на ресурсах випуску v0.27.1 прив'язана до цього коміту. Переміщення тегів залишило б кожен із цих опублікованих артефактів указувати на коміт, якого більше не існує. Залишення їх зберігає старі коміти досяжними, а кожен опублікований ланцюг походження розв'язуваним, ціною двох тегів, що більше не є предками main, і саме тому існує цей випуск: v0.27.2 дає main власний тег, запакований із коміту, що на ньому лежить.

  Це друге розкрите переписування цієї історії; перше, 2026-09-21, канонізувало авторство і зафіксоване в нотатках 0.27.0 разом із двома власними висячими sha1 крейтів. Переписування розкривається тут щоразу, тому що репозиторій, який продає перевірюване походження, не може тихо зсувати ґрунт під опублікованим артефактом.

0.27.1 - 2026-09-22#

Виправлено#

• Опублікований крейт не компілювався. src/lunar_orientation.rs містить include_str! верхнього рівня для tests/fixtures/llr_geometry/de440_moon_pa.csv, а маніфест виключає /tests/fixtures із пакета, тож архів, який отримує crates.io, не мав файла, що його вбудовує сама бібліотека. Публікація v0.27.0 не пройшла збірку перевірки саме з цієї причини, і жодна 0.27.0 не дійшла до crates.io; npm і PyPI, чиї завдання від нього не залежать, опублікувалися нормально. Виключення тепер має виняток для цього одного каталогу.

  Кожен інший include_str! фікстури в src/ міститься всередині модуля #[cfg(test)] і тому ніколи не потрапляє в пакетовану бібліотеку. Лише верхнього рівня потрапляє.

• Ніщо в CI не запускало cargo package, тому архів, що не може скомпілюватися, вперше виявило завдання публікації, коли два інші реєстри вже випустили. Завдання package тепер збирає і компілює саме цей архів при кожному надсиланні.

Змінено#

• Закріплення емісії реалізації місячної системи координат більше не зсуваються при підвищенні версії. Нижній колонтитул SVG несе версію рушія, тож кожен випуск повторно базував три хеші, двічі за один день, а закріплення, перезняте за рутиною, перестають читати. Рядок версії нормалізується до заповнювача перед хешуванням, а емісія окремо перевіряється на вказування запущеної версії, тож цей факт перевіряється точніше, ніж його коли-небудь перевіряв хеш.

0.27.0 - 2026-09-22#

Додано#

• lunar-llr-datum: еталон місячної системи координат за реальною кампанією спостережень. lunar-frame-campaign замінив уведене перетворення Гельмерта симульованою кампанією і прямо про це сказав: її мережа станцій, її розклад і її сигма на спостереження є ілюстративними вхідними даними. Цей сценарій прибирає симуляцію з двох місць, де розклад і модель похибок входять у відповідь. Епохи є часами передавання 337 заархівованих нормальних точок лазерної локації Місяця ILRS (2015-04-08 .. 2015-06-27, Grasse MeO 7845 і Matera MLRO 7941, усі п'ять масивів ретрорефлекторів), а вага кожного спостереження є власною заархівованою точністю цієї нормальної точки, bin_rms / sqrt(n_raw): медіана 5,13 мм односторонньої дальності, узята з файла, а не обрана тут. Координати станцій походять із IERS ITRF2020, а координати рефлекторів із таблиці 7 JPL DE430; кожна фікстура фіксує URL, дату отримання і SHA-256 та відтворюється зі свого джерела зафіксованим генератором, який перевіряє джерело й переривається, а не видає число. Звіт називає, які ланки виміряні, а які залишаються змодельованими, і змодельовані виміряно: різниця спостережуваної та обчисленої односторонньої дальності за реальними даними становить 156 494 м середньоквадратично, що той самий набір тестів підтверджує проти JPL Horizons на тому самому проміжку (195 655 м середньоквадратично за вектором, найгірша епоха 0,054°, у межах ~0,3°, які для себе стверджує вбудований аналітичний місячний ряд). Додатково: новий вид, новий зчитувач (realdata::llr_crd) і новий модуль (lunar_llr); наявні пакети місячної системи координат закріплено біт у біт.

• sigma_ure_m як параметр сценарію для lunar-integrity і moonlight-service-volume. Точність дальності сигналу в просторі була константою часу компіляції (LUNAR_SIGMA_URE_M), тож перебір обсягу обслуговування міг відповісти лише «пройшло/не пройшло» за одного фіксованого значення. Рівні захисту точно лінійні щодо неї, тому її відкриття перетворює перебір на вимогу до точності дальності в усьому обсязі. Типове значення відтворює попередню поведінку біт у біт.

• Експорт геометрії для кожного супутника у moonlight-service-volume: export_site_lat_deg + export_site_lon_deg додають масив per_sat_geometry, що дає азимут, висоту та похилу дальність до кожного супутника в кожну епоху для одного названого селенографічного місця, а також прапорець видимості. Підсумок сукупного покриття навмисно згортає геометрію кожного супутника, але похила дальність є саме тим, що споживає бюджет лінії зв'язку, тож спільний аналіз зв'язку та навігації неможливо було виконати лише за підсумком. Вимкнено, якщо не задано обидві координати; суто додатково.

• lunar_service::topocentric, публічний помічник кутів огляду, що стоїть за експортом.

• Рядок матриці верифікації для нової можливості геометрії.

• Справжня діаграма спрямованості антени в експорті геометрії. Рушій від P1 несе діаграму кругової апертури з рівномірним освітленням (antenna::pattern_gain_dbi, форма Ейрі [2·J₁(x)/x]²), і ніщо поза antenna.rs її не використовувало: натомість роботу виконували посилення на осі, поєднане з емпіричним правилом залежності ширини променя від посилення. Необов'язкова таблиця export_antenna у moonlight-service-volume (зчитується лише тоді, коли задано місце експорту) тепер дає кожному експортованому рядку кут від осі на супутнику та посилення передавання в бік місця за цією діаграмою і додає блок antenna_pattern, який повідомляє кількість у промені за справжньою діаграмою поряд із кількістю в промені за симетричним наближенням (θ₃dB[deg] = √(31000/G_lin)), а різницю як названу поправку. Обидва числа видаються; жодне не замінює інше. Виміряно на власній репрезентативній місячній апертурі рушія (тарілка 1 м, 2,4 ГГц, η = 0,60) над південнополярним місцем та ілюстративною оболонкою класу LCNS, ці два розходяться більш ніж на один супутник: за справжньою діаграмою 0 із 76 видимих ліній зв'язку лежить усередині променя половинної потужності, наближення стверджує 28, тобто поправка −2,33 супутника на епоху, найгірша окрема епоха 3. Наближення несе власну ефективність апертури (0,641 проти правила 70·λ/D градусів, яким його зазвичай цитують, 0,920 проти рівномірної кругової апертури), тож для тарілки з η = 0,60 воно повертає промінь у 1,238× ширший; блок видає обидві неявні ефективності, а не залишає їх для виведення. Суто додатково: виміряно в документованій робочій точці, 597 наявних листків, 0 змінено, 0 видалено, 494 додано.

• antenna::symmetric_beamwidth_rad, antenna::symmetric_relation_implied_efficiency, antenna::within_half_power_beam, antenna::HALF_POWER_DROP_DB, antenna::SYMMETRIC_GAIN_BEAMWIDTH_CONST_DEG2, antenna::UNIFORM_APERTURE_HPBW_COEFF і lunar_service::nadir_off_boresight_rad, публічні елементи, що стоять за цим. Діаграму також тепер прив'язано до опублікованих констант Ейрі, а не лише до себе самої: перетин половинної потужності знаходиться бісекцією й порівнюється з x = 1.61634, що робить точну ширину половинної потужності 1.02899·λ/D і чесно фіксує, що загальноприйнятий коефіцієнт 1.02 ставить pattern_gain_dbi на −2,955 дБ, а не −3,010 дБ.

• Довгоформатна таблиця відтворюваності для lunar-time-budget. Виходи сценарію у вигляді масивів, тобто сітка часів усереднення, сім кривих x(τ) за кожним доданком і їхня сума у вигляді кореня із суми квадратів, доходили до споживачів лише як масиви JSON. Одну випущену таблицю було обрізано на 400 символах, і вона опублікувала 23 зі своїх 57 часів усереднення під стовпцем, що стверджував, ніби містить усі, а рукопис відбудовував криві за кожним доданком із замкнених форм, бо рушій їх ніколи не видавав. Звичайний прогін тепер також записує <scenario>.table.csv з одним рядком на (індекс сітки, час усереднення, доданок), який неможливо обрізати до чогось, що все ще виглядає цілим. Індекс сітки є точним ключем з'єднання; τ записується з 13 значущими цифрами, а кожен x із 7, тож байти не розходяться між збірками того самого джерела. Суто додатково: JSON звіту побайтово ідентичний.

• Звіт hybrid-optical-rf тепер описує сам себе. Блок link_configuration віддзеркалює розв'язані вхідні дані лінії зв'язку: довжину хвилі несівної, апертуру передавання й приймання, дальність, тривалість імпульсу, час інтегрування, ефективності та втрати, із застосованими типовими значеннями, тож стаття називає конфігурацію, на якій виконувалась, а не цитує типове значення, зчитане з джерела. Блок units дає одиницю та клас походження кожної величини, яку стаття, імовірно, цитуватиме. Причиною його появи є сліди коваріації передавання: вони видавалися як голе variance, а рукопис вивів квадратні метри з перевірки внутрішньої узгодженості. Висновок був правильним, і саме тому він був дефектом: ніщо не помітило б, якби він був хибним. Суто додатково: виміряно в чотирьох конфігураціях, 456 наявних полів, 0 змінено, 0 видалено, 196 додано.

• Рядок матриці верифікації для таблиці відтворюваності бюджету часу, чесно InternalConsistency / MODELLED: підсумок перевіряється за кореневою сумою квадратів доданків у тому самому файлі, який поділяє власні визначення доданків рушія, а тому не є незалежним оракулом. Разом вони додають три рядки. Поточний підсумок для цього невипущеного розділу становить 168 рядків: 64 VALIDATED, 100 MODELLED, 4 PARTNER.

Змінено#

• Авторство комітів у всій історії тепер є єдиною особою, і два опубліковані крейти вказують на коміт, якого більше не існує. 2026-09-21 історію git було переписано так, що кожен коміт людини має автором і комітером ashfordeOU <236818772+ashfordeOU@users.noreply.github.com>. Раніше вона містила три написання однієї особи: 688 комітів як ashfordeOU <contact@ashforde.org>, 34 як Chakshu Baweja <contact@ashforde.org> і 94 уже канонічних. Єдиний коміт dependabot[bot] навмисно залишено з його власним автором: перепозначення оновлення залежностей бота стверджувало б авторство роботи, якої тут ніхто не виконував.

  Вміст не змінився. Переписування торкнулося лише заголовків автора й комітера, і це можна перевірити, а не просто стверджувати: дерево кожного тега та кожної гілки біт у біт таке саме, як було раніше. v0.26.0 і далі розв'язується до дерева 92284e9420605568f1bfabb78cd95d383b40f3e2, точно як і раніше.

  Чого це коштувало. Назва коміту є хешем його дерева, батьків і заголовків автора, тож зміна предка перейменовує кожного нащадка. Коміт випуску v0.26.0 мав назву dce2dbf7700788cf6de46260c14673c0e5347360, а тепер d4921f3025569e00e425e1747d0acfc261e96e18. Два артефакти записали стару назву під час публікації й не можуть бути виправлені, бо опублікована версія реєстру за задумом незмінна:

  • kshana 0.26.0 на crates.io: .cargo_vcs_info.json фіксує dce2dbf…
  • kshana-mcp 0.26.0 на crates.io: той самий sha1, path_in_vcs: mcp/kshana-mcp

  Більше нічого не зачеплено. Пакет npm не фіксує gitHead, а дистрибутив PyPI не фіксує жодного коміту; обидва перевірено, а не припущено.

  Немає виправлення, яке змусило б dce2dbf… називати переписаний коміт: цей рядок і є старою спадковістю, а єдиний спосіб, у який він розв'язується, це залишити опублікованою історію до переписування, що відновило б авторство, яке переписування прибрало. Тому походження для 0.26.0 іде через тег, а не через записаний sha1, і тег доставляє ті самі байти, з яких зібрано крейт. Наступний випуск записує дійсний коміт без жодних дій.

Виправлено#

• realtime-frame-eop за замовчуванням використовував файл EOP без рядків прогнозу (G12). Сценарій вбудовував п'ятирядковий витяг finals2000A лише з остаточними значеннями як свій автономний типовий, тож голий прогін повідомляв predicted_rows.n = 0, а таблиця за горизонтами трималася на парах 5, 4, 3 і 2. Рушій завжди міг прочитати рядок прогнозу; у вході їх просто не було. Тепер типовим є дослівний витяг IERS 2026 (tools/finals2000A_2026.txt, MJD 61173–61204): 20 остаточних значень Bulletin B і 12 рядків лише з прогнозом Bulletin A, тож голий прогін без аргумента файла й без мережі повідомляє predicted_rows.n = 12 та таблицю за горизонтами на n = 20 / 31 / 30 / 29, а також заповнюються порівняння з оперативним прогнозистом і узгодження з власними опублікованими прогнозами продукту. Довгий 45-рядковий витяг було виміряно як альтернативу й відхилено: він теж лише з остаточними значеннями, тож залишив би predicted_rows.n на 0. Це змінює опубліковані числа за правилом R4 і з дозволу засновника: десять із 22 комірок випущеного p4_frame_eop.csv і 24 із 42 заповнених комірок tests/golden/realtime-frame-eop.csv. Виміряна нижня межа полюса «швидкий мінус остаточний» стає 0,0678 мкс дуги (було 0,0769 мкс дуги), що є значенням, яке таблиця руху полюса власної статті P4 уже публікує на n = 20; тепер вони збігаються замість розбіжності на 13,5 %. Кожен інший показник, який P4 друкує з цієї таблиці, не змінюється з точністю друку. Повний перелік старе → нове, включно з полями, які не змінилися, міститься в docs/revisions/G12-default-eop-cell-changes.md. Витяг лише з остаточними значеннями й далі постачається, закріплений побайтово та виконується: нульова кількість рядків прогнозу в ньому є властивістю файла, і тест досі це доводить.

• Застаріле обмеження кількості супутників у moonlight-service-volume. Сценарій обмежував n_sats значенням 12, хоча його власний конструктор орбітального угруповання підтримує 24 і тест перевіряє 24; тому кожна запитана кількість понад 12 мовчки зменшувалася, а перебір за кількістю супутників повертав однакові значення понад 12 — їх неможливо було відрізнити від справжнього геометричного насичення. Тепер обмеження встановлено на межі конструктора. Це зміна поведінки лише для n_sats > 12.

• Той самий застарілий ліміт у lunar-differential-pnt. lunar_dpnt обмежував n_sats значенням 12 з тим самим наслідком, і цей дістався до опублікованої таблиці: dpnt_nsats_sweep.csv містить рядок n = 16, побайтово ідентичний своєму рядку n = 12, бо рушій повертав відповідь для дванадцяти супутників під позначкою шістнадцяти. Тепер обмежено межею конструктора 24, і новий тест її закріплює: кожне більше орбітальне угруповання має і повідомляти власну кількість, і строго покращувати рівень захисту, тож ліміт не може повернутися непоміченим. Це змінює опубліковані числа: рівень захисту n = 16 стає 16,92 м → 14,57 м. За переборювання до 24 крива строго монотонна (11,94 м за 24 супутників, на 29,5 % краще, ніж за 12), тож насичення на 12 немає: видиме плато було лімітом. Зміна поведінки лише для n_sats > 12.

0.26.0 - 2026-09-18#

Випуск документації, прозорості та пісочниці. Поведінка рушія не змінюється: матриця верифікації складається з 102 рядків: 56 VALIDATED, 42 MODELLED, 4 PARTNER, без змін відносно 0.25.0.

Додано#

• Rustdoc рівня крейта (//! у lib.rs), що охоплює точки входу, модель чесності/рівнів і відтворюваність, тож docs.rs відкривається на справжній вступній сторінці, а не на голій стіні модулів.
• docs/SCENARIOS.md: довідник за видами для всіх 50 видів сценаріїв, згенерований з api::list_scenario_kinds() (єдине джерело істини) за допомогою gen_validation_artifacts і захищений tests/scenarios_reference_doc_sync.rs, тож не може розійтися з диспетчером.
• Документація модулів для 11 раніше недокументованих публічних модулів (allan, estimator, fom, hybrid, inertial, models, report, run, scenario, timetransfer, types).
• Літературні джерела для п'яти формульних модулів, що наводили рівняння, але не називали посилання: batch_ls (Tapley/Schutz/Born; Bjorck), cr3bp (Szebehely; Koon et al.), detection (Kay), attitude_budget (Wertz; Sidi), reentry (Allen-Eggers, NACA TR-1381).
• Опублікований security.txt на kshana.dev для узгодженого розкриття вразливостей.
• Рівень валідації за прогоном у пісочниці. Таблиця показників якості одного прогону тепер несе позначку VALIDATED/MODELLED для кожного показника, зчитану з того самого пошуку fomTier(), який використовує звіт для завантаження (віддзеркалює src/fom_label.rs, сам виведений з матриці верифікації), тож рівень, показаний поряд із живим числом, ніколи не може розходитися з реєстром.
• lunar-attack-surface у меню пісочниці: усі 50 видів, що диспетчеризуються, тепер на відстані одного кліку (було 49/50).
• Ще п'ять карток можливостей із запуском (космічна погода, оцінювання впливу радіочастотних завад, стійкість, взаємодія CCSDS OEM, KIF), що піднімає кількість карток із запуском з 11 до 16. Картки лише для API та бібліотек зберігають чесне посилання на документацію, а не фальшиву кнопку запуску.

Змінено#

• Покриття документації тепер храповано в CI. check-doc-coverage.sh компілює бібліотеку з missing_docs, рахує попередження та завершується помилкою лише тоді, коли кількість перевищує закріплену стелю (986). Жорсткий #![warn(missing_docs)] під -D warnings перетворив би ~1000 наразі недокументованих публічних елементів на збій збірки за одну ніч; так нові недокументовані публічні елементи провалюють збірку, а наявний борг погашається свідомо.

Виправлено#

• Рядок інструмента MCP list_scenario_kinds рекламував «~17 вбудованих видів сценаріїв», тоді як api::list_scenario_kinds() уже давно виставляв 50: документ, звернений до агентів, применшував реальну можливість утричі. Закріплено на справжньому числі.
• Заново згенеровано оракул відповідності SBOM CycloneDX для оновленого графа залежностей (60 компонентів). Вердикт відповідності не змінився: нуль нормалізованих помилок схеми, і кожен атомарний ідентифікатор ліцензії, як і раніше, є в офіційному переліку SPDX.

0.25.0 - 2026-07-15#

Додано#

• П'ять можливостей підвищено до зовнішньо VALIDATED, кожну тепер перехресно перевірено за незалежною сторонньою реалізацією тієї самої однозначно визначеної величини (нециклічно, з фікстурами, що відтворюються офлайн):
  • Перетворення степеневого закону IEEE-1139 у девіацію Аллана проти замкнених форм allantools для всіх п'яти типів шуму (tests/powerlaw_oadev_reference.rs);
  • ваги формувача діаграми CRPA MVDR / мінімальної норми з гасінням у напрямку завади проти LAPACK у numpy/scipy (tests/crpa_reference.rs);
  • визначення орієнтації Wahba / TRIAD / QUEST проти SVD Rotation.align_vectors SciPy на безшумних спостереженнях (tests/wahba_reference.rs);
  • обмін блоком коваріації CCSDS 502,0 OEM повним колом через розбирач незалежної бібліотеки oem (tests/ccsds_oem_covariance_reference.rs);
  • ядро статистик виявлення при захопленні з квадратичним законом (узагальнене Marcum-Q / P_d / P_fa / поріг) проти SciPy ncx2/chi2 (tests/acquisition_reference.rs). Машинно перевірена матриця валідації переходить до 56 VALIDATED · 42 MODELLED · 4 PARTNER у 102 рядках (було 51 · 47 · 4). Чесні застереження щодо обсягу збережено: наприклад, підвищення для захоплення охоплює лише ядро статистик виявлення; CFAR/втрата від прямування залишаються MODELLED.
• Показники якості в області позиції (fom::positioning_performance): точні CEP, SEP і 2DRMS за 3-D ENU-коваріацією позиції навігаційного розв'язку та горизонтальним рівнем захисту. CEP/SEP — це точні медіани радіальної похибки (а не лінійне правило 0.589·(σ₁+σ₂)), перехресно перевірені за квантилями rayleigh/maxwell з scipy.stats та незалежною медіаною Монте-Карло в NumPy (tests/positioning_fom_reference.rs). Замінює попередню чесну заглушку «не реалізовано» — сигнатуру функції змінено: замість (), що повертала помилку, тепер (cov_enu, hpl_m), що повертає PositioningFom.
• Еквівалентні ступені свободи (EDF) довірчого інтервалу завершено для всіх оцінювачів родини Аллана (assurance::uncertainty::edf): EDF модифікованого Аллана, Адамара та повної дисперсії тепер використовують комбінований алгоритм EDF Greenhall і Riley та форму TOTVAR з таблиці 7 NIST SP 1065 (раніше було реалізовано лише EDF перекривного Аллана; інші мовчки його перевикористовували), перехресно перевірено за allantools edf_greenhall/edf_totdev (tests/uncertainty_edf_reference.rs).
• Незалежні зовнішні перехресні перевірки для можливостей геометрії місячного PNT, DOP, EOP, DRO та радіочастотних вимірювань дальності (tests/validate_p*.rs, з фікстурами та генераторами оракулів у tests/fixtures/{p1_footprint,lunar_service,eop_prediction,rf_ranging_precision,dro_family_jpl,p2_independent_dop}/). Кожна перевірка проганяє вже випущену змодельовану можливість проти оракула, створеного іншою реалізацією, тож узгодження нециклічне: орбітальна зона передавання/захоплення проти scipy.special.j1 (Cephes, справді інша функція Бесселя J1); геометричний DOP поверхневих маяків проти незалежного розв'язання (HᵀH)⁻¹ у NumPy; зростання похибки прогнозу персистентності UT1/EOP проти окремого повторного розбору в NumPy тих самих дослівних рядків IERS finals2000A; планарна родина дальніх ретроградних орбіт проти Three-Body Periodic Orbit Database від NASA/JPL; і бюджет точності радіочастотного вимірювання дальності проти еталона з перших принципів. Це додаткові докази регресії для наявних модулів; додавання цих перехресних тестів саме по собі не змінює позначки жодної можливості (п'ять підвищень вище є окремими змінами статусу на основі оракулів у src/verification.rs).
• Сценарій lunar-attack-surface (src/attack_surface.rs, kind = "lunar-attack-surface"): складений, досяжний з двійкового файла (CLI / Python / MCP / wasm через run_toml) прогін P1 безпеки місячних сигналів, що зшиває дефіцит потужності бюджету лінії зв'язку та його смугу чутливості 12–18 дБ, потрібну потужність передавання завади/спуфінгу залежно від відстані, орбітальну зону захоплення за справжньою діаграмою спрямованості антени, результат втягування захоплення спуфінгу контуром стеження, досяжність горизонту безповітряного тіла та бюджет автентифікації OSNMA/TESLA. Порожнє тіло відтворює базовий рівень P1.
• Смуга чутливості дефіциту потужності (linkbudget::deficit_sensitivity_band, deficit_power_factor): справжній багатоосьовий перебір (еталон × EIRP × похила дальність), побудований на sweep::SweepAxis і обчислений через received_signal_power_dbw, що відтворює смугу P1 12–18 дБ і зводить лінійні множники 32× (округлено) / 36× (без округлення).
• Тривимірний куб захоплення спуфінгом (spoof_capture::capture_cube): додає до карти захоплення вісь зсуву несівної/Доплера (J/S × зсув коду × зсув несівної, час утримання сигналу в кожній комірці); зріз із нульовою несівною точно зводиться до 2-D capture_map.

Змінено#

• Виявлення розрідженою мережею моніторів (monitor_network) тепер складає фізичну AGC-статистику spoof_monitors і селенографічну сітку видимості lunar_service, щоб вивести статистику виявлення й геометрію кожної станції, замість вільних параметрів і довільного перекриття великих кіл; ймовірності виявлення окремого монітора та мережі залишаються замкненими формами хі-квадрат/Marcum-Q з detection. Поля SurfaceMonitor / SpoofEvent змінено на фізичні величини (широта/довгота/висота/потужність).

Виправлено#

• Оцінювання накладних витрат автентифікації OSNMA/TESLA (nma_budget): частини полів OSNMA на сторінку (8-бітовий HKROOT + 32-бітовий MACK на сторінку в 2 с) було помилково позначено як підсумки на підкадр, що применшувало накладні витрати в 15× (1,33 біт/с). Виправлено на опубліковані підсумки на 30-секундний підкадр із SIS-ICD (HKROOT 120 + MACK 480 біт ⇒ 20 біт/с). Наслідок тепер названо чесно: за швидкості навігаційних даних AFS 50 біт/с накладні витрати автентифікації становлять першорядні ≈40 %, а не незначні кілька відсотків; поле auth_latency задокументовано як затримку розкриття ключа (нижню межу часу до першого автентифікованого розв'язку).

0.24.0 - 2026-07-09#

Широкий випуск можливостей. Він приносить два повністю зовнішньо перевірені набори аналізу: повну родину багатокритеріального аналізу рішень (MCDA) та оцінювачі блукання Аллана / довгострокової стабільності годинника при великих τ, і відкриває на основі підкладки новий шар сценаріїв із запуском: місячний бюджет часу, система координат/EOP у реальному часі, оптико-радіочастотний гібрид, спостережуваність цисмісячного простору та стійкість до конфліктів багатошарового PNT, а також підкладку можливостей місячного поверхневого маяка і безпеки сигналів. Машинно перевірена матриця валідації зростає до 51 VALIDATED · 47 MODELLED · 4 PARTNER у 102 рядках (було 40 · 47 · 4 у 91): усі одинадцять нових рядків є валідаціями рішень аналізу й оцінювачів синхронізації за зовнішнім оракулом, перевіреними проти незалежних бібліотек (SciPy, pymcdm, pyDecision, allantools) із жорстким допуском, тоді як нову поверхню можливостей PNT чесно подано як MODELLED. Як і раніше, жодне твердження числової моделі не підвищується без зовнішнього набору даних за ним.

Додано#

Сценарії із запуском: кожен є зареєстрованим kind сценарію, що диспетчеризується через рушій і наскрізно підтверджений у CI тестом tests/determinism.rs (який запускає кожен вбудований scenarios/*.toml і жорстко завершується помилкою на будь-якій фікстурі, яку не можна запустити):

• Стійкість багатошарового PNT до конфліктів (conflict-resilience, src/conflict_resilience.rs): рушій стійкості Монте-Карло із зерном для багатошарової архітектури PNT із моделлю виживання з плавним погіршенням за вектором за § 4,2 (чотири названі вектори загроз, замкнена форма виживання придатного PNT, до якої збігається Монте-Карло кожного шару, видана в JSON результату) і задокументованим, захищеним від дрейфу походженням параметрів загроз (src/conflict_threat_params.rs). Архітектури MODELLED; збіжність Монте-Карло виживання до замкненої форми є перевіреним ядром.
• Спостережуваність цисмісячного простору (cislunar-observability, src/cislunar_observability.rs): власний спектр граміана спостережуваності вздовж дуги, засівач дальньої ретроградної орбіти (DRO) із диференціальною корекцією та незалежна перехресна перевірка фільтром квадратного кореня інформації, чия апостеріорна коваріація стає скінченною саме за повного рангу спостережуваності. Орбітальне угруповання MODELLED; інваріанти рангу/граміана/STM/SRIF становлять перевірене ядро.
• Безперервність і цілісність гетерогенного оптико-радіочастотного гібрида (hybrid-optical-rf, src/hybrid_integrity.rs, src/optical_availability.rs, src/optical_linkbudget.rs, src/cross_raim.rs): міждоменна доступність і цілісність, коли поєднуються оптичний і радіочастотний PNT. MODELLED.
• Ендогенний місячний бюджет часу (lunar-time-budget, src/lunar_time_budget.rs) і бюджет системи координат / EOP у реальному часі (realtime-frame-eop, src/realtime_frame_eop.rs, src/frame_eop.rs): бюджети місячного часу й орієнтації Землі P3/P4, виведені ендогенно з ланцюга синхронізації, а не декларовані. MODELLED.

Зовнішньо перевірені набори аналізу: можливості бібліотеки, кожна з яких входить до матриці як нові рядки VALIDATED (перевірені за незалежним зовнішнім оракулом, а не самоперевіркою):

• Повний набір багатокритеріального аналізу рішень (MCDA) (src/mcda/): чотири родини методів: агрегація цінності (WSM, WPM, WASPAS), система відношень (MOORA) і пропорційна (COPRAS), відстань до ідеалу (TOPSIS), компромісне програмування (VIKOR) та переважання (PROMETHEE II із шістьма формами узагальненого критерію, ELECTRE I узгодженість/неузгодженість), а також вагові коефіцієнти пріоритету AHP за власним вектором Перрона із шлюзом коефіцієнта узгодженості Saaty (CR < 0,10), корисність MAUT, виділення фронту Парето та аналіз чутливості до ваг. Дев'ять агрегаторів відтворюють pymcdm / pyDecision, а власний вектор AHP збігається з SciPy/LAPACK, усе до < 1e-9 (tests/mcda_*_reference.rs). Торнадо чутливості також виводиться всередині сценарію стійкості до конфліктів.
• Блукання Аллана та оцінювачі довгострокової стабільності годинника при великих τ (src/allan.rs): MTIE (статистика блукання «розмах до піка» похибки часу за ITU-T G.810/G.823/G.8261, на яку писано маски синхронізації), часове блукання MDEV і TDEV та оцінювачі розширеного діапазону Theo1 / TOTVAR. VALIDATED проти allantools на серії NIST SP 1065; гібрид ThéoH зі знятим зміщенням, побудований на TOTVAR, чесно залишається MODELLED.
• Забезпечення / каркас зовнішнього оракула (src/assurance/): каркас оракула, під'єднаний безпосередньо до шлюзу чесності CI, запис походження W3C-PROV з детермінованим коренем Меркла та Greenhall еквівалентні ступені свободи + довірчі інтервали хі-квадрат для оцінок стабільності.
• Шов розширення PackRegistry / ExternalPack (src/registry.rs, src/api.rs): шов диспетчеризації, щоб пакети можливостей маршрутизувалися через один реєстр (вбудована диспетчеризація лежить на гарячому шляху CLI; пакети поза деревом приєднуються за типовим ExternalPack::register_into), захищений еталонним набором відповідності побайтової ідентичності та шлюзами CI для окремого / wasm32.

Підкладка змодельованих можливостей: нові модулі бібліотеки, що живлять наведені вище сценарії та майбутні (ще не окремий kind сценарію):

• DOP місячного поверхневого маяка (src/lunar_beacon.rs) із бюджетом реалізованої точності, перебором N супутників і картою GDOP, а також збурена місячна ефемерида (src/lunar_perturbed.rs) і геометрія безповітряного горизонту / обернена потужність спуфінгу / смуга дефіциту AFS (src/jamming.rs, src/linkbudget.rs). Повторно використовує ядро DOP, перевірене за gnss_lib_py.
• Приймання DEM у форматі LOLA + пряма видимість над рельєфом (src/realdata/lola_dem.rs).
• Триешелонований захист безпеки сигналів: захоплення спуфінгу, перехресна цілісність датчиків і розмір мережі моніторів (src/spoof_capture.rs, src/cross_sensor_integrity.rs, src/monitor_network.rs) з орбітальною зоною променя антени та бюджетом автентифікації OSNMA (src/antenna.rs, src/nma_budget.rs). MODELLED.

Змінено#

• Матрицю валідації та кожен похідний артефакт заново згенеровано з єдиного джерела істини (src/verification.rs): реєстр на сайті, діаграми карти модулів і походження валідації, а рядки лічильників README / за поверхнями тепер читаються 51 / 47 / 4 із 102 (було 40 / 47 / 4 із 91); запобіжник чесності лічильників тепер сканує повну історію git, а рисунки README уніфіковано на темній палітрі бренду.
• Один спільний адаптивний драйвер інтегрування тепер лежить в основі і integrate, і integrate_dopri (src/integrator.rs), усуваючи дубльований крокувальник.
• До CI додано статичний аналіз SonarQube Cloud (Rust + імпортоване покриття) зі значками оцінок безпеки / супроводжуваності / надійності в README.

Уривок, що називає сторонні клієнти ШІ, тут пропущено; він є в CHANGELOG.md на GitHub.

• Дисципліна випуску / пакування: CI реєструє середовище розгортання для кожної публікації пакета/реєстру, а цільове завдання публічного окремого збирання виведено з-під повільних двійкових файлів валідації.
• Запобіжник гігієни «без атрибуції» обмежено лише маркерами авторства, тож згадка хоста інтеграції чи продукту більше не провалює збірку.
• Документація: розділ README Citing тепер перелічує чотири опубліковані препринти arXiv, а можливість DOP поверхневого маяка задокументовано в місячному рядку.

Виправлено#

• Цілочисельні лічильники циклів для циклів, що керуються числами з плаваючою комою (Sonar S2193).
• Точна обернена функція хі-квадрат за малих ступенів свободи через уточнення Ньютона в шляху довірчих інтервалів забезпечення.
• kshana.dev: розділ стандартів тепер відкривається за замовчуванням, а резервну кількість реєстру виправлено; застарілі рядки README / сайту навколо шару спостережуваності синхронізовано.

0.23.0 - 2026-06-29#

Випуск можливостей, що додає загальний шар інформації Фішера / спостережуваності Крамера–Рао та оптимального планування експериментів, і випуск, на якому тримається стаття про спостережуваність місячного PNT. Машинно перевірена матриця валідації зростає до 40 VALIDATED · 47 MODELLED · 4 PARTNER у 91 рядках (було 39 · 46 · 4 у 89): новий рушій оцінювання перевірено за зовнішнім оракулом, і він VALIDATED; його місячне застосування чесно MODELLED. Як і раніше, жодне твердження числової моделі не підвищується без зовнішнього набору даних за ним.

Додано#

• src/fim.rs: інформація Фішера, межі Крамера–Рао та оптимальне планування експериментів. Загальний багаторазовий рушій теорії оцінювання: матриця інформації Фішера M = HᵀWH з якобіана вимірювань і ваг; симетричний розв'язувач власних значень (циклічний Якобі); нижня межа Крамера–Рао через обернену матрицю або псевдообернену Мура–Пенроуза плюс базис нуль-простору, коли інформація має дефіцит рангу (випадок вільної мережі / дефекту датума); а також метрики планування експериментів D-, A-, E- і T-оптимальності із селектором best_design за кандидатними геометріями. VALIDATED проти NumPy (eigh/inv) і опублікованих замкнених меж Kay (1993) до 1e-9 (tests/fim_observability_reference.rs), тож входить до матриці як рядок із зовнішнім оракулом, а не самоперевірка.
• Спостережуваність спільного визначення орбіти для Місяця (lunar_observability у src/lunar_combination.rs, виведена у звіті місячного поєднання): застосовує рушій FIM/CRLB до спільного розв'язання орбіти й годинника, щоб виявити дефект датума абсолютної станції, відновлення її рангу в міру додавання станцій із земної бази, досягнуту CRLB положення станції та E-оптимальну зумовленість. Чесно MODELLED: рушій оцінювання перевірено зовні, але місячна мережа, до якої його застосовано, є репрезентативною симуляцією, і жоден наявний набір даних не може перетворити цю геометрію на вимірювання.
• Репрезентативна геометрія еліптичної місячної замороженої орбіти (ELFO) для сценарію місячного поєднання (orbit_ecc, orbit_inc_deg, orbit_argp_deg, orbit_planes; кругове розміщення залишається типовим) і поле спостережуваності без VLBI у звіті, щоб результат про дефект датума можна було показати як загальний щодо геометрії. Та сама драбина 3→1→0 і поріг у три станції зберігаються на ELFO родини Moonlight/LCNS, а з трьома земними базами VLBI абсолютне положення станції спостережуване з субметровою межею; зафіксовано elfo_geometry_confirms_the_observability_structure. Усе ще MODELLED.

Змінено#

• Матрицю валідації та кожен згенерований артефакт доказів заново згенеровано з єдиного джерела істини (src/verification.rs): реєстр (web/data/verification-matrix.json), docs/VERIFICATION-MATRIX.md, docs/MODELLED-RATIONALE.md, рисунки розбивки валідації та типів оракулів, а рядки лічильників README на всіх поверхнях розповсюдження тепер читаються 40 / 47 / 4 із 91.

0.22.1 - 2026-06-29#

Патч-випуск лише з пакуванням. Жодних змін рушія, сценаріїв чи результатів; матриця валідації без змін: 39 VALIDATED · 46 MODELLED · 4 PARTNER у 89 рядках.

Виправлено#

• Публікація npm: пакет repository.url, виведений з маніфесту крейта, використовував власника GitHub з хибним регістром (AshfordeOU), що провалило перевірку походження sigstore в npm (вона порівнює власника з урахуванням регістру). Маніфест repository тепер має канонічний нижній регістр ashfordeOU, тож згенерований package.json збігається з суб'єктом походження, і випуск npm публікується.

Змінено#

• Збірка колеса закріплює codegen-units = 1, щоб колесо manylinux було побайтово відтворюваним між перезбірками (перевірка відтворюваності перезбіркою та порівнянням).

0.22.0 - 2026-06-29#

Консолідаційний випуск, зосереджений на доказах, походженні та дисципліні розповсюдження. Машинно перевірена матриця валідації зростає до 39 VALIDATED · 46 MODELLED · 4 PARTNER у її 89 рядках (було 15 · 42 · 4 у 61), завдяки перехресній перевірці змодельованих можливостей за незалежними зовнішніми оракулами. Кожен розповсюджуваний артефакт тепер несе криптографічну атестацію походження збірки SLSA, постачається зі SBOM CycloneDX і публікується синхронно на всіх поверхнях. Жодне твердження числової моделі не підвищується без зовнішнього набору даних за ним; нова можливість залишається чесно MODELLED.

Додано#

• Динаміка орієнтації (src/attitude_dynamics.rs, MODELLED) — рівняння Ейлера для вільного від моментів твердого тіла + кінематика кватерніонів (RK4) із самоперевірками законів збереження (норма кватерніона, кінетична енергія, |Iω|, прецесія симетричного дзиґи).
• Перехресна перевірка змодельованих можливостей за незалежними зовнішніми оракулами, що доводить матрицю валідації до 39 рядків VALIDATED, кожен з яких підкріплений зовнішнім набором даних (шлюз чесності CI забороняє статус VALIDATED без нього). Найновіші валідації за зовнішнім оракулом: виміряна крива стабільності оптичного годинника (підгонка кривої ADEV у quantum_trade відтворює опубліковану σ_y(τ) оптичного решіткового годинника ⁸⁸Sr від Norcia et al., Science 366:93 (2019), Zenodo 10.5281/zenodo.3382347, CC-BY-4.0, вбудовану в tests/fixtures/optical_clock_adev/); генерація дальнісного коду GPS L1 C/A (G1/G2 LFSR у src/sdr.rs відтворює вісімкові значення фаз коду з таблиці 3-Ia IS-GPS-200 для PRN 1–9); і зчитувач цифрової висоти SRTM на реальному рельєфі (src/altpnt/terrain.rs зчитує вбудований тайл SRTM v3 NASA/USGS із суспільного надбання, N36W117 / Death Valley, розміщуючи Badwater Basin у межах його задокументованої смуги зйомки).
• Нові можливості MODELLED, кожна внутрішньо перехресно перевірена за замкненою формою або суміжним шляхом коду: відносна динаміка Clohessy–Wiltshire / Hill, пасивна геолокація випромінювача за TDOA/FDOA, визначення орієнтації Wahba/TRIAD/QUEST, розв'язання цілочисельних неоднозначностей фази несівної GNSS (LAMBDA), прицілювання в B-площині та гравітаційний маневр у наближенні зшитих конік, формування діаграми антенних решіток CRPA проти завад, статистики захоплення GNSS із квадратичним законом, неоднозначність смуг / динамічний діапазон квантового інерціального датчика, степеневий шум годинника IEEE-1139 + поріг flicker-FM та обмін блоком коваріації CCSDS-OEM.
• Єдиний реєстр доказів (ledger) як одне джерело зі згенерованою документацією верифікації та захистом від розбіжностей; доступний для перегляду реєстр валідації на kshana.dev із прямими посиланнями на докази в кожній картці.
• Машинозчитувані метадані цитування — codemeta.json (CodeMeta 2,0) і .zenodo.json, прив'язані до маніфесту Cargo тестом tests/citation_metadata_doc_sync.rs.
• Походження ланцюга постачання — атестація походження збірки SLSA для архіву crate, wheels, sdist та архіву npm; PyPI OIDC Trusted Publishing; CycloneDX SBOM, що постачається всередині пакетів wheel і npm; порівняння відтворюваних збірок та перевірка після випуску.
• Знаходжуваність — robots.txt, sitemap.xml та метадані Open Graph / JSON-LD на kshana.dev; згенерована з матриці діаграма validation-breakdown.
• README для кожної поверхні (crates.io / PyPI / npm) із захистом від розбіжностей у лічильниках.

Змінено#

• Оракул передавання часу за Саньяком підвищено до ExternalDataset — поправку Саньяка для екваторіального навколосвітнього обльоту тепер перевірено за опублікованим значенням Ашбі 207,4 нс (Living Reviews in Relativity 6:1, 2003, рівн. 1,29; відтворено з точністю < 0,05 нс). Складена можливість передавання часу чесно залишається MODELLED.
• Документацію, діаграми та рисунки оновлено відповідно до чинної матриці (39/46/4/89): діаграму походження валідації, рисунок oracle-kind-stacked (тепер генерується з матриці із захистом від розбіжностей у CI), VALIDATION/PROVENANCE/CAPABILITY/QUANTUM-MODELS/WHEEL_TAGS, документи з архітектури та навчальні посібники, а також загальну кількість у реєстрі на kshana.dev.
• Вихідне дерево переформатовано закріпленим rustfmt (набір інструментів 1.93.0) — суто стиль, без змін поведінки.
• Синхронне версіонування. Усі поверхні розповсюдження (crate, PyPI, npm, крейт MCP + образ OCI, плагін JetBrains) тепер версіонуються синхронно з рушієм, що забезпечується scripts/check-version-sync.sh у CI.
• Плагін JetBrains переліцензовано на AGPL-3.0-only (опублікована версія 0.1.1 ще вказувала Apache-2.0), і тепер він виводить свою версію для Marketplace з тегу випуску.
• Підвищення надійності — виклики unwrap поза тестовим кодом усунено або обґрунтовано; clippy::unwrap_used застосовується до коду поза тестами.
• kshana.dev: ґрунтовне оновлення за принципом «спершу докази» — домінантний головний блок, діаграми архітектури та рисунки результатів, i18n, згортні та адаптивні розділи реєстру й стандартів.

Виправлено#

• Точні ефемериди SP3 — застосування поправки вузла обертання Землі за IGS під час інтерполяції.
• Зображення в реєстрах — README на PyPI/crates.io/npm використовують абсолютні URL зображень; відносні шляхи до зображень у головному README відображалися як зламані зображення на сторінці PyPI 0.21.0. Захист у CI (tests/surface_readme_image_urls_doc_sync.rs) запобігає повторенню цієї помилки.
• CI — fmt + clippy проходять; припинено збірку з орієнтацією на справжні дані, що ігноруються git.

Тести#

• Коваріація годинника у фільтрі Калмана залишається додатно напівозначеною та симетричною (тест властивостей, tests/property.rs).
• Захисти синхронізації документації: кожен публічний рядок із кількістю валідації, метадані цитування, згенерований рисунок і URL зображень у README поверхонь прив'язані до свого першоджерела.

0.21.0 - 2026-06-26#

Цей випуск додає до відкритого рушія два прикладні набори MODELLED — демонстратор квантового PNT (довірене квантове передавання часу, квантова навігація без GNSS, квантове виявлення збоїв і аномалій) та набір місячного / цисмісячного PNT (місячний координатний час, місячна РНДБ, спільне визначення орбіти й годинника, реалізація системи відліку, область обслуговування, диференціальний PNT, експорт для взаємосумісності) — кожен запускається з одного kind і видає чесний запис TradeEvidence разом із реєстром репрезентативності та прогалин до польоту. Він також додає шість нових валідацій за зовнішніми оракулами, доводячи матрицю валідації з машинною перевіркою до 15 VALIDATED · 42 MODELLED · 4 PARTNER у 61 рядку. Нові прикладні числа є MODELLED за ілюстративними параметрами з публічних джерел — без TRL, льотної історії, сертифікації чи схвалення агентством — а перевірені ядра, які вони повторно використовують, позначено як такі.

Додано#

• Набір демонстраторів квантового PNT (quantum-time-transfer, quantum-gnss-free-nav, quantum-anomaly-detect). Три прикладні напрями MODELLED, що запускаються на рушії, кожен видає TradeEvidence разом із записом про репрезентативність і прогалини до польоту:
  • Довірене квантове передавання часу (src/timetransfer_chain.rs) — бюджет «оптичний решітчастий годинник + фотонний канал» проти CSAC + двостороннього РЧ-каналу, що повторно використовує рівень захисту синхронізації, із показником безпеки щодо атак із затримкою/повторенням (1 − P_md) та виявленням аномалій годинника + затримкою CUSUM.
  • Квантова навігація без GNSS (src/quantum_nav_od.rs) — інерційний вибіг на холодноатомному інтерферометрі проти INS навігаційного класу під час відсутності GNSS; чесно зазначено, що без зовнішнього фіксування зміщення акселерометра залишається неспостережуваним, тож похибка все одно зростає.
  • Квантове виявлення збоїв / аномалій (src/quantum_faults.rs) — розмічений каталог збоїв із ROC AUC та бутстреп-довірчим інтервалом і мінімальним виявлюваним збоєм за фіксованої частоти хибних тривог.
  • Спільна бібліотека моделей похибок квантових пристроїв (src/quantum_devices.rs) та єдиний засіб порівняння квантових і класичних рішень (src/qtrade.rs) лежать в основі всіх трьох.
• Набір місячного / цисмісячного PNT. Сім запусковних kind MODELLED, що надбудовані над ядром CR3BP: місячний координатний час (світський хід LTC/TCL − TT, src/lunar_time.rs), геодезична спостережувана затримки місячної РНДБ (src/lunar_vlbi.rs), пакетний оцінювач спільного багатотехнологічного визначення орбіти + годинника (src/lunar_combination.rs), реалізація системи відліку (7-параметрова трансформація Гельмерта + прив'язка IAU 2015 WGCCRE, src/lunar_frame_realise.rs), аналіз області обслуговування класу Moonlight / LCNS (src/lunar_service.rs), місячний диференціальний PNT (src/lunar_dpnt.rs) та експорт взаємосумісності за LunaNet / IOAG (CCSDS-OEM + місячна шкала часу в оболонці KIF, src/lunar_interop.rs). Усе MODELLED за ілюстративними параметрами з публічних джерел; не перевірено за реальним відстеженням РНДБ / Gateway; жодної афіліації чи схвалення агентством.
• Шість нових валідацій за зовнішніми оракулами (матриця валідації тепер містить 15 перевірених):
  • ADEV / HDEV на реальному цезієвому годиннику 5071A — перевірено за опорними значеннями Stable32 у десяткових точках (tests/cs5071a_reference.rs).
  • OADEV / MDEV / TDEV за еталоном Stable32 PHASE.DAT — перевірено за опублікованими таблицями Stable32 (tests/phasedat_reference.rs).
  • ROC AUC виявлення аномалій на реальній телеметрії ESA OPS-SAT — перевірено за scikit-learn (tests/opssat_ad_reference.rs).
  • Синтез функціоналів гравітації ICGEM — перевірено за стандартом нормальної сили тяжіння GRS80 (γ Сом'ільяни з точністю до 3.5e-12; карта збурень EGM2008, tests/icgem_gravity_reference.rs).
  • Модель іоносфери Klobuchar з ефемеридного повідомлення — перевірено за RTKLIB (tests/klobuchar_reference.rs).
  • Ядро виявлення RAIM (171 випадок, tests/raim_reference.rs) та рівень захисту SBAS DO-229E на реальних даних EGNOS (форк RTKLIB SBAS-PL, tests/sbas_reference.rs) — обидва перевірено за своїми зовнішніми оракулами.
• Реєстр репрезентативності та прогалин до польоту (src/representativeness.rs). Структурований запис, який видає кожен демонстратор: що є репрезентативним, що спрощено і що відокремлює модель від польоту — чесний супутник кожного рішення MODELLED.
• Агрегація досліджень і зручність CLI. Маніфест набору сценаріїв з агрегацією дослідження однією командою, стабільні за хешем метадані дослідження + --study-name, лінтинг сценаріїв за допомогою --validate та відображення рівня валідації для кожного показника якості у звітах досліджень.

Змінено#

• kshana.dev перероблено навколо спільного предметного каркаса — можливості та валідацію об'єднано в один предметний провідник зі спільною термінологією, виведено нові перевірені ділянки, додано анімований інструмент Землі з точним контуром суші та заклик до дії «замовити дослідження», а також брендинг і посилання Ashforde OÜ.
• README + ARCHITECTURE перевірено на повноту та чесність — виправлено застарілі кількості перевірених (тепер 15 зовнішніх оракулів), розширено діаграми, а також процитовано препринти про умовний рівень захисту синхронізації (arXiv:2606,24210) та розрив оптимізму через РЧ-спотворення (arXiv:2606,22054).
• Джерела paper/ і конвеєр чернетки JOSS зберігаються в публічному репозиторії.

0.20.0 - 2026-06-22#

Цей випуск додає до відкритого рушія чотири можливості досліджень — умовний рівень захисту синхронізації, оцінювання стійкості PNT за узгодженою рамкою, оцінювання розриву оптимізму через РЧ-спотворення та програмно-визначений приймач / вхідний каскад для реальних даних — кожну можна відтворити однією командою, і вона записує побайтово детермінований артефакт. Усі дослідження MODELLED (синтетичне або публічне калібрування за набором даних), містять чесне походження (версія рушія, зерна (seed), хеш конфігурації) та мітки валідації, і не є сертифікаціями.

Додано#

• Умовний рівень захисту синхронізації (tpl). Обмежена holdover межа недетектованої похибки часу за спуфінгу GNSS із нижньою межею монітора k-сигма, дисперсією вибігу за ван Лоаном упродовж затримки виявлення та часом до тривоги за CUSUM. Відкалібровано на реальній записаній атаці (JammerTest 2024, сценарій 2.1.1) за допомогою cargo run --release --example tpl_jammertest, що відтворює її опорну таблицю зі скалярів, відновлених із публічного запису (сирий набір даних не розповсюджується).
• Оцінювання стійкості PNT за узгодженою рамкою + дослідження нестабільності рішень (resilience). Модель архітектури, оцінювання за RPCF, симплекс вагових коефіцієнтів Діріхле, нестабільність за тау Кендалла та частотою перевороту top-1, а також колапс різноманітності спільного режиму (Hill-N2), із cargo run --release --example resilience_report -- paper-artifacts/resilience-study.json. Зіставлення — у docs/RESILIENCE-CROSSWALK.md.
• Дослідження розриву оптимізму через РЧ-спотворення (impairment_study, impairment_ml, eval_stats). Панель із 13 детекторів на синтетичному корпусі з обґрунтованими параметрами, розрив оптимізму між розподілом навчання і поза ним, тренди законів масштабування з перестановочним нульовим розподілом та предиктор деградації за принципом «виключення одного», через cargo run --release --example optimism_study -- paper-artifacts/optimism-study.json.
• Вхідний каскад програмно-визначеного приймача (sdr) та адаптери реальних даних (realdata/). Від сирих IQ/IF до відводів корелятора та SQM, а також адаптери завантаження (RINEX, u-blox UBX, GnssLogger, JammerTest, Yunnan, SatGrid) і приклади зондування. Вони читають записи, які користувач надає локально; жодні записи не додаються до репозиторію.
• Зафіксовані артефакти досліджень. Побайтово детерміновані optimism-study.json і resilience-study.json тепер відстежуються в paper-artifacts/, щоб числа досліджень можна було перевірити без перезбирання; їх і далі можна відтворити зі згаданих вище генераторів. Сирі набори даних залишаються поза репозиторієм (/realdata-cache/).

Змінено#

• Версію піднято до 0.20.0 у Cargo.toml, CITATION.cff і README; артефакти дослідження перетину перегенеровано, щоб їхня позначка відповідала випущеній версії.

0.19.0 - 2026-06-18#

Змінено#

• Переліцензовано з Apache-2.0 на GNU AGPL-3.0-only, із комерційною ліцензією від Ashforde OÜ (подвійне ліцензування). Відкритий рушій залишається повністю відкритим і публічно перевірюваним; мережевий копілефт AGPL (§13) означає, що закрита або хмарна похідна версія має повернутися у відкритий код — або отримати комерційну ліцензію. Це захищає перевірене ядро від форку із закриттям, зберігаючи довіру до публічного, запусковного й придатного до аудиту рушія. Див. LICENSE (AGPL) та новий LICENSING.md (що охоплює кожна ліцензія і коли вона застосовується).
  • LICENSE тепер містить текст AGPL-3.0; заголовки SPDX в усіх джерелах оновлено до AGPL-3.0-only; NOTICE, README, GOVERNANCE, GLOSSARY, вебсайт та метадані крейтів/пакетів (Cargo.toml, pyproject.toml, CITATION.cff, крейт MCP + образ) відповідно оновлено.
  • Умови для контриб'юторів (CONTRIBUTING.md) тепер ліцензують вхідні внески за AGPL і надають Ashforde OÜ право включати внески до комерційно ліцензованого видання, щоб подвійне ліцензування продовжувало працювати.
  • Політика залежностей не змінилася, але обґрунтована заново (deny.toml, GOVERNANCE): залежності залишаються з дозвільними ліцензіями (Apache/MIT/BSD/ISC). AGPL дозволено лише для власного крейта kshana — копілефтна залежність заразила б комерційне видання і зламала б подвійне ліцензування.
  • Примітка для downstream: це копілефтне переліцензування. Користувачі, які покладалися на дозвільні умови Apache-2.0, можуть і далі користуватися останнім випуском під Apache-2.0 (v0.18.0 і раніші, як опубліковано); починаючи з v0.19.0 діє AGPL-3.0 / комерційна ліцензія.

Безпека#

• Оновлено pyo3 з 0,24 до 0,29, щоб усунути RUSTSEC-2026-0176 / RUSTSEC-2026-0177 (GHSA-36hh-v3qg-5jq4 / GHSA-chgr-c6px-7xpp) у зовнішніх сканах OSV/залежностей. Обидва є бюлетенями рівня функцій, чиї уражені функції (BoundList/TupleIterator::nth/nth_back, PyCFunction::new_closure) Kshana ніколи не викликає, а pyo3 є необов'язковою залежністю (функція python), тож реальний вплив був нульовим, але оновлення зберігає чистий скан для аудиторів нижчого рівня. src/python.rs перенесено на API pyo3 0,29 (тип, що повертається, Bound для scenario_kinds; явний skip_from_py_object для pyclass RunOutput). Усі 11 тестів прив'язок Python проходять на перезібраному розширенні.

0.18.0 - 2026-06-17#

Додано#

• Одинадцять нових запусковних видів сценаріїв — демонстратори двох тендерів, міст сумісності CCSDS і набір першого наближення для аналізу місії та середовища (усі MODELLED, адитивні; наявні еталони відтворюваності не змінено). Кожен можна запустити через CLI / Python / WASM / MCP, він постачається з scenarios/<kind>.toml і несе явну мітку MODELLED у своєму JSON результату та однорядковому підсумку (тест для кожного виду в tests/dominance_demonstrators.rs перевіряє, що мітка присутня і що вихідні дані ніколи не містять рядка VALIDATED):

  • impairment-eval (src/impairment_eval.rs) — випробувальний стенд оцінювання виявлення РЧ-спотворень методами машинного навчання: розмічений синтетичний корпус + незалежний від детектора комплекс ROC/AUC + звіт про розрив оптимізму між розподілом навчання і поза ним (лише робочі характеристики — ніколи польові дані/IQ).
  • quantum-trade (src/quantum_trade.rs) — порівняння квантових і класичних рішень PNT із завантаженням виміряної ADEV та оболонкою стійкості за відсутності GNSS.
  • space-weather (src/space_weather.rs) — сонячні/геомагнітні індекси (таблиця IAGA Kp↔ap, добовий Ap, центрований 81-добовий F10.7a), екзосферна температура Jacchia-71 та пов'язування густини термосфери, керованої активністю, над статичною атмосферою (НЕ модель абсолютної густини NRLMSISE).
  • oem-interop (src/oem.rs) — імпорт CCSDS 502,0 OEM + міст двостороннього перетворення для ефемерид GMAT / Orekit / STK (зчитувач parse_oem, точна обернена операція до записувача).
  • launch-window (src/launch.rs) — азимут запуску у двотільній задачі (sin Az = cos i/cos lat), Δv зміни площини, виграш від обертання майданчика та геометрія щодобових можливостей.
  • reentry (src/reentry.rs) — балістичний коридор повернення в атмосферу за Алленом–Еггерсом: пікове гальмування, швидкості піка перевантаження та піка нагрівання, висота піка перевантаження.
  • eo-coverage (src/eo_payload.rs) — геометрія смуги огляду / GSD / доступу / повторного проходу для EO (космічний трикутник SMAD).
  • space-packet (src/space_packet.rs) — кодування/декодування первинного заголовка космічного пакета CCSDS 133.0-B із побітно точним двостороннім перетворенням.
  • attitude-budget (src/attitude_budget.rs) — 3-DOF гравітаційно-градієнтний момент + бюджет похибки наведення за RSS (скалярний бюджет до появи апаратури, а не контур керування).
  • passes (src/passes.rs) — передбачення проходів зі сходом/заходом для наземної станції (AOS/TCA/LOS, максимальний кут місця, доступ).
  • link-budget (src/linkbudget.rs) — односторонє рівняння лінії зв'язку CCSDS-401 / DSN-810-005 (C/N₀ = EIRP − FSPL − L_other + G/T − k, FSPL / Eb·N₀ / запас / замикання).

• 17-станний гібридний квантово-класичний тісно зв'язаний UKF — подано як запусковний сценарій (MODELLED). Новий вид сценарію hybrid-ukf (src/fusion/hybrid_ukf.rs, scenarios/hybrid-ukf.toml), що перетворює раніше доступний лише через API 17-станний тісно зв'язаний GNSS/INS несцентований фільтр (src/fusion/tightly_coupled17.rs) на сценарій, який можуть запускати прив'язки CLI/Python/WASM/MCP. 17-станний вектор похибок складається з 15 станів похибки INS (позиція, швидкість, неспіввісність орієнтації, зміщення акселерометрів і гіроскопів), доповнених поправкою зміщення акселерометра, виведеною за CAI — холодноатомний інтерферометр (src/inertial/quantum_imu.rs) задає нижню межу випадкового блукання швидкості q_va, тож довготривалий дрейф вибігу визначається обмеженнями квантового датчика — і 2-станним годинником із фазою та частотою, шум процесу якого береться з рушія q-параметрів годинника (clock_state::q_from_allan, що відображає профіль девіації Аллана годинника на PSD q_wf/q_rw, масштабовані до одиниць дальності). Платформа спершу працює за допомогою GNSS (фільтр вивчає зміщення, швидкість і годинник), а потім виконує вибіг крізь відсутність GNSS лише на IMU CAI і годиннику, тож запуск демонструє гібридизацію класичного IMU на короткому проміжку + квантового на довгому. Показник якості — самоузгодженість фільтра: об'єднані NEES (нормована квадратична похибка оцінювання, за підмножиною оцінюваних позиції/швидкості/годинника) та NIS білості інновацій (нормований квадрат інновації) за ансамблем Монте-Карло, що перевіряються за їхніми 95% смугами χ² (Бар-Шалом §5,4). Узгоджений фільтр потрапляє в смуги; навмисно розлаштований фільтр (параметри q_factor / r_factor) позначається — об'єктивно перевіряється, розрізняльний критерій, а не формальна печатка. Перевірка NEES/білості інновацій є СТАТИСТИЧНИМ ОРАКУЛОМ: це твердження про самоузгодженість (заявлена фільтром коваріація чесно відповідає розкиду його власних похибок за модельованого шуму), а НЕ гарантія точності в реальному світі. Чесні межі: усе є модельованим / симуляцією — входи CAI і годинника є діапазонними значеннями, репрезентативними для літератури, а не виміряною апаратурою; апаратура CAI та її ключова особа залишаються на стороні партнера; ніщо тут не означає TRL > 3, льотної історії чи зовнішньої валідації (JSON результату та однорядковий підсумок несуть ці мітки явно). Єдина траєкторія з постійною швидкістю та рівним польотом лише слабко робить спостережуваними стани орієнтації та зміщення IMU, тому NEES оцінюється за 8 оцінюваними станами; маневрова траєкторія для повної спостережуваності 17 станів — у плані розвитку. Також додає інструментарій узгодженості Ukf::update_stats (повертає NIS для кожного оновлення) та TightlyCoupled17::{update_gnss_nis, nees, nees_subset}. Усі наявні сценарії не зачеплено (адитивно; еталони відтворюваності не змінено).

• Послідовна (рекурсивна) навігація за рельєфом — SITAN як фільтр, що працює безперервно. Новий вид сценарію terrain-slam (src/altpnt/sequential.rs, scenarios/terrain-slam.toml), що проганяє наявну модель вимірювання «альтиметр проти DEM» епоха за епохою через рушій SIR particle_filter, а не через пакетний пошук від грубого до точного, який terrain-nav використовує для відновлення єдиного сталого зміщення INS. У кожній точці маршруту хмара поширюється на приріст, повідомлений INS (який сам спотворений зростанням дрейфу на кроці), перезважується за збігом із рельєфом і передискретизується у разі виродження — тож змінний у часі дрейф INS відстежується вздовж треку, чого фіт зі сталим зміщенням структурно не може. На синтетичній DEM рекурсивна оцінка залишається обмеженою і повторно сходиться (кінцева ≈ 70 м), тоді як інерційний розв'язок без допомоги необмежено розходиться до ≈ 5 км; похибка на епоху залежить від виразності рельєфу (на пласких сідловинах вона вибігає на зміщеній INS, а на виразному рельєфі знову захоплюється), а монітор ефективного розміру вибірки підтверджує здорову хмару. Чесні межі: карта відома й фіксована — рекурсивна локалізація за збереженою DEM (половина локалізації в SLAM за рельєфом), а не спільне оцінювання карти; за побудовою не циклічна (введена рампа дрейфу є незалежною істиною). Усі наявні сценарії не зачеплено (адитивно; еталони відтворюваності не змінено).

• Хребет стійкості за відсутності GNSS + зрізи демонстратора FutureNAV (src/holdover.rs та основи оболонки стійкості в src/impairment_eval.rs, src/quantum_trade.rs, src/navsignal.rs, src/inertial/quantum_imu.rs, зі зрізами верифікації FutureNAV у src/verification.rs). Поєднує будівельні блоки альтернативного PNT — holdover годинника, супроводження сигналу, інерційний вибіг, рельєф — в єдиний наратив стійкості до відсутності GNSS. MODELLED; адитивно.

• Kshana Interchange Format (KIF) — версійована самоописова оболонка артефакту (src/interchange.rs). Обгортка результатів сценарію з тегом схеми, щоб збережений артефакт ніс із собою свій вид, версію схеми та мітки MODELLED/VALIDATED, а старіші оболонки залишалися читабельними з прямою сумісністю. Адитивно; наявний JSON результату не змінено.

• Модуляція / супроводження навігаційного сигналу + диференціальний коректор гало/NRHO у CR3BP (src/navsignal.rs, src/cr3bp.rs). Модель модуляції та супроводження навігаційного сигналу першого наближення і диференціальний коректор обмеженої круговою задачі трьох тіл для гало та майже прямолінійних гало-орбіт, виведені на наявну вісь можливостей для далекого космосу. MODELLED.

• Режим оцінювання зсуву розподілу + регулятор шкали серйозності корпусу для impairment-eval (src/impairment_eval.rs). Додає явний поділ на розподіл навчання й поза ним та настроювану шкалу серйозності корпусу до комплексу розриву оптимізму ROC/AUC (лише робочі характеристики — ніколи польові дані/IQ).

• ROI «вартість на покриття» + відображення цілісності від пропущеного виявлення (src/frugal.rs, src/integrity_impact.rs). Економна інженерна лінза ROI (вартість на одиницю покриття) та відображення частоти пропущених виявлень на вплив на цілісність. MODELLED; адитивно.

• Цитований аркуш параметрів моделі похибок холодноатомного інтерферометра (CAI) (src/inertial/quantum_imu.rs). Аркуш параметрів із діапазонами та посиланнями на літературу для інерційної моделі CAI — вхідні дані цитовані, а не виміряна апаратура (без тверджень про TRL чи льотну історію); він живить нижню межу випадкового блукання швидкості hybrid-ukf.

• Управління проєктом. GOVERNANCE.md, що описує модель ухвалення рішень і межу між відкритим і закритим; рядок спільноти/управління в карті можливостей змінюється none → partial, щоб це відобразити.

Виправлено#

• Рівень захисту цілісності ARAIM — тепер застосовано номінальне зміщення (b_nom) і σ_URA. Рівень захисту MHSS тепер віднімає односторонню проєкцію номінального зміщення b_k = Σ_i |s_i|·b_nom для кожного режиму збою та використовує сигму цілісності σ_URA (відмінну від сигми точності σ_URE), що передається в повідомленні підтримки цілісності (Integrity Support Message). Це робить рівень захисту консервативнішим і коректнішим за стандартами, а отже змінює значення PL, які повідомляють наявні сценарії цілісності. ISM/сценарій отримує поля #[serde(default)] sigma_ura_m / b_nom_m, тож входи, що залишають їх незаданими, зберігають попередню поведінку. Відновлену формулу b_k і чесну примітку щодо реалізації див. у docs/ARAIM_REFERENCE.md.

• Узгодженість χ² монітора спуфінгу. parity_raim_test тепер використовує спільний шлях обернено-χ² raim::chi2_quantile, усуваючи другу розбіжну реалізацію χ², тож RAIM і монітор паритету спуфінгу погоджуються щодо своїх порогів.

• gravity-map-nav підключено до диспетчера CLI. Раніше сценарій був доступний лише через API; тепер він запускається як kind=, як і кожен інший сценарій.

• Документація/точність підрахунків. Кількість видів сценаріїв у README тепер зафіксовано за api::list_scenario_kinds().len() тестом scenario_count_doc_sync, тож задокументована кількість більше не може розходитися з диспетчером.

0.17.0 - 2026-06-14#

Додано#

• PNT для далекого космосу та Марса — відкритий рушій радіометричної навігації та симуляція GSE. Нова, суто додаткова вісь можливостей поверх ядра, перевіреного для Землі (кожен наявний земний сценарій побітово ідентичний: еталонні результати відтворюваності проходять без змін і без регенерації). Додано: ядро багатотільної динаміки (Body{mu, re, zonals, gravity, rotation, IAU-pole} із тесеральною гравітацією Марса GMM-3, пов'язаною з тілом марсіанською системою IAU, підключуваним інтерфейсом EphemerisProvider, двочастинними юліанськими датами з точністю нижче мікросекунди та TT↔TDB); радіометричні спостережувані (ітераційний час світла і затримка Шапіро, дво-/одно-/триканальний Доплер і далекометрія через двоплечове розв'язання Мойєра, когерентне перевипромінювання транспондера, регенеративна/PN-далекометрія за CCSDS 414, Δ-DOR за CCSDS 506, середовища сонячної плазми/тропосфери/іоносфери); розбір і формування CCSDS-TDM (503); редукований динамічний кореневий інформаційний фільтр з емпіричними прискореннями RTN, тристановим бортовим годинником і моделлю марсіанського опору; спільний оцінювач, що поєднує односторонні та двосторонні виміри; поверхня сценаріїв mars-pnt (релейне угруповання + LMO/перехід/поверхня) у CLI, Python, WASM, MCP та playground; а також наскрізний симулятор продуктивності GSE (геометрія → бюджет лінії → спостережувані → SRIF → коваріація). Рівень перевірки — підтверджено симуляцією: синтетичне замкнене визначення орбіти (Mars-LMO ≈ 0,2 м) і аналітична самоузгодженість, при цьому марсіанську динаміку із Сонцем у центрі незалежно звірено з JPL DE440 (xval/anise-mars-od, залежить від ядра: 137 м на дузі в 1 добу, чесний залишок неврахованої багатотільної взаємодії). Наведені точності для далекого космосу є показниками якості, отриманими симуляцією та коваріацією, а не результатами реальної місії; перевірка за реальними даними стеження DSN/ESTRACK залишається в дорожній карті. ANISE (MPL-2.0, edition-2024) обмежено крейтом перехресної перевірки, виключеним із робочого простору, тому ліцензійний бар'єр cargo deny і завдання MSRV-1.75 не зачеплено.
• Траси на поверхні з точністю агентств за реальною орієнтацією Землі IERS. Сценарій ephemeris приймає необов'язкове поле eop_finals2000a — вбудований вміст реального файла IERS finals2000A — і зводить трасу через покрокові UT1−UTC та рух полюса, інтерпольовані з нього (той самий EopSeries, що використовує precise_od), перекриваючи номінальні скаляри dut1_s/xp_arcsec/yp_arcsec. Дані подорожують разом зі сценарієм, тож прогін залишається відтворюваним і не потребує файлової системи (працює в playground на WASM). Прапорець kshana --eop <finals2000A> вбудовує реальний файл у сценарій із CLI. Усуває асиметрію, коли лише precise_od використовував реальні дані орієнтації Землі.

Виправлено#

• Узгодженість систем відліку для швидкості зміни дальності. Наземну станцію тепер переносять в інерціальну систему точною оберненою до редукції супутника (frames::itrf_to_teme, що скасовує рух полюса і зоряне обертання), а не обертанням GMST, сліпим до руху полюса, тож обидва кінці мають одну систему відліку. Вплив на заявлений Доплер нижчий за поріг перевірки, але усунено справжню невідповідність систем відліку та надмірне твердження «точно» в коді.
• Перевіряється carrier_hz. Нульова або нескінченна чи нечислова несуча частота тепер повертає помилку замість мовчазного отримання нульового Доплера (через неї λ = c/несуча ставала нескінченною), що відповідає наявній перевірці step_s.

0.16.0 - 2026-06-11#

Додано#

• Перевірка силової моделі підгонкою ефемерид, перехресно звіреною з реальними продуктами агентств. Новий пакетний оцінювач найменших квадратів (src/precise_od.rs) із варіаційною матрицею переходу стану та редагуванням викидів, керований повною силовою моделлю (PreciseForceModel: геопотенціал EGM2008, треті тіла, твердий + океанічний + атмосферний припливи та емпіричні прискорення CPR/2-на-оберт), що живиться від реального парсера орієнтації Землі IERS finals2000A. Звірено з опублікованими еталонними орбітами: Galileo MEO до 13 см після підгонки, ESA Swarm-A LEO та LRO місячна (селеноцентрична, гравітація GRAIL, система тіла IAU-2015 — редукована динаміка 6,6 м, чесно вище цілі 5 м на відкритому шляху; шлях класу DE із ANISE/DE440, що її досягає, — це крейт, виключений із робочого простору).
• Сценарій spoof-detect — інтегрований багатошаровий детектор спуфінгу, що поєднує покрокову паритетну перевірку RAIM, монітори AGC і якості сигналу (SQM) та злите рішення, звірений з опублікованими параметрами сценарію TEXBAT (Humphreys et al., ION GNSS 2012), зокрема зі складним випадком із вирівняною несівною.
• Сценарій ephemeris — стан, системи відліку, траса на поверхні та Доплер. Поширює один супутник (TLE→SGP4 або аналітична орбіта) і на кожному кроці видає інерціальний стан TEME і GCRS (положення і швидкість), положення ITRF/ECEF у земній системі, трасу на поверхні підсупутникової точки у WGS-84 (широта / довгота / висота), а також топоцентричні азимут / висоту над горизонтом / дальність зі швидкістю зміни дальності та Доплером від наземної станції. Доступний із CLI, Python, WASM і сервера MCP та постачається як пресет «Ground track» у веб-playground, де трасу накреслено на реальній карті світу (берегові лінії Natural Earth 1:110m, вбудовані — без мережі чи зовнішніх залежностей).
• Експорт CCSDS OEM (--export-oem / export_oem = true) — Orbit Ephemeris Message зі швидкістю, який споживають GMAT / Orekit / STK, нарівні з наявними експортерами SP3 і OMM.
• Твердий, океанічний (FES2004) та атмосферний (Ray 2001 S2) припливи Землі на геопотенціалі (IERS Conventions, розд. 6), підключені до силової моделі.
• Колеса ARM64 — збірка PyPI тепер також створює колеса Linux aarch64 (manylinux_2_28), macOS arm64 та Windows arm64.
• Розширений технічний звіт (препринт) із посиланням у README, а стаття JOSS підготовлена до подання (ORCID автора, компіляція в PDF у CI за кожної зміни).

Змінено#

• Системи відліку звірено з точністю до міліметра з опублікованими векторами Vallado. Редукцію TEME→PEF/ITRF, повний ланцюг CIO IAU 2006/2000A GCRS→ITRS і перетворення ECEF→геодезичні WGS-84 тепер зафіксовано за прикладом із Vallado et al. (AIAA 2006-6753) з його IERS EOP, а не лише за внутрішньою самоузгодженістю.
• Незалежні перехресні перевірки шкал часу. ERA і шкали UTC/TAI/TT збігаються з hifitime до < 1 мкс, а планетні ефемериди DE440 збігаються з JPL Horizons (геоцентричні положення Місяця/Сонця), обидві перевірки — постійно ввімкнені бар'єри CI.
• Веб-playground ховає вкладку показників якості, коли результат не містить рядків показників, тож пакети лише з діаграмою (ефемериди, RAIM, спуфінг) відкриваються на своїй діаграмі — для ефемерид це траса на поверхні — замість порожньої таблиці.
• Керовані повзунки playground і перебір параметра тепер працюють для сценарію ефемерид / траси на поверхні: його регулятори (широта / довгота станції, крок часу, тривалість, UT1−UTC) можна налаштовувати, а перебір може будувати геометрію проходу (максимальна висота, піковий Доплер, висота, швидкість) залежно від будь-якого з них — наприклад, максимальна висота залежно від широти станції. Вкладка Sweep тепер показується лише тоді, коли сценарій справді піддається перебору, тож жоден пакет не пропонує елемент керування, що нічого не будує.
• Задокументовано наближення SGP4 DUT1 ≈ 0 у місці виклику GMST (похибка обертання ≤ ~13″, цілком у межах власної похибки моделі SGP4) і оновлено CAPABILITY.md.

0.15.1 - 2026-06-09#

Додано#

• Плагін JetBrains Kshana — PNT simulator тепер опубліковано й схвалено на JetBrains Marketplace. README, kshana.dev і документація з поширення посилаються на нього напряму.

Виправлено#

• Публікація в реєстрі MCP тепер успішна: server.json description перевищував ліміт реєстру в 100 символів (HTTP 422). Його скорочено, а назву сервера (і мітку власника образу) приведено до канонічного простору імен io.github.ashfordeOU/kshana-mcp.
• Публікація на JetBrains Marketplace тепер успішна: CI повторно завантажував ту саму версію плагіна, яку було внесено вручну, а Marketplace таке відхиляє. Версію плагіна піднято до 0.1.1, а захист від повторів тепер також трактує відповідь «already contains version» як успішну відсутність дії.
• Скидання кешу kshana.dev: рядки запитів style.css/app.js з позначкою версії відстежують випуск, тож відвідувачі, що повертаються, завжди отримують актуальну збірку.

0.15.0 - 2026-06-08#

Додано#

• kshana-mcp — Kshana як сервер Model Context Protocol (MCP) (mcp/kshana-mcp/). Окремий крейт, виключений із робочого простору (SDK rmcp має edition 2024), що надає перевірений рушій ШІ-агентам та асистентам — Cursor, JetBrains AI Assistant / Junie і будь-якому клієнту MCP — через stdio. Інструменти: run_scenario, list_scenario_kinds, validate_scenario, export_sp3, export_omm, кожен — тонка обгортка над kshana::api.
• Плагін для JetBrains IDE (ide/jetbrains/). Клацніть правою кнопкою на сценарії .toml → Run Kshana Scenario; показники якості та JSON результату надходять потоком у вікно інструмента Kshana. Суто платформний плагін на Kotlin, сумісний з усіма JetBrains IDE 2024,3+.
• Публічне поширення + автопублікація з кожним випуском для обох:
  • kshana-mcp на crates.io (cargo install kshana-mcp) через publish.yml.
  • kshana-mcp як багатоархітектурний образ OCI на ghcr.io (docker run ghcr.io/ashfordeou/kshana-mcp) через новий mcp-publish.yml.
  • kshana-mcp в офіційний реєстр MCP через GitHub OIDC (жодних секретів); запис реєстру (server.json) використовує тип пакета OCI з власником, підтвердженим міткою.
  • плагін IDE на JetBrains Marketplace через publishPlugin (за токеном, необов'язковий підпис розробника) для кожного тегу випуску.

0.14.1 - 2026-06-08#

Додано#

• Незалежна перехресна перевірка систем відліку за ANISE/SPICE (xval/anise-frames/). Окремий крейт, виключений із робочого простору, звіряє редукцію CIO IAU 2006/2000A у kshana (kshana::cio::gcrs_to_itrs_matrix, GCRS→ITRS) з ANISE (чисто Rust-реалізація NAIF/SPICE), що обертає GCRF→ITRF93 за earth_latest_high_prec.bpc від JPL, причому ті самі параметри орієнтації Землі IERS finals2000A подано з обох боків, на вісьмох щоквартальних епохах 2020–2023. Дві незалежні реалізації системи відліку збігаються з максимальним відносним обертанням 0,028″ — ≤ 0,86 м на поверхні, ≤ 0,93 м на LEO, ≤ 3,6 м на орбіті GNSS, що з великим запасом задовольняє давню перехресну перевірку систем відліку з ROADMAP «< 10 м» (вона доповнює, а не замінює наявні побітові опори SOFA/ERFA). Крейт ізольовано, бо anise + hifitime мають ліцензію MPL-2.0 / edition-2024 і ніколи не повинні потрапляти в граф залежностей опублікованого kshana, його Cargo.lock, ліцензійний бар'єр cargo deny чи збірку MSRV; ANISE зафіксовано з default-features = false. Містить бінарник frame-xval (завантажує BPC розміром ~5 МБ, друкує таблицю, записує report.{json,md}), тестовий бар'єр, що сам пропускається за відсутності ядра/мережі, та необов'язкове завдання CI лише через workflow_dispatch (ніколи не блокує main). Задокументовано в docs/VALIDATION.md (рядок CIO) та ROADMAP.md.

Виправлено#

• Playground, зручний для мобільних. Виправлено горизонтальне переповнення .panel playground на телефонах (елемент CSS-сітки з типовим min-width: auto виходив приблизно на 100 px ширше за область перегляду) через min-width: 0 та елементи керування із захистом ширини; перевірено без вад на 360 / 390 / 414 / 768 px. Вирівняно кнопки дій «Pin to compare» / «Download report» (однакові поля в гнучкому рядку). Збільшено кнопки запуску, повзунки, списки вибору та навігаційні посилання до мінімального розміру цілі дотику ~44 px за WCAG 2.5.5 / Apple-HIG на телефонах і сенсорних пристроях, розміри на настільних комп'ютерах не змінено.

0.14.0 - 2026-06-08#

Виправлено#

• Підвищення надійності за підсумками змагального стрес-тесту. (1) sbas_protection_level тепер відхиляє нескінченні чи нечислові висоту над горизонтом/азимут/дисперсію та від'ємні чи нечислові діагоналі коваріації (майже вироджена геометрія, збільшена малою σ, раніше могла проскочити крізь бар'єр абсолютного півота й повернути NaN VPL / абсурдний HPL як дійсний Some — тихий збій цілісності). (2) Числовий propagator (propagate/propagate_dopri) закривається безпечно на нескінченному початковому стані замість того, щоб вічно крутити адаптивний контролер. (3) Допоміжна функція комірки DEM більше не панікує на сітці з одним відліком (1×N). (4) Азимут lunar_look_angle тримається строго в [0, 360). (5) SphericalHarmonicField::from_gfc відхиляє нефізичні (NaN / недодатні) GM/радіус.

Додано#

• Бінарник validation_report + артефакт випуску: генератор без залежностей, що видає одну друковану HTML-сторінку з підсумком перевірки, яка індексує кожну перевірку, що забезпечується CI (SGP4 666/666, EGM2008, побітові системи відліку, NIST Allan, datasheet IMU, ARAIM/SBAS, відтворюваність на 3 ОС, покриття), до її тесту та зовнішнього оракула. Робочий процес випуску генерує kshana-validation-summary.html і додає його (із походженням SLSA) до кожного позначеного випуску.
• pytest сумісності з numpy + посилення збірки коліс: tests/python/test_numpy_interop.py (запускається в CI) плюс зафіксований контейнер manylinux і крок перевірки auditwheel show у збірці коліс.
• Навчальні посібники та освіта: docs/tutorials/ (три розібрані посібники, анотовані сценарії за галузями, вправи рівнів 1/2/3) із tests/tutorials.rs, що фіксує кожне наведене число за живим виводом рушія.
• Артефакти зовнішнього подання (paper/, notebooks/, submissions/): чернетка статті JOSS, зошит «квантове проти класичного» та готові до подання набори для awesome-gnss / ESA Navipedia / NASA ASCL / ESA ESSR / ION/IAC, а також FUNDING.yml — підготовка зовнішніх кроків подання.
• Навігація alt-PNT за рельєфом і комбінована (модуль altpnt): навігатор зіставлення рельєфу TERCOM/SITAN за DEM (завантажувач .hgt + генератор синтетичних фікстур) і комбінований навігатор без GPS на основі гравітації + магнітного поля (IGRF) + рельєфу, доступні як види сценаріїв terrain-nav і combined-altpnt. Перевірено збіжністю зіставлення рельєфу (відновлено відоме внесене зміщення) та обмеженою похибкою комбінованого фільтра на проміжку без GPS.
• Геометрія LunaNet LANS (lunar): іменовані місячні поверхневі майданчики (Apollo 11/15/16, край Shackleton) з авторитетними селенографічними координатами, поверхневі кути огляду (аз/висота/дальність), видимість/покриття та DOP майданчика, звірені з радіусом Місяця, опублікованими координатами майданчиків і тотожністю висоти 90° для радіального зеніту.
• Кероване браузерне playground: повзунки керованого режиму, вихідна панель із вкладками, накладка туру першого запуску, режими перебору параметра та накладання кількох прогонів, 3D-вид орбіти на canvas/SVG без залежностей (пакет орбіти тепер видає додатковий eci_track), режим вбудовування/iframe та завантаження як HTML-звіт — кожен із модульними тестами node у CI.
• Модель похибок IMU, звірена з datasheet (tests/imu_allan_spec.rs): ARW/VRW/нестабільність зміщення ADIS16465/16488/16460, відновлені із синтезованої девіації Аллана та перевірені за специфікаціями виробника (ідентифікація NIST SP1065 / IEEE 952).
• Перевірка оцінювачів Аллана за NIST SP1065 (tests/allan_nist_sp1065_1000point.rs): чотири оцінювачі відтворюють опубліковані еталонні девіації для 1000 точок і довірчі межі з Таблиці 32.
• Рівні захисту SBAS / DO-229E, безіоносферна комбінація L1/L5 та мапа відповідності DO-316 (модуль sbas). sbas_protection_level формує зважену геометричну матрицю з висоти/азимута кожного супутника та бюджету похибок UDRE/GIVE/повітряного/тропосферного, обертає нормальну матрицю (спільний orbit::invert4) і проєктує дисперсії в HPL/VPL через K-коефіцієнти DO-229E (PA 6.0/5.33, NPA 6,18). iono_free_l1l5 додає безіоносферну псевдодальність GPS L1/L5 (IS-GPS-705, γ₁₅ = 1.79327), перевірену на скасування незалежної першопорядкової іоносферної затримки рушія. do316_compliance_map зіставляє вимоги DO-316/DO-229E з функціями, що їх реалізують. Звірено із замкненими визначеннями K-коефіцієнтів, еталонною геометрією numpy inv(GᵀG) та тотожністю коваріації двома шляхами; перехресна перевірка відповідності опублікованих PL щодо RTKLIB/gLAB задокументована як така, що очікує розгляду, в docs/COMPLIANCE.md.
• Повна тесеральна сферично-гармонічна гравітація — поле EGM2008 до степеня/порядку 70. Новий gravity_sh::SphericalHarmonicField обчислює геопотенціал і його прискорення в земній системі з повністю нормованих коефіцієнтів C̄_nm, S̄_nm, використовуючи стабільне нормоване рекурентне співвідношення Лежандра Holmes–Featherstone (денормалізація переповнила б на цьому степені). Постачувані коефіцієнти — продукт NGA EGM2008 (суспільне надбання, через ICGEM), вбудований у egm2008_data.rs і побітово відтворений tools/gen_egm2008.py із зафіксованого tools/egm2008_to70.gfc; будь-яку модель ICGEM .gfc завантажують через from_gfc. Звірено з трьома незалежними оракулами: згортання до точкової маси (лише C̄00 = −μr/|r|³), поле лише із зональних складових, що відтворює наявний forces::zonal_accel до ~1e-9, та аналітичне прискорення, що збігається зі скінченнорізницевим градієнтом безпосередньо підсумованого потенціалу до <1e-6.
• Загальнорелятивістське прискорення Лензе–Тіррінга (захоплення системи відліку) (forces::lense_thirring_accel, IERS 2010 рівн. 10,12), гравітомагнітний член понад наявну поправку Шварцшильда, підключений до числового propagator через новий прапорець ForceModel::lense_thirring(). Перевірено: лінійне за кутовим моментом Землі та на 1–2 порядки величини менше за член Шварцшильда, у режимі вимірювань LAGEOS / Gravity Probe B.
• Трейт Propagator, що об'єднує аналітичний і числовий propagator орбіти. Числовий propagator силової моделі Ковела тепер рівноправний із SGP4: новий тип NumericalPropagator (початковий стан + ForceModel + Tolerance + вибір Integrator із подвоєнням кроку або Дормана–Прінса) і Sgp4 обидва реалізують propagator::Propagator, чий state_at(t_seconds) -> StateVector повертає інерціальний стан TEME в одиницях SI (м, м/с), тож їх можна взаємозамінно використовувати за Box<dyn Propagator>. Реалізація SGP4 — точне перетворення км/хв→SI власного методу (перевірено тестом на рівність); числова реалізація через трейт проходить той самий суб-метровий бар'єр точного Кеплера, два адаптивні драйвери збігаються, а PropagatorError виводить базовий код SGP4.

0.13.0 - 2026-06-08#

Цей випуск закриває найбільшу прогалину коректності рушія: орієнтацію Землі та редукцію системи відліку тепер виконано на рівні еталонної реалізації (звірено побітово з ERFA/SOFA), стек цілісності отримує двоугруповальний ARAIM на реальних TLE GPS+Galileo, а шари поширення, квантових датчиків, місячні/цисмісячні та геомагнітні поглиблюються — разом із типізованим API Python, багатшим браузерним playground і матрицею відтворюваності на трьох ОС. Основне:

• Системи відліку, побітово. Повна нутація IAU 2000A і 2000B, прецесія IAU 2006, редукція GCRS↔ITRS IAU 2006/2000A на основі CIO (X, Y, s), рух полюса IERS і вихідні системи TEME→GCRS/ITRS — кожне звірено побітово з еталонними підпрограмами ERFA/SOFA.
• Двоугруповальний ARAIM (GPS + Galileo) на реальних TLE, з HPL/VPL, виводом діаграми Стенфорда та відкритим docs/ARAIM_REFERENCE.md.
• Цисмісячний PNT: propagator CR3BP Земля–Місяць, системи MCI↔MCMF, селенографічні координати та запускний сценарій цілісності LunaNet для Місяця.
• Квантове зондування: систематичні ефекти Коріоліса та AC-Stark для інтерферометра на холодних атомах, перебір дрейфу та звірка з бюджетом Freier (2016).
• Геомагнітна модель основного поля IGRF-14, самодостатня й перевірена.
• Типізований API Python (PyO3 RunOutput/ScenarioMeta, .data(), scenario_kinds, validate_toml, заглушки типів) зі збіркою коліс у CI, а також повноцінний вихід propagator у GCRS/ITRS та експорт CCSDS OMM.
• Достовірність і відтворюваність: пряме порівняння точності SGP4 з незалежним крейтом sgp4, бар'єр покриття в CI (~97% рядків у src/) і матриця відтворюваності на трьох ОС (ubuntu/macos/windows).

Змінено#

• Кожна діаграма playground тепер відповідає темі сайту. Усі дванадцять генераторів SVG-діаграм — діаграма результату/holdover (src/report.rs + src/chart.rs), діаграма девіації Аллана (web/app.js) і кожна діаграма сценарію (src/hybrid.rs, jamming.rs, timetransfer.rs, spoof.rs, raim.rs Стенфорд + доступність, lunar.rs, ensemble.rs, sweep.rs, gnss_sim.rs, fusion/pack.rs, inertial/mod.rs) — використовували холодні темно-сині панелі (#0e131b), холодно-сірі осі/текст і строкату червоно-синьо-фіолетову палітру серій. Тепер скрізь теплий графітовий набір: панелі --bg, тепла сітка --line, підписи --fg із сталим призначенням серій — квантова = медово-золота (--accent-bright), класична = тепла бурштинова (--partial), специфікація/межа = --crit. Діаграми з кодуванням безпеки зберігають своє значення: діаграма RAIM Стенфорда лишається зеленою (доступно) / бурштиновою (оманливо) / червоною (небезпечно) / приглушено-сталевою (недоступно), а HPL/VPL читаються як золото/бронза.
• Діаграми тепер самоописові після збереження/завантаження. Обидві діаграми вбудовують свій заголовок в SVG (заголовок діаграми Аллана та підзаголовок «lower is better» раніше були лише HTML навколо зображення, тож збережене зображення не мало підпису), і обидві мають нижній колонтитул походження — Kshana v<version> · <scenario-hash> · kshana.dev — тож завантажена діаграма самодостатня й лишається відтворюваною.
• Кожна діаграма тепер має нижній колонтитул походження. Колонтитул — Kshana v<version> · scenario <hash> · kshana.dev — проставляється централізовано для всіх видів сценаріїв у api::run_toml (раніше він був лише на діаграмах holdover і Аллана), тож будь-яке збережене чи завантажене зображення — з playground, з експорту .chart.svg в CLI чи з HTML-таблиці результатів — вказує свою версію, відбиток сценарію та джерело. Хеш позначено scenario для ясності, він береться з scenario_hash результату, де він є, із запасним хешем джерела для звітів цілісності/Місяця. Що таке відбиток і навіщо він, задокументовано в розділі README «Output» та в docs/PROVENANCE.md.

Виправлено#

• raim::chi2_quantile і семплер шуму Стенфорда для RAIM тепер не панікують на значеннях поза діапазоном / нескінченних чи нечислових (знахідка фазингу, що залежить від порядку read_dir, з нових сценаріїв ARAIM). chi2_quantile тепер перевіряє p/k як normal_quantile (повертаючи граничне значення замість паніки через assert!), а Normal шуму Стенфорда для доступності обмежує σ строго додатним значенням — тож стек цілісності/ARAIM ніколи не панікує на змінених чи хибно налаштованих сценаріях.

Додано#

• Матриця CI міжплатформної відтворюваності. Нове завдання reproducibility-matrix запускає тести відтворюваності на ubuntu-latest, macos-latest та windows-latest за кожним push. Оскільки повний JSON результату не є побітово ідентичним між ОС (розбіжність libm в останньому ULP), воно точно перевіряє платформонезалежну проєкцію — відбиток вхідних даних плюс форму виводу, зафіксовані для кожного сценарію як еталони SHA-256 у tests/golden/ новим tests/cross_platform_golden.rs — разом із числовими фіксаціями (golden.rs, до 1e-6), станами SGP4 (sgp4_verification.rs, до 2e-5 км) і детермінованістю в межах процесу (determinism.rs). Разом це доводить міжплатформну відтворюваність на трьох ОС без крихкості точного хешування повного виводу побайтно. docs/REPRODUCIBILITY.md описує цей поділ.
• Бар'єр покриття коду в CI. Нове завдання coverage запускає cargo-tarpaulin із рушієм на основі вихідного коду LLVM, публікує звіт lcov як артефакт збірки та забезпечує нижню межу покриття рядків для src/ (згенеровані таблиці даних, точка входу CLI, тести та вебресурси виключено). Виміряне покриття рядків — ~97% на src/ (SGP4 і модулі годинника ≥95%); бар'єр встановлено на 85% — вище цілі ≥80% і з запасом від виміряного значення, тож він ловить регресії без хибних спрацювань. У README опубліковано значок покриття.
• Пряме порівняння SGP4/SDP4 з незалежним крейтом sgp4. Новий тест (tests/sgp4_crate_comparison.rs) перехресно звіряє propagator Kshana з найпоширенішою бібліотекою SGP4 на Rust (neuromorphicsystems/sgp4, додана як залежність лише для тестів) на тих самих 666 векторах AIAA 2006-6753. Коли обидві працюють на гравітаційній моделі WGS72, яку використовують вектори, дві незалежні реалізації збігаються із субмікронною точністю на навколоземних і резонансних орбітах та з 4,12 мм у найгіршому випадку за всіх режимів, і обидві відтворюють еталонну таблицю tcppver.out. Зафіксована таблиця порівняння (tests/fixtures/sgp4_comparison.md, регенерується через KSHANA_REGEN_FIXTURES=1) розбиває результат за режимами (LEO/MEO, далекий космос, резонанс ½ доби та 1 доби) і зазначає чотири навмисно патологічні випадки, які крейт відхиляє під час побудови. Живі перевірки тримають обидві реалізації в межах 2e-5 км від еталона й узгодженими між собою в межах 4e-5 км — це захист від регресій, а не разова дія. Це конкурентна родовід-перевірка: коректність відносно незалежної кодової бази, а не лише статична таблиця. (Типовий from_elements крейта використовує WGS84, тож відрізняється від еталона WGS72 приблизно на км — про це чесно сказано в тексті таблиці.)
• Експорт CCSDS OMM тепер доступний наскрізно. Запис OMM (src/omm.rs) раніше не мав шляху через CLI/API; середні елементи сценарію orbit тепер можна публікувати як каталог CCSDS 502.0-B-2 OMM — одне повідомлення OMM KVN на кожен супутник, визначений TLE — через kshana <orbit.toml> --export-omm out.omm, або export_omm = true у сценарії автоматично записує <scenario>.omm (за зразком наявного --export-sp3). Кожне повідомлення несе справжній каталожний номер NORAD супутника, міжнародний позначник COSPAR (YYYY-NNNP) та епоху (форма CCSDS «день року»), розібрані з рядка TLE 1 новою tle::parse_tle_identity; рядок назви стає OBJECT_NAME (інакше OBJECT <id>). CREATION_DATE — це епоха сценарію, а не поточний годинниковий час, тож вивід відтворюваний. Новий API: api::export_omm / api::auto_export_omm, OmmFile::from_tle_block, OrbitClockScenario::to_omm_string. Синтетичний сценарій Walker або RINEX (без середніх елементів TLE) завершується помилкою замість видачі порожнього файла. Звірено із вбудованим знімком gps-ops з 30 супутників (tests/sp3_export_roundtrip.rs).
• Інтерактивні підказки при наведенні на діаграмах playground. Наведення курсора на діаграму притягує перехрестя до найближчого відліку й показує підказку зі значенням (web/hover.mjs, підключено в web/app.js). На діаграмі Аллана вона показує τ і σ_y(τ) кожного годинника; на часових діаграмах сценаріїв (holdover годинника, лічба шляху, передавання часу, гібридний PNT, GNSS/INS) — час і значення кожного набору у власних одиницях діаграми (нс / м / пс / використання), розібраних із результату, тож підказка збігається з кривою. Спеціалізовані діаграми (RAIM, спуфінг, перебір) накладки не мають. Діаграми лишаються самоописовими blob-зображеннями <img> — накладка є прозорим перехрестям із підказкою зверху, тож завантаження/порівняння/експорт не зачеплено. Координатну математику (найближчий відлік, курсор→частка графіка, розбір ламаної) покрито модульними тестами (web/hover.test.mjs, запускаються в CI).
• Режим порівняння A/B у playground. Закріпіть будь-який прогін як базовий A, запустіть другий сценарій — і обидва показуються поруч із таблицею різниць показників якості (holdover, RMS/p95 часу, доступність), що підсвічує переможця за кожною метрикою (web/compare.mjs, підключено в web/app.js; логіку різниць покрито модульними тестами в web/compare.test.mjs, запускаються в CI). Усі значення вставляються як текст, а всі діаграми — через blob <img>, тож жоден рядок зі сценарію ніколи не вводиться як розмітка.
• Кнопки завантаження діаграм (SVG + PNG). Кожна діаграма playground тепер має панель «Download SVG / PNG» у стилі теми (web/chartdl.mjs, підключено в web/app.js). SVG віддає вірний масштабований оригінал; PNG растеризує те саме самоописове зображення у 2x для слайдів і документів. Файли названо з їхнім походженням — kshana-<chart>-v<version>-<scenario-hash>.<ext> — а логіку імені/розміру покрито модульними тестами (web/chartdl.test.mjs, запускаються в CI).
• Геомагнітна модель основного поля IGRF-14 (src/igrf.rs). Стандартне сферично-гармонічне поле IAGA (степінь/порядок 13, епоха 2025,0 + вікова варіація 2025–2030; коефіцієнти згенеровано машинно з офіційного igrf14coeffs.txt за допомогою tools/gen_igrf.py у src/igrf_data.rs, побітово відтворювано). Синтез із нормалізацією Шмідта повертає вектор поля (північ/схід/вниз) і похідні елементи (схилення, нахил, горизонтальна/повна інтенсивність) у будь-якому геодезичному місці/на будь-яку дату, а також геомагнітний полюс і силу диполя — магнітний аналог зіставника гравітаційної карти для альтернативної навігації PNT. Перевірено самодостатньо: синтез збігається з точним замкненим нахиленим диполем, повне аналітичне поле степеня 13 збігається зі скінченною різницею скалярного потенціалу, вісь диполя відтворює відомий геомагнітний полюс (~80,7°N, −72,7°E) і силу ~29,7 мкТл, а глобальне поле фізичне.
• Типізовані прив'язки Python (src/python.rs). Окрім run/run_full за схемою «рядок на вході — рядок на виході», модуль тепер надає типізований клас RunOutput (.json, .svg, .summary та метод доступу .data(), що повертає результат, розібраний у рідний словник Python — без повторного розбору JSON, придатний до обгортання NumPy), а також run_typed, scenario_kinds() (розібраний список словників метаданих) і validate_toml() (список повідомлень про помилки без викидання винятків). Постачається заглушка типів PEP 561 (kshana.pyi + py.typed) для mypy/pyright/редакторів і короткий посібник docs/PYTHON_API.md. Наявні функції не змінено.
• Повноцінні вихідні системи відліку для propagator (src/orbit.rs перелік Frame + position_in_frame + state_gcrs). Будь-який Propagator (Kepler, SGP4, RINEX, GLONASS, SP3) тепер може видавати своє положення в TEME, GCRS (≈ J2000) або ITRS (земна система) — TEME рідна, GCRS через перевірену редукцію TEME→GCRS, ITRS через ланцюжок цієї редукції з обертанням CIO IAU 2006/2000A gcrs_to_itrs — а також свій повний стан у GCRS (положення + швидкість) через state_gcrs. Інерціальний вихід на дату більше не обмежений лише TEME.
• Редукція небесної системи в земну за CIO IAU 2006/2000A (src/cio.rs). Сучасний ланцюжок GCRS↔CIRS↔ITRS без рівнодення: координати CIP X, Y, зчитані з матриці зміщення-прецесії-нутації IAU 2006/2000A (з повторним використанням перевіреної прецесії FW + нутації 2000A з поправкою P03 eraNut06a), 66-членний ряд локатора CIO s (eraS06, згенерований машинно з еталона ERFA за допомогою tools/gen_s06.py у src/cio_s06_data.rs, побітово відтворюваний), матриця GCRS→CIRS (eraC2ixys), кут обертання Землі (eraEra00) і повне обертання GCRS→ITRS (eraC2tcio, складене з наявним рухом полюса IERS). Звірено побітово з опублікованими тестовими векторами eraXys06a (X=0.5791308482835292617e-3, Y=0.4020580099454020310e-4, s=-0.1220032294164579896e-7 при JD_TT 2453736,5), eraC2ixys та eraEra00. Показано, що ланцюжок CIO і застарілу редукцію TEME на основі рівнодення/GMST-1982 збігаються з точністю до задокументованої різниці конвенцій зоряного часу ≈2·(рівняння рівнодень). Це строга редукція, яку шлях рівнодення/GMST лише наближав.
• Повний ряд нутації IAU 2000A (src/nutation.rs nutation_iau2000a, nutation_matrix_2000a). Повна модель MHB2000 — 678 лунно-сонячних + 687 планетних членів — з точністю < 0,1 мс дуги, поряд із наявним скороченням 2000B на 77 членів. Таблиці згенеровано машинно з еталона IAU SOFA / ERFA nut00a за допомогою tools/gen_nut00a.py у src/nutation_iau2000a_data.rs (генератор відтворює зафіксований файл побітово), а весь ряд — обидва набори фундаментальних аргументів IERS-2003 і MHB2000 та планетні довготи — звірено побітово з опублікованим тестовим вектором eraNut00a (Δψ = −0.9630909107115518e-5, Δε = 0.4063239174001679e-4 при JD_TT 2453736,5, до 1e-13 рад). Типова редукція TEME→GCRS зберігає ряд 2000B (~1 мс дуги, нижче за спрощення обертання системи швидкості в ланцюжку); nutation_matrix_2000a надає матрицю на дату з < 0,1 мс дуги для тих, кому вона потрібна.
• Запускний сценарій цілісності для Місяця (kind = "lunar-integrity", scenarios/lunanet-araim.toml). Підключає прохід рівня захисту на південному полюсі Місяця (src/lunar.rs LunarScenario → south_pole_hpl_pass) до виконавця сценаріїв із JSON LunarReport і SVG-діаграмою HPL залежно від часу, тож випадок цисмісячної цілісності доступний просто з CLI. Він чесно показує прогалину: за σ_URE LANS 30 м HPL на південному полюсі (≈ 260–450 м) перевищує межу тривоги 50 м (0 % доступності) — цілісність PNT для Місяця ще не досягнута.
• Доступність двоугруповального ARAIM на реальних TLE GPS+Galileo та підключення до виконавця сценаріїв (src/raim.rs, src/orbit.rs, scenarios/araim-gps-galileo.toml). Додає araim_dual_constellation_availability (розширений рушій ARAIM — несправності окремого супутника і всього угруповання — на часовій сітці) та visible_positions_labeled і підключає його до виконавця IntegrityScenario через прапорець araim_dual, щоб багатогнссне дослідження ARAIM було доступне прямо з TOML. Тест на реальних даних (tests/araim_dual_real_data.rs) на вбудованих знімках Celestrak GPS+Galileo від 2026-06-07 показує, що додавання Galileo піднімає доступність ARAIM з 0,21 до 0,67 за вимогливого VAL 12 м (10,5→21,8 супутників у видимості), тоді як режим, стійкий до несправностей угруповання, принципово обмежений за лише двох угруповань — кількісна причина, чому стійка двоугруповальна цілісність потребує третього угруповання або SBAS. Чесний залишок: числово точне відтворення таблиці A-3 з EU ARAIM TN на одній прив'язаній до версії епосі та запис фікстури Zenodo.
• Обмежена колова задача трьох тіл (CR3BP) для системи Земля–Місяць (src/cr3bp.rs). Нове ядро цисмісячної динаміки, якого не можуть дати propagator двох тіл/SGP4: рівняння руху в обертовій системі (cr3bp_accel), propagator RK4 (propagate_cr3bp), інтеграл сталої Якобі (jacobi_constant) і п'ять точок Лагранжа (lagrange_points). Звірено із замкненими / опублікованими опорами: колінеарні точки Земля–Місяць (L1 ≈ 0,83692, L2 ≈ 1,15568, L3 ≈ −1,00506), точні рівносторонні L4/L5 = (½−μ, ±√3/2, 0), усі п'ять підтверджено як рівноваги поля, стала Якобі зберігається з точністю інтегратора під час поширення, а також позаплощинна відновлювальна сила, що робить можливими орбіти halo/NRHO. Це основа для подання справжньої NRHO. Чесний залишок: диференційно скориговані періодичні початкові умови NRHO 9:2, ексцентрична/ефемеридна (DE) модель і денормалізоване перетворення в селеноцентричні системи відліку src/lunar.rs.
• Рух полюса IERS і редукція TEME→ITRF (src/frames.rs). Додає polar_motion_matrix (SOFA iauPom00: W = Rx(−y_p)·Ry(−x_p)·Rz(s′) з локатором TIO s′), pef_to_itrf / itrf_to_pef та teme_to_itrf — обертання TEME→PEF на основі GMST з наступним рухом полюса — завершуючи точне положення в земній системі ITRF поверх teme_to_ecef лише на GMST (рух полюса — ефект у десятки метрів на орбітальному радіусі). x_p/y_p — спостережувані величини IERS, які подає викликач. Чесний залишок: повністю CIO-ланцюжок (X, Y, s) і числова перехресна перевірка ANISE/SPICE <10 м лишаються наступними кроками.
• Систематичні ефекти атомного інтерферометра на холодних атомах, перебір дрейфу та перевірка за опублікованим пристроєм (src/inertial/quantum_imu.rs, docs/QUANTUM.md). Розширює акселерометр CAI з перших принципів двома провідними детермінованими систематичними ефектами: фазою Коріоліса/обертання Φ_cor = 2·k_eff·v_⊥·Ω·T² (coriolis_phase, з еквівалентним зміщенням прискорення 2·Ω×v через coriolis_accel_bias) і фазою світлового зсуву AC-Stark Φ_LS = (δ_LS,1 − δ_LS,3)/Ω_eff (ac_stark_phase, що скасовується симетрією π/2–π–π/2 для сталого зсуву). Додає cai_drift_sweep (дрейф положення за лічбою шляху залежно від часу циклу — суть порівняння квантового з класичним) і тест перевірки за мобільним гравіметром Freier et al. 2016 (arXiv:1512,05660): змодельований поріг квантово-проєкційного шуму лежить нижче опублікованого короткотермінового шуму 96 нм/с²/√Гц і в межах ~2 порядків від нього. docs/QUANTUM.md оновлено. Чесний залишок: систематичні ефекти хвильового фронту/спрямування променя, розв'язання неоднозначності смуг, точне відтворення льотних випробувань CARIOQA-PMP / Boeing-AOSense (потребує опублікованих PSD платформи) і пресет для playground на JS.
• Редукція цисмісячної системи відліку та прохід цілісності на південному полюсі Місяця (src/lunar.rs). Розширює місячний рушій ARAIM обертанням MCI↔MCMF (Moon-centered inertial ↔ Moon-fixed) (mci_to_mcmf / mcmf_to_mci, спрощена модель середнього обертання зі швидкістю місячного зоряного обертання), селенографічними широтою/довготою/висотою (mcmf_to_selenographic / selenographic_to_mcmf) та south_pole_hpl_pass — приземлений приймач в районі Artemis щодо репрезентативного набору ретрансляторів LunaNet за 24-годинний прохід, що чесно кількісно визначає прогалину цілісності: за номінальної σ_URE LANS 30 м рівень захисту скінченний, але перевищує межу тривоги поверхневих операцій 50 м. Чесний залишок: точна ефемерида LANS NRHO (цисмісячна орбіта 3-body), фізична лібрація / прецесійний місячний полюс (DE421/SPICE) і сценарій LunaNet у TOML лишаються наступними кроками.
• Повідомлення підтримки цілісності ARAIM, SVG діаграми Стенфорда та відкритий еталон ARAIM (src/raim.rs, docs/ARAIM_REFERENCE.md). Додає явне IntegritySupportMessage (σ_URA / σ_URE / b_nom / P_sat / P_const з еталонними значеннями WG-C GPS+Galileo та перетворювачами .fault_priors() / .dual_fault_priors() у рушії одиночної несправності araim_raim і несправності всього угруповання araim_dual_raim), автономний засіб відображення stanford_svg діаграми цілісності Стенфорда (чотири зони, межа PL = error, напрямні меж тривоги, один кольоровий маркер на епоху) і docs/ARAIM_REFERENCE.md, що документує алгоритм, ISM, гіпотези несправностей, контракт рівня захисту та перевагу двох угруповань. Тести демонструють виграш геометрії/надлишковості (додавання другого угруповання звужує HPL одиночної несправності) і стійкість до несправності угруповання (двоугруповальний користувач переживає втрату цілого угруповання; одноугруповальний — ні). Чесний залишок: числове відтворення таблиці A-3 з EU ARAIM TN / показника доступності 15–25 % на прив'язаному до версії знімку реальних TLE, запис фікстури Zenodo та підключення araim_dual_raim до виконавця файлів сценаріїв.
• Нутація IAU 2000B та повна інерціальна редукція TEME→GCRS/J2000 (src/nutation.rs). Додає другу й третю складові справжньої редукції інерціальної системи поверх уже наявної прецесії IAU 2006: 77-членний лунно-сонячний ряд нутації MHB2000 (nutation_iau2000b, стандартне скорочення IAU 2000B з точністю ~1 мс дуги) з фундаментальними аргументами Делоне та матрицею нутації SOFA iauNumat, а також ланцюжок Vallado AIAA-2006-6980 TEME→TOD (рівняння рівнодень) → TOD→MOD (нутація) → MOD→GCRS (зміщення-прецесія), що надається як teme_to_gcrs(r, v, jd_tt) / gcrs_to_teme. Ряд, аргументи та сталі одиниць перенесено з еталона IAU SOFA / ERFA nut00b і звірено побітово з опублікованим тестовим вектором eraNut00b (Δψ, Δε до 1e-13 рад). Чесний залишок: повний 678-членний ряд IAU 2000A (<0,1 мс дуги), числова перехресна перевірка ANISE/SPICE <10 м і рух полюса лишаються наступними кроками (див. ROADMAP.md).

0.12.0 - 2026-06-06#

Цей випуск містить перший у Kshana неаналітичний propagator орбіти — інтегратор Ковела з ієрархічною силовою моделлю з шести збурень (дві маси + зональні J2–J6 + третє тіло Сонця/Місяця за епохою + тиск сонячного випромінювання з конічною тінню/напівтінню + атмосферний опір + постньютонівська релятивістська поправка Шварцшильда), яким керують два адаптивні інтегратори (RK4 з подвоєнням кроку та вкладена пара Дормана–Прінса RK5(4)), — поряд із шаром маневрів / проєктування траєкторій (імпульсні та скінченні маневри, розв'язувач Ламберта Іцо та перебір «porkchop»), шаром alt-PNT із зіставленням гравітаційної карти, що відновлює 60-хвилинну трасу без GPS із точністю до 500 м, конвеєром пакетного й послідовного визначення орбіти та повним 17-станним тісно зв'язаним UKF GNSS/INS з лічбою шляху на квантовому CAI. Кожну числову можливість зафіксовано за аналітичною істиною чи виведеною вручну замкненою формою; збурення, вимкнені за замовчуванням, не зачіпають випущених еталонів.

Додано#

• Постньютонівська (Шварцшильда) релятивістська поправка (forces::relativistic_accel + propagator::ForceModel::relativity). Додає домінантне загальнорелятивістське збурення на навколоземній орбіті — головну причину релятивістського зсуву перигею — у формі IERS / Montenbruck–Gill β = γ = 1 a = (μ/c²r³)·{[4μ/r − v²]·r + 4(r·v)·v}. Як і атмосферний опір, вона залежить від швидкості, тож входить у праву частину інтегратора (r, v) через [accel_rv], вмикається за вибором і за замовчуванням вимкнена. Перевірено самодостатньо: на коловій орбіті вона зводиться до замкненої форми 3μ²/(c²r³)·r̂ (суто радіальна й назовні, позавісьові складові точно нульові); її відношення до двомасового члена — підручникове ≈1.9·10⁻⁹ на LEO (сигнатура μ/(c²r)); випадок радіальної швидкості збігається зі спрощеним вручну μ(4μ + 3v²r)/(c²r³); а в propagator вона збурює орбіту, не розсіюючи її — велика піввісь зберігається з точністю набагато краще за метр/добу, структурна протилежність монотонному спаду від опору. Оскільки вона вимкнена за замовчуванням, еталони двох мас/J2/зональних не зачеплено. Налаштування параметрів PPN (β,γ) і член захоплення системи відліку Лензе–Тіррінга лишаються наступними кроками.
• Конічна модель тіні умбра+напівтінь (forces::conical_shadow), тепер використовується тиском сонячного випромінювання. Оновлює двійкове затемнення на основі циліндра умбри до плавного коефіцієнта ν ∈ [0,1]: Сонце й Земля моделюються як диски з видимими кутовими радіусами a = asin(R☉/d☉), b = asin(Rₑ/|r|) і видимим відстанню між центрами c, а ν — це одиниця мінус частка диска Сонця, закритої диском Землі (площа перекриття двох кіл — «лінзи») — повне сонце для c ≥ a+b, повна умбра для c ≤ b−a, кільцеве для c ≤ a−b і неперервна напівтінь між ними. srp_accel тепер її використовує, тож сила SRP плавно спадає крізь затемнення замість перемикання вмк/вимк. Додає номінальний forces::SOLAR_RADIUS за IAU. Перевірено самодостатньо: ν = 1 на повному сонці та ν = 0 глибоко в умбрі (точно), плавна монотонна напівтінь (ν зростає від 0 до ~½ при c = b до 1 у смузі [b−a, b+a]), а конічна напівтінь виходить за межі циліндра умбри (точка, яку двійковий циліндр вважає повністю освітленою, для конуса має 0 < ν < 1). Простіший cylindrical_shadow лишається доступним; потемніння диска Сонця до краю та тінь сплюснутої Землі лишаються наступними кроками.
• Вкладений інтегратор Дормана–Прінса RK5(4) (integrator::dopri54_step / integrator::integrate_dopri + propagator::propagate_dopri). Додає стандартну вкладену пару за таблицею Бутчера Дормана–Прінса (1980) поряд із наявним драйвером RK4 з подвоєнням кроку: сім стадій FSAL дають розв'язок 5-го порядку й оцінку похибки 4-го порядку з одного набору обчислень (7 проти 11 викликів функції на крок), дешевшу оцінку локальної похибки. Адаптивний драйвер використовує ту саму RMS-норму похибки та контролер кроку 0.9·(1/err)^(1/5), тож це пряма заміна; propagator::propagate_dopri надає його на силовій моделі орбіти. Перевірено самодостатньо: вкладена оцінка похибки є O(h⁵) (половинний крок зменшує її ~у 32 рази); DP5(4) інтегрує y' = y до e і гармонічний осцилятор на 50 періодах із збереженням енергії до <1e-6; він досягає тієї самої кінцевої точки з тим самим допуском за меншої кількості обчислень функції, ніж подвоєння кроку (без втрати точності); а propagate_dopri проходить той самий бар'єр аналітичної істини, що й шлях RK4, — субметрова відмінність від точного розв'язку Кеплера в універсальних змінних на 24-годинній орбіті LEO — тоді як два драйвери збігаються до <1 м на орбіті J2..J6 (замкненої форми немає). Вищі вкладені пари (RKF7(8) / DOP853) лишаються наступним кроком.
• Атмосферний опір підключено до propagator як його першу силу, що залежить від швидкості (forces::atmospheric_density + forces::drag_accel + propagator::ForceModel::drag). Додає атмосферу кусково-експоненційну за Vallado Table 8-4 ρ = ρ0·exp(−(h−h0)/H) (28 смуг від рівня моря до понад 1000 км, із обмеженням нижче поверхні) і квадратичний опір a = −½ · ρ(h) · (C_D·A/m) · |v_rel| · v_rel відносно співобертової атмосфери v_rel = v − ωₑ ẑ × r (forces::EARTH_ROTATION_RATE = 7.2921151467e-5). Оскільки опір залежить від швидкості, ForceModel отримує новий accel_rv(t, r, v), а права частина інтегратора тепер передає швидкість (f(t,[r;v]) = [v; a(t,r,v)]); функція accel_at лише за положенням не змінена, тож консервативні члени та еталони не зачеплено. Перевірено самодостатньо: густина прив'язана до значення 1,225 кг/м³ на рівні моря, обмежується нижче поверхні, монотонно спадає крізь LEO, на 400 км лежить у середньосонячній смузі ~1e-12 кг/м³, а її відновлена локальна шкала висот (≈ 58 км на 400 км) фізична; опір протидіє співобертовій відносній швидкості з величиною LEO ~2e-6 м/с² для C_D·A/m = 0.02 m²/kg; і — ключова ознака — опір дисипативний: орбіта 300 км втрачає питому енергію монотонно, а її велика піввісь спадає на обмежені ~км/добу, тоді як вакуумна база зберігає енергію до <1e-9. Густина термосфери NRLMSISE-00 (застереження щодо густини для опору < 5 %) лишається наступним кроком.
• Тиск сонячного випромінювання підключено за епохою до силової моделі propagator (forces::srp_accel + propagator::ForceModel::solar_radiation). Додає модель SRP «гарматне ядро» a = ν · P☉ · cᵣ · (A/m) · (AU/d)² · d̂ з коефіцієнтом затемнення за циліндричною тінню (forces::cylindrical_shadow, ν ∈ {0 1}): тиск випромінювання P☉ = Φ☉/c із сучасної повної сонячної освітленості 1361 Вт/м² (≈ 4,5398·10⁻⁶ Н/м²), спад потоку за оберненим квадратом (AU/d)² і радіальний поштовх від Сонця. Він іде тією самою правою частиною за епохою, що й третє тіло, беручи ефемериду Сонця ephem один раз на просунутій епосі epoch_jd_tt + t/86400, спільній для третього тіла Сонця та SRP. Компонується: with_zonals_j2_j6().third_body(true, true, epoch).solar_radiation(1.5, 0.02). Перевірено самодостатньо за виведеними вручну ознаками: тиск випромінювання на 1 AU зводиться до підручникового ≈ 4,5398·10⁻⁶ Н/м²; SRP повністю освітленого супутника LEO побітово ідентичний формулі гарматного ядра, спрямований від Сонця і лежить у смузі ~1,36·10⁻⁷ м/с² для cᵣ = 1,5, A/m = 0,02 м²/кг; подвоєння відстані до Сонця зменшує величину вчетверо (обернений квадрат); циліндрична тінь затемнює лише циліндр умбри (антисонячний бік і в межах одного радіуса Землі від лінії Земля–Сонце) і дає точно нульовий SRP у затемненні; а в propagator SRP збурює орбіту LEO на малу обмежену величину, що масштабується приблизно лінійно з A/m — тоді як модель без збурень лишається побітово незалежною від часу, не зачіпаючи еталонів двох мас/J2/зональних. Конічна умбра/напівтінь (плавна ν ∈ [0 1]), атмосферний опір і зовнішня перехресна перевірка за GMAT/Orekit лишаються наступними кроками.
• Третє тіло Сонця/Місяця за епохою підключено до змінної в часі правої частини propagator (propagator::ForceModel::third_body / accel_at). Збурення від третього тіла більше не є окремим силовим членом — тепер його інтегрує propagator Ковела як справді змінну в часі силу: кожне обчислення правої частини бере положення Сонця/Місяця з ephem на просунутій епосі epoch_jd_tt + t/86400 (з повторним використанням precession::julian_centuries_tt для перетворення доба↔століття), тож збурювачі рухаються своїми орбітами під час інтегрування, а не заморожені на початку. Компонується з будь-якою гравітаційною моделлю (ForceModel::with_zonals_j2_j6().third_body(true, true, epoch)). Перевірено самодостатньо: член Сонця в правій частині побітово ідентичний third_body_accel, обчисленому в положенні за ефемеридою на той момент і при t = 0, і при t = 1 day (що точно доводить прив'язку 86400 с ↔ 1 доба ↔ 1/36525 століття), збурювач просувається на ~2,6·10⁹ м/добу між відліками (не заморожений), миттєві приливні величини на LEO потрапляють у підручникові смуги ~5·10⁻⁷ м/с² (Сонце) і ~1,1·10⁻⁶ м/с² (Місяць, ≈ 2× Сонце), кожне тіло вимірно збурює добову траєкторію, лишаючись обмеженим, а той самий початковий стан, поширений на епохах із різницею в чверть року, дає іншу траєкторію (приливна вісь повертається на 90°) — тоді як модель без жодного з тіл побітово незалежна від часу, не зачіпаючи еталонів двох мас/J2/зональних. Точність ефемериди класу DE і зовнішня перехресна перевірка за GMAT/Orekit лишаються наступними кроками.
• Ефемерида Місяця низької точності (ephem::moon_position), що завершує пару третіх тіл Сонце/Місяць. Додає низькоточний місячний ряд Montenbruck & Gill (§3.3.2) поряд із моделлю Сонця, тож незалежна від тіла forces::third_body_accel тепер може керуватися будь-яким світилом без зовнішнього ядра DE/SPK. Перевірено самодостатньо за виведеними вручну місячними ознаками: геоцентрична відстань за місяць лишається в межах реальної обвідної перигею/апогею (~356 500–406 700 км), а її місячне середнє відновлює велику піввісь ~384 400 км; екліптична широта ніколи не перевищує нахилу місячної орбіти ~5,3° (перевірено проєкцією на полюс екліптики в екваторіальних координатах, що разом перевіряє ряд широти та обертання на нахил екліптики); напрям на Місяць повертається в межах 1° після одного зоряного місяця (27,3217 доби), а його добовий рух лишається у фізичній смузі 12–15°/добу; а збурення від третього тіла — Місяця — на супутнику LEO має підручникову величину ~1,1·10⁻⁶ м/с² (≈ вдвічі більше за сонячне). Точність положення класу DE, атмосферний опір і SRP лишаються наступними кроками.
• Гравітація третього тіла (Сонця) із вбудованою ефемеридою низької точності (forces::third_body_accel, ephem::sun_position). Додає до силової моделі збурення від третього тіла: a = GM₃·((s−r)/|s−r|³ − s/|s|³) (пряме притягання мінус непрямий член, який має віднімати геоцентрична система), з положенням Сонця від нового модуля ephem — низькоточного аналітичного ряду Montenbruck & Gill — без зовнішнього ядра DE/SPK для низькоточного прогону. Перевірено самодостатньо: прискорення збігається з точним градієнтом власного збурювального потенціалу (third_body_potential), збурення зникає в геоцентрі і має підручникову величину ~5·10⁻⁷ м/с² на супутнику LEO, а ефемерида Сонця влучає у виведені вручну опори J2000 — відстань у перигелії ≈ 1,471·10¹¹ м, схилення ≈ −23° біля грудневого сонцестояння, видимий рух ≈ 1°/добу (≈ 90° за чверть року) і відстань, що протягом цілого року лишається в обвідній орбіти Землі 0,983–1,017 AU. Виконує половину третього тіла кроку силової моделі в віхи числового propagator (Місяць надається в супутньому записі вище); точність положення класу DE, атмосферний опір і SRP лишаються наступними кроками.
• Силова модель зональних гармонік J2–J6 (forces::zonal_accel / zonal_potential). Розширює силову модель propagator Ковела за межі J2 до повного зонального поля Землі до степеня 6 (стандартні опубліковані ненормовані J2..J6 EGM-96), підключене до propagator як ForceModel::with_zonals_j2_j6(). Прискорення є точним аналітичним градієнтом зонального збурювального потенціалу R(r) = −(μ/r)·Σ Jₙ(Re/r)ⁿPₙ(z/r) (поліноми Лежандра висхідною рекурсією), перевіреним трьома незалежними способами: воно зводиться до перевіреної на 666 векторах j2_accel з машинною точністю при обмеженні до [J2]; воно збігається з числовим градієнтом власного потенціалу на повному полі J2..J6 (золота стандартна перевірка консервативного поля); а непарний J3 проти парних J2/J4..J6 членів демонструє свою характерну (анти)симетрію північ–південь за z → −z — асиметрію грушоподібної форми. Поширена орбіта J2..J6 зберігає повну енергію (кінетична + центральна + зональний потенціал) до ~1e-8 за добу й збурює орбіту лише з J2 на малу ненульову величину. Це виконує крок 2 («зональні гармоніки J2–J6») віхи числового propagator; поле тесеральних гармонік EGM високого степеня, опір, SRP, третє тіло та зовнішня перехресна перевірка за GMAT/Orekit лишаються наступними кроками.
• Числовий propagator орбіти (Ковела) (src/propagator.rs). Перший у Kshana неаналітичний propagator (решта стека орбіт — аналітичні SGP4/SDP4): він підключає силову модель двох мас + J2 (src/forces.rs) до адаптивного драйвера RK4 з подвоєнням кроку (src/integrator.rs) як f(t,[r;v]) = [v; a(r)] із перемикачем ForceModel. Перевірено за аналітичною істиною, сильнішою за числову перехресну перевірку іншим інструментом: незбурена орбіта відтворює точний розв'язок Кеплера в універсальних змінних із субметровою точністю на 24-годинній орбіті LEO (суворіший бар'єр, ніж «проти числового еталона < 10 м» у формулюванні віхи), питома енергія та кутовий момент зберігаються до ~1e-9 відносно, а вузлова регресія J2 відтворює замкнену j2_secular_rates із теорією першого порядку (в межах 2 %, залишок O(J2²)). Також додає solve_kepler_checked — розв'язувач Ньютона для рівняння Кеплера, що повертає Err замість мовчки хибної відповіді, коли не збігається за обмежений бюджет ітерацій (випадок біля перигею e = 0.999). Чесна межа: силова модель — лише дві маси + J2: поле тесеральних гармонік EGM високого степеня (200×200 + завантажувач), опір (NRLMSISE-00), SRP, сили третіх тіл і зовнішня перехресна перевірка за GMAT/Orekit лишаються наступними кроками.
• 60-хвилинне зіставлення гравітаційної карти без GPS до < 500 м (run_gps_denied_gravity_nav). Поглиблює шар alt-PNT до цілі перевірки ESA NAVISP Quantum Wayfarer: транспортний засіб летить трасою ~700 км протягом повної одногодинної втрати GNSS — його інерціальний розв'язок дрейфує до ≈ 70 км — а гравіметр на холодних атомах і ієрархічний від грубого до точного зіставник частинок/сітки відновлюють сталий дрейф INS до ≈ 145 м (< 500 м), зменшення у > 480 разів. Реальний поріг білого шуму гравіметра вноситься як детермінована послідовність із зерном (seed), тож зіставнику ніколи не дають безшумової істини, а прогін точно відтворюваний (перевірено побітово ідентичним і стабільним у межах кількох метрів за різних реалізацій шуму). Тест регресійного рівня показує, що уточнення необхідне — єдина груба сітка застрягає на ~2 км, лише триетапне уточнення долає бар'єр 500 м. Новий зафіксований сценарій scenarios/gps-denied-gravity-nav.toml. Рядок docs/CAPABILITY.md чесно лишається частковим (вбудованої карти EGM2008 досі немає), а його докази оновлено до результату 60-хв < 500 м. Чесна межа без змін: поле сферичних гармонік низького степеня + синтетичні маскони; Монте-Карло за реалізаціями похибки подання карти — наступний крок.
• Реєстр завищених тверджень + захист від регресій (docs/CLAIMS-VS-REALITY.md, tests/no_overclaims.rs). Завершує напрям чесності/зняття тверджень: чотирнадцять завищених тверджень, які каталогізував попередній аудит (OC-0…OC-13), тепер усі GREEN — сильні твердження (OC-0 зв'язаний фільтр Калмана годинник+положення, OC-2 глушіння J/S→C/N₀→втрата захоплення, OC-7 фізика CAI Маха–Цендера, OC-8 ARAIM HPL/VPL) замінені випущеними, перевіреними можливостями, а не пом'якшеним формулюванням, а решту рядків знято, щоб вони відповідали коду. Новий тест CI сканує живі публічні поверхні (README, CAPABILITY, GLOSSARY, web/) і падає, якщо будь-яка знята гола фраза завищеного твердження з'являється знову без застережень, тож рядок GREEN не може непомітно регресувати. Показник якості «цілісність» кожного прогону лишається чесно названим самоузгодженістю фільтра (не авіаційною цілісністю); справжній ARAIM HPL/VPL подається окремо, щоб ці два поняття ніколи не змішувалися.
• Навігація із зіставленням гравітаційної карти (alt-PNT без GPS). Новий src/gravimeter.rs додає шар можливостей alt-PNT, якого вимагають дослідження ESA NAVISP Quantum Wayfarer / QT-CCI із зіставлення гравітаційної карти: модель вимірювання гравіметра на холодних атомах, поріг білого шуму якої виведено з ASD акселерометра CAI (σ = ASD/√τ); поле гравітаційних аномалій у сферичних гармоніках низького степеня, повністю нормоване (звірене із замкненими функціями Лежандра P̄₁₁=√3·cosφ, P̄₂₀=(√5/2)(3sin²φ−1), P̄₂₂=(√15/2)cos²φ та виведеною вручну однокомпонентною аномалією 1,897 мГал) плюс синтетичні маскони для локальних особливостей високого степеня; і фільтр частинок із зіставленням гравітаційної карти (поєднує mapmatch + particle_filter), що відновлює трасу без GPS із послідовності аномалій, крізь яку він летить. Зафіксований еталонний тест NAVISP (scenarios/gravity-map-nav.toml) зменшує вільний інерціальний дрейф ~73 км до кількох км. Чесна межа: Kshana не містить повного набору коефіцієнтів EGM2008 2190° — поле є низького степеня + маскони, а не справжньою картою високої роздільності; завантажувач EGM/EIGEN, магнітна карта, SLAM за рельєфом та підключення kind= рушія сценаріїв із SVG-діаграмою дрейфу лишаються наступними кроками. docs/CAPABILITY.md «Навігація за гравітаційною картою / alt-PNT» → частково.
• Моделювання маневрів і плацдарм проєктування траєкторій. Новий src/maneuver.rs додає перший шар проєктування траєкторій над SGP4: імпульсні вузли ΔV, що застосовують розрив швидкості й переносять уперед коваріацію 6×6 (детермінований імпульс ⇒ одинична матриця переходу стану; коваріація похибки виконання повертається із системи імпульсу — ECI або LVLH — у блок швидкості), інтегрування скінченного імпульсу (стала тяга на дузі імпульсу з масою як станом), досягнуте ΔV якого перевіряється за замкненим рівнянням ракети Ціолковського краще за 0,01 %, розв'язувач одновиткової задачі Ламберта за Izzo-2015 (r1, r2, час польоту ⇒ v1, v2), точний propagator Кеплера в універсальних змінних (істина двох мас) і перебір «porkchop», що відображає сітку «епоха запуску × епоха прибуття» на C3 відльоту та V∞ прибуття, виведені як 2-D масив JSON для контурного відображення в браузері. Перевірка самодостатня й сильніша за навчальний вивід: кожен вихід Ламберта проходить круговий шлях через propagator Кеплера (він має повернутися в r2), а мінімум «porkchop» звіряється з аналітичним нижнім порогом C3 переходу Гомана для двох компланарних колових орбіт. Kshana позиціонує це як шар симуляції продуктивності над GMAT/Orekit, а не заміну (багатовиткові гілки та реальна планетна ефемерида лишаються поза межами). Десять тестів.
• Повний 17-станний тісно зв'язаний UKF GNSS/INS з лічбою шляху на квантовому CAI. Новий src/fusion/tightly_coupled17.rs несе повний інерціально-навігаційний стан, який оцінює тісно зв'язаний фільтр, — [position, velocity, attitude-error, accelerometer bias, gyro bias, clock bias, clock drift] (17 станів) — поширений через безплатформну механізацію, яку керують виміряна питома сила та кутова швидкість, з малокутовим обертанням тіло→інерціальна C ≈ I + [ψ×], так що похибка орієнтації зв'язується з горизонтальним прискоренням (стандартний нахиловий зв'язок INS). Під час втрати GNSS він іде лише на IMU; шум процесу випадкового блукання швидкості — це виведений q_va акселерометра на інтерферометрі з холодними атомами (crate::inertial::quantum_imu), тож дрейф лічби шляху обмежений квантовим датчиком — 120-секундна втрата лишається обмеженою кількома сотнями метрів проти кілометрів, яких досяг би вільний INS навігаційного класу. Оновлення псевдодальності/швидкості зміни дальності проходить через спільний ансамблевий фільтр (unscented) (з α = 1 для добре обумовлених ваг за такого розміру стану). П'ять тестів: тотожність моделі вимірювання, інтегрування сталої швидкості ідеальним IMU, допомога GNSS, оцінювання зміщення акселерометра та еталонна 120-секундна втрата, обмежена CAI.

0.11.0 - 2026-06-05#

Змінено#

• Чесне формулювання квантового позиціонування. Основний опис тепер звучить як «симулятор стійкості PNT із моделями продуктивності квантових датчиків» послідовно в гаслі README, рядку цитування, CITATION.cff (назва + анотація) та графіці банера — замість вільнішого маркетингового формулювання «гібридний квантово-класичний симулятор PNT». Розділ README Що це / чим не є отримує явне твердження про межі «Це не (ще)» (не рушій фізики атомної інтерферометрії з перших принципів, не приймач GNSS/розв'язувач PVT, не інструмент проєктування місій), а новий ROADMAP.md верхнього рівня робить квантовий фізичний шар пунктом P2 (фаза CAI Маха–Цендера, проєкційний шум, тензор вібрації), щоб читачі знали: фізику з перших принципів заплановано й вона буде, а не покинута. Жодної зміни поведінки чи API.

Додано#

• Дослідження компромісів проєктування угруповання: перебір конструкцій Walker із фронтом Парето, JSON часу повторного відвідування та субкілометрова перевірка за формулою Walker. src/walker.rs отримує walker_design_sweep, що запускає сітку planes × sats_per_plane (наприклад, компроміс 3×3) за сталого нахилу та табулює для кожної конструкції частку покриття, найгірший PDOP і максимальний/середній проміжок між повторними відвідуваннями; pareto_front позначає недомінантні конструкції (менше супутників, більше покриття, нижчий PDOP, коротше повторне відвідування), а WalkerDesignReport::to_json серіалізує комірки та фронт Парето — разом із полями часу повторного відвідування — у JSON. Нова перевірка прив'язує генератор до формули Walker i:T/P/F: супутники з однаковим слотом у сусідніх площинах переходять один в одного точним обертанням R_z(2π/P) з точністю до 1 км за повні 24 год поширення SGP4 (коротко­періодичне «дихання» J2 є спільним і скасовується), а слоти в площині підтверджено рознесеними на 2π/S у середньому. Спирається на зафіксований реальний знімок Celestrak gps-ops від 2021-07-28 (scenarios/orbit-sgp4-gps.toml, використовується тестами покриття сценаріїв і кругового шляху SP3).
• Розширене передавання часу й частоти: TWSTFT, спільний огляд GNSS, PPP, оптичне, підгонка степеневого закону IEEE-1139 та ансамбль годинників. Новий src/timetransfer_adv.rs будує робочі методи передавання на основі наявних замкнених форм Саньяка/спільного огляду та інструментів стабільності Аллана. twstft_sagnac дає поправку Саньяка для двостороннього передавання часу й частоти через супутник (TWSTFT) як суму трьох ділянок контуру, що точно дорівнює замкненій формі BIPM Δt = 2·A·ω_E/c² (перехресно перевірено незалежним twstft_sagnac_bipm); run_twstft видає однодобовий ряд T_A − T_B та його TDEV. gnss_common_view_series бере одинарні різниці двох синтетичних наземних станцій, так що годинник супутника скасовується. iono_free_combination + ppp_receiver_clock — безіоносферна комбінація PPP і розв'язання годинника приймача відносно синтетичної істини класу SP3, що точно скасовує першопорядкову іоносферу. rytov_variance, fried_parameter та модель lognormal_fading з одиничним середнім моделюють спричинену турбулентністю сцинтиляцію оптичної лінії у вільному просторі. fit_power_law_psd — повна підгонка п'яти коефіцієнтів IEEE-1139 h_α методом найменших квадратів до кривої дисперсії Аллана (усі п'ять канонічних шумових процесів одночасно) із зазначенням домінантного процесу для кожної декади τ. ensemble_timescale формує паперову шкалу часу зі зваженням за оберненою дисперсією, чия девіація Аллана строго нижча за найкращий годинник-внесок. 31 модульний тест; цілі перевірки — замкнені форми й синтетична істина — реальне завантаження BIPM Circular-T / IGS SP3 ще попереду.
• Карти іоносфери IONEX: розбір файла, інтерполяція в часі та відображення похилої обліковості. src/ionex.rs отримує parse_ionex, що читає формат файлів IONEX (визначення сітки в заголовку + блоки START/END OF TEC MAP) у послідовність IonexMap — нормалізуючи порядок широт файла з півночі на південь у TecGrid з додатним кроком і масштабуючи значення на 10^EXPONENT. interpolate_tec_in_time змішує дві послідовні карти на епоху запиту, а obliquity_factor / slant_tec відображають вертикальний TEC на похилий промінь через однощаровий тонкооболонковий коефіцієнт M(z) = 1/cos z′ (sin z′ = (Rₑ/(Rₑ+H))·sin z). Разом із наявною сіткою ця модель перетворює виміряну глобальну карту іоносфери IGS на придатну до використання похилу затримку.
• Проєктування угруповання: розмір за смугами покриття + порівняння кількох угруповань. src/walker.rs отримує min_satellites_streets_of_coverage — ідеалізований розв'язувач мінімальної кількості супутників за смугами покриття: з наявного півкута покриття λ і півширини смуги c він визначає розмір майже полярного угруповання для безперервного одинарного глобального покриття як p = ⌈π/(2c)⌉ площин (наприклад, 4-супутникова площина на висоті GPS потребує 2 площин, 8 супутників) і повідомляє None, коли супутників надто мало для утворення безперервної смуги. compare_constellations — інструмент порівняння кількох угруповань: він оцінює кожну названу конструкцію Walker на тій самій станції/вікні через pdop_sweep і повертає їхні покриття / PDOP / розмір поруч. Чесна межа: точна на шві поправка Райдера на межі площин, що обертаються назустріч, і 3-D глобус покриття лишаються наступними кроками.
• Багатошарове виявлення спуфінгу: паритетний детектор узгодженості RAIM + злиття шарів. src/spoof_monitors.rs отримує третій і останній шар виявлення та етап злиття: parity_raim_test підганяє методом найменших квадратів розв'язок положення/годинника до надлишкового набору псевдодальностей і перевіряє залишкову зважену суму квадратів проти порога χ²(m−4) — позначаючи зміщену підмножину супутників і правильно залишаючи синфазне зміщення (поглинуте годинником приймача) невидимим для RAIM, а не замаскованим. fuse_spoof_layers об'єднує паритетний шар, шари AGC і SQM в одне зважене рішення, що фіксує, які шари спрацювали. Монте-Карло характеризує детектор: емпірична P_fa ≈ 0,068 проти розрахункової точки 0,05, а пропущене виявлення спадає з 0,885 за зміщення спуфінгу 2σ до 0,16 за 8σ. Чесна межа: перехресна перевірка за конкретними опублікованими тестовими векторами спуфінгу (Spirent / ION GNSS+) потребує тих зовнішніх наборів даних і лишається наступним кроком.
• Ансамбль перевірки зв'язаного та розв'язаного фільтра Калмана. Монте-Карло зі 100 випробувань у src/fusion/coupled.rs кількісно оцінює користь від збереження перехресної коваріації положення↔годинник: точна вбудована розв'язана база (звірена побітово з наявним CoupledPntFilter) обробляє ті самі дані з обнуленими перехресними блоками, і після майже виродженої псевдодальності та виправлення лише годинника зв'язаний фільтр відновлює положення з 2,97 м RMS проти 48,8 м розв'язаного, вигравши 97 зі 100 випробувань — виправлення годинника уточнює положення лише через кореляцію, яку розв'язаний пакет відкидає. Це завершує набір перевірок коректності фільтра Калмана (форма Йосипа, безпека PSD, узгодженість NEES/NIS, а тепер і ансамбль зв'язаного фільтра).
• Конвеєр визначення орбіти (пакетний + послідовний). Новий src/orbit_determination.rs відновлює орбітальний стан супутника [r, v] зі стеження за дальністю наземною станцією, поєднуючи три наявні частини: силова модель двох мас + J2 (src/forces.rs) та інтегратор RK4 (src/integrator.rs) поширюють стан-кандидат на дузі, модель вимірювання дальності передбачає дальність кожної станції, а пакетний коректор Гаусса–Ньютона (src/batch_ls.rs) виводить кандидата на стан найкращої підгонки (determine_orbit_batch). Та сама динаміка та модель дальності також керують послідовним рекурсивним визначенням на наявному фільтрі unscented (determine_orbit_sequential). Чотири тести перевіряють його: передбачення дальності на дузі; пакетне відновлення із субметровою / мм·с⁻¹ точністю з безшумових дальностей; пакетне відновлення до ~2 м із залишком після підгонки на порозі шуму 5 м (ознака узгодженої підгонки найменших квадратів); та послідовне відновлення в межах десятків метрів. Чесна межа: вимірювання швидкості зміни дальності/Доплера та кутів, аналітична матриця переходу стану J2 і маскування видимості станцій — наступні кроки.
• Тісно зв'язаний навігатор UKF GNSS/INS. Новий src/fusion/tightly_coupled.rs підключає наявне ядро фільтра Калмана unscented (src/fusion/ukf.rs) до робочого тісно зв'язаного навігатора на восьмистановому [px,py,pz,vx,vy,vz,b,d] (положення/швидкість ECEF плюс зміщення та дрейф годинника приймача в одиницях дальності). Він приймає сирі виміри супутників — pseudorange (ρ = |p − sᵢ| + b) та range_rate/Доплер (ρ̇ = (p − sᵢ)·(v − ṡᵢ)/|p − sᵢ| + d) — а не попередньо сформоване визначення положення, тож TightlyCoupled (з propagate/propagate_orbital/ update_gnss) продовжує коригувати менш ніж із чотирма супутниками і долає втрати GNSS на своїй поширеній динаміці. П'ять тестів перевіряють його наскрізно, зокрема сценарії приймання віхи: геометрія псевдодальності/Доплера проти ручних значень; безшумова збіжність до субметрової точності на п'яти супутниках; випадок із трьома супутниками, що збігається з ~212 м до ~13 м, де знімковий PVT навіть не можна сформувати; 120-секундна втрата зі сталою швидкістю в межах 50 м; і — головне приймання — 30-хвилинний вигнутий прохід LEO (реальна орбіта двох мас + J2) зі 120-секундною втратою GNSS, утримана на 0,77 м RMS проходу і 2,9 м у найгіршому випадку під час втрати. Цей орбітальний рух по інерції поєднує наявну гравітаційну силову модель (src/forces.rs) та інтегратор RK4 (src/integrator.rs) у модель процесу UKF (propagate_orbital), тож фільтр слідує кривизні орбіти — чого не може рух по інерції зі сталою швидкістю (одна лише кривизна становить ~58 км за 120 с на LEO). Чесна межа: орбітальний рух по інерції використовує силову модель двох мас + J2, а не сиру питому силу IMU (для безтягової орбітальної платформи вони збігаються); додавання стану похибки безплатформного IMU та поправок іоносфери/тропосфери в контурі лишаються наступними кроками.
• Модель вимірювання зіставлення карти (навігація за рельєфом / гравітацією). Новий src/mapmatch.rs надає модель вимірювання, що перетворює наявний фільтр частинок послідовного важливого перевибірки (src/particle_filter.rs) на робочий навігатор без GPS: field_likelihood (гауссова правдоподібність збігу поля) і map_match_likelihood, що бере відлік будь-якого географічно прив'язаного еталонного поля — висоти рельєфу (TRN) або гравітаційної аномалії — в положенні частинки й зважує її за узгодженістю з виміряним значенням транспортного засобу. Поле — будь-який семплер Fn(lat, lon) -> value, тож він поєднується з білінійною сіткою в src/ionex.rs або замиканням. Два тести фіксують його: правдоподібність має пік (=1) при ідеальному збігу й спадає до e^(−½) на одній сигмі, а фільтр частинок над виразною синтетичною ділянкою рельєфу відновлює справжнє положення в межах 0,1. Чесна межа: реальні еталонні карти (висота SRTM, гравітаційна аномалія EGM/EIGEN) та їхні завантажувачі — наступні кроки.
• Цілісність цисмісячного PNT (місячний ARAIM). Новий src/lunar.rs застосовує земний рушій ARAIM MHSS до навігаційної служби для Місяця у стилі LunaNet із місячними параметрами (σ_URE ≈ 30 m проти 0,6 м для GPS, P_sat ≈ 1e-4): місячні сталі, селеноцентричний базис Схід/Північ/Угору та допоміжна функція геометрії неба, а також lunar_araim (HPL/VPL). Три тести фіксують його — ортонормований селеноцентричний базис, геометрію похилої дальності та точне лінійне масштабування рівня захисту за σ_URE (місячні 30 м дають у 50 разів більший рівень захисту, ніж та сама геометрія за 0,6 м для GPS — кількісна причина, чому цілісність PNT для Місяця складна). Чесна межа: точна ефемерида LANS NRHO, бюджет похибок сигналу в просторі та редукція системи відліку MCI↔MCMF — наступні кроки.
• Двочастинні (високоточні) юліанські дати. Новий src/jd2.rs додає Jd2 — юліанську дату, розділену на цілу day і дробову frac у [0,1) (конвенція SOFA/hifitime), з new/from_parts/add_seconds/diff_seconds/total. Різниці близьких епох лишаються точними до межі f64, тоді як JD з одним f64 втрачає ~50 мкс біля J2000. Чотири тести фіксують це: круговий шлях, нормалізацію дробу, точне відновлення мікросекунди (з поруч продемонстрованою відмовою варіанта з одним f64) та адитивну/зворотну арифметику секунд.
• Записувач CCSDS OMM (Orbit Mean-Elements Message). Новий src/omm.rs доповнює записувач ефемерид oem повідомленням про середні елементи: OmmFile::from_tle відображає середні елементи SGP4/TLE в одиниці OMM (середній рух в оборотах/добу, кути в градусах, плюс BSTAR), а to_omm_kvn серіалізує стандартну форму KVN CCSDS 502.0-B-2 — тож орбіту Kshana може спожити будь-який інструмент, що розуміє OMM, замість нестандартного TLE. Два тести фіксують перетворення одиниць TLE→OMM (≈ 15,5 обороту/добу, нахил 51,6° тощо) і наявність обов'язкових ключових слів KVN. Чесна межа: форма KVN і відображення TLE постачаються тут; відображення XML (ndm/omm) і круговий шлях через еталонний парсер — наступні кроки.
• Фільтр частинок послідовного важливого перевибірки. Новий src/particle_filter.rs додає нелінійний, негауссів оцінювач, що стоїть за навігацією з картою без GPS (зіставлення за рельєфом або гравітаційною картою): predict (поширення частинок крізь динаміку + гауссів шум процесу), update (перезважування за правдоподібністю вимірювання на частинку), систематичний resample, монітор виродження effective_sample_size та оцінка зваженого середнього. Шість тестів точно фіксують детерміноване ядро — ESS у діапазоні 1…N, систематичний перевибір, що вибирає індекси пропорційно вазі, опукла комбінація зваженого середнього, гауссова правдоподібність, що тягне оцінку до вимірювання, поведінку «перевибір до рівномірного» та детермінованість predict із зерном (seed). Чесна межа: рушій постачається тут; еталонні карти (висота SRTM, гравітаційна аномалія EGM) і модель вимірювання карти — наступні кроки (білінійний семплер сітки ionex міг би однаково обслуговувати гравітаційну/рельєфну карту).
• Карти іоносфери TEC у стилі IONEX. Новий src/ionex.rs додає вимірювану іоносферу як альтернативу моделі Klobuchar з ефемеридного повідомлення: TecGrid (регулярна сітка за широтою/довготою вертикального TEC, глобальна карта іоносфери IGS) із білінійною інтерполяцією в точці перетину (vtec_at, із обмеженням за межами сітки) та затримкою першого порядку Δ = 40.3·TEC/f² (vtec_to_delay_m, delay_at). Його закріплюють чотири тести: 1 TECU ≈ 0.162 m на L1 із масштабуванням 1/f², точна інтерполяція у вузлах, білінійні середини, що усереднюють кути, та запити поза сіткою з обмеженням на краях. Чесні межі: тут постачаються сітка та інтерполяція; розбір формату файлів IONEX, інтерполяція в часі між картами та функція проєкції на похилий напрямок — завдання наступних етапів.
• Геометричні поправки передавання часу (Саньяк + спільне спостереження GNSS). Новий src/timegeo.rs додає два детерміновані ефекти, які має враховувати справжнє порівняння годинників, доповнюючи стохастичну двосторонню модель у timetransfer: sagnac_correction (Δt = (ω_E/c²)·(x₁y₂ − x₂y₁), затримка через обертання Землі — десятки нс для континентальних баз) та common_view_offset, одинарна різниця спільного спостереження GNSS, що точно скасовує похибку годинника супутника й відновлює зсув між станціями. Три тести закріплюють їх на точних еталонах: ≈ 33 нс Саньяка для екваторіальної чверті обороту, антисиметрія та нульові радіальні/полярні випадки, а також точне скасування годинника супутника. Чесні межі: повний бюджет затримок транспондера/апаратури TWSTFT та розв'язок передавання часу PPP без іоносфери — завдання наступних етапів.
• Модель сил на орбіті (двотільна + J2). Новий src/forces.rs додає модель прискорення, яку інтегрує чисельний пропагатор: two_body_accel (−μ·r/|r|³), збурення сплюснутості j2_accel (замкнена форма в ECI) та gravity_accel, що їх підсумовує — поєднуйте її з src/integrator.rs як f(t,[r;v]) = [v; a(r)]. Він також відкриває аналітичні світські швидкості J2 (j2_secular_rates): регресію вузла Ω̇, обертання апсид ω̇ та дрейф середньої аномалії Ṁ. Шість тестів закріплюють фізику на точних еталонах: μ/r² для двотільного члена, замкнена форма J2 на екваторі (~10⁻³ від двотільної величини), критичний нахил (63,4349°), що заморожує перигей (ω̇ = 0), регресія вузла МКС (Ω̇ ≈ −5°/day) та східний дрейф ретроградної сонячно-синхронної орбіти. Чесні межі: лише двотільна модель + J2; J3–J6, опір, тиск сонячного випромінювання та третє тіло — завдання наступних етапів.
• Постійні посилання на сценарії для поширення. Новий src/permalink.rs додає кодек Base64 за RFC 4648 без залежностей (стандартний алфавіт +/ із заповненням та безпечний для URL алфавіт -_ без заповнення) і обгортки encode_scenario / decode_scenario, щоб TOML майданчика можна було закодувати в параметр запиту ?s= і поширити як URL. Для браузера відкрито як прив'язки wasm encode_permalink / decode_permalink. Чотири тести закріплюють його на канонічних векторах RFC 4648 ("foobar" → "Zm9vYmFy" тощо), двостороннє перетворення сценарію з безпечним для URL алфавітом (без +///=, які треба екранувати), відхилення недійсних символів та двостороннє перетворення всіх 256 байтів. Чесні межі: тут постачаються кодек і прив'язки; інтерфейс кнопки «Поділитися» на майданчику, багатосерійна діаграма Plotly/D3 та режим порівняння A/B — завдання наступних етапів.
• Пакетний метод найменших квадратів Гаусса–Ньютона (пакетний диференціальний коректор). Новий src/batch_ls.rs додає ядро оцінювання, на якому тримається пакетне визначення орбіти (або будь-яке підганяння параметрів): gauss_newton лінеаризує задану користувачем модель h(x) якобіаном за центральними скінченними різницями, формує й розв'язує зважені нормальні рівняння (HᵀWH)·Δx = HᵀW·(z − h(x)) (повторно використовуючи перевірену обернену матрицю) та ітерує до збіжності з вагами для кожного вимірювання. Чотири тести закріплюють його: лінійне підганяння прямої, що досягає точного розв'язку зважених найменших квадратів, нелінійне підганяння a·exp(b·t), що відновлює справжні параметри, 3-D багатостанційне визначення за дальностями, що відновлює відому позицію із безшумних дальностей (різновид визначення орбіти), та відхилення недовизначених або неузгоджених входів. Чесні межі: це загальний рушій коректора; специфічна для орбіти модель вимірювань дальності/швидкості зміни дальності/азимуту-висоти, аналітична матриця переходу стану J2 та валідація за опублікованими випадками — завдання наступних етапів.
• Монітори спуфінгу на РЧ-рівні (потужність AGC і SQM). Новий src/spoof_monitors.rs додає два незалежні детектори спуфінгу у вхідному каскаді приймача, що доповнюють монітор часового спуфінгу із залученням годинника в spoof: монітор потужності AGC (combine_power_dbm некогерентна сума потужностей + AgcMonitor), який сигналізує про надлишкову прийняту потужність, яку додає передавач спуфінгу понад настроюваний запас у дБ, та монітор якості сигналу (bpsk_autocorr трикутна автокореляція коду + SqmMonitor), який сигналізує про дисбаланс корелятора «раннього мінус пізнього», що вносять багатопроменевість/meaconing/повторення. Чотири тести закріплюють точні замкнені форми (3,01 дБ для подвоєння потужності, сукупність 10·log10(N), трикутна R(τ)=1−|τ| та поріг тривоги раннього/пізнього в 10 %). Чесні межі: повний детектор паритету спуфінгу на узгодженості RAIM, багаторівневе злиття виходів моніторів та валідація за опублікованими векторами спуфінгу Spirent/ION GNSS+ — завдання наступних етапів.
• Адаптивний чисельний інтегратор ЗДР. Новий src/integrator.rs додає першу частину чисельного пропагатора (орбітальне поширення в Kshana інакше аналітичне, SGP4/SDP4): загальний крок Рунге–Кутти четвертого порядку (rk4_step) для будь-якої системи першого порядку y' = f(t, y) та адаптивний драйвер (integrate), що контролює локальну похибку подвоєнням кроку (екстраполяція Річардсона) зі стандартним регулятором кроку 0.9·(tol/err)^(1/5) та логікою прийняття/відхилення. Шість тестів закріплюють його на точних розв'язках: експонента y' = y → e з точністю < 1e-9, зменшення похибки в ~16× на кожне половинне зменшення кроку, що доводить збіжність четвертого порядку, збереження енергії/повернення гармонічного осцилятора за повний період та адаптивний драйвер, що досягає жорсткого допуску зі змінними кроками. Чесні межі: це ядро інтегратора та його контроль похибки; вкладені таблиці Дорманда–Прінса RK5(4)/RKF7(8) та ієрархічна модель сил на орбіті (двотільна + J2–J6 + опір + тиск сонячного випромінювання + третє тіло), що роблять його NumericalPropagator, — завдання наступних етапів.
• Несцентований (сигма-точковий) фільтр Калмана. Новий src/fusion/ukf.rs додає масштабований несцентований фільтр Калмана (Julier і Uhlmann; Wan і van der Merwe) як загальний оцінювач із n станами над заданими користувачем функціями процесу та вимірювання — сигма-точковий оцінювач, який тісно зв'язаний навігатор GNSS/INS використовує, коли модель псевдодальності/Доплера сильно нелінійна, а якобіан EKF погіршується. Він містить допоміжну щільну лінійну алгебру (множник Холецького для розкиду сигма-точок, обернена матриця Гаусса–Жордана для коваріації інновацій) та оновлення P⁺ = P⁻ − K S Kᵀ без форми Джозефа. Шість тестів фіксують його, причому ключові використовують точну властивість: для лінійної моделі несцентоване перетворення відтворює фільтр Калмана з числовою точністю (передбачення, оновлення та повний цикл передбачення + оновлення збігаються з вручну запущеним лінійним KF, плюс 1-D аналітична перевірка байєсівської апостеріорної та тотожності Холецького/оберненої матриці). Чесні межі: це рушій оцінювача; 17-станний тісно зв'язаний навігатор GNSS/INS, модель вимірювань псевдодальності/Доплера та сценарій валідації на відсутність GNSS залишаються завданнями наступних етапів.
• Рівні захисту ARAIM для двох орбітальних угруповань. Новий araim_dual_raim розширює одноразовий збій Advanced RAIM (araim_raim) режимом збою всього орбітального угруповання за EU ARAIM / DO-316: поряд з гіпотезами без збою та збою окремого супутника кожне орбітальне угруповання (позначене для кожного супутника) додає одну гіпотезу, що одночасно вилучає всі його супутники, з апріорною ймовірністю P_const (новий DualFaultPriors { p_sat, p_const }). Кожна гіпотеза додає складову до тієї самої суми цілісності MHSS, тож VPL/HPL — це найменші межі, за яких сумарна P_HMI вкладається в бюджет за гіпотезами без збою + окремий SV + збій угруповання (розподіл Бонферроні хибних сповіщень ведеться за всіма N + C гіпотезами). За P_const = 0 результат побітово збігається з araim_raim; користувач з одним угрупованням отримує None щодо збою власного угруповання (його неможливо виключити) — саме тому покриття двома угрупованнями має значення. Чотири тести охоплюють еквівалентність, розширення рівня захисту, недоступність для одного угруповання та перевірку входів, повторно використовуючи наявну машинерію підрозв'язків із розділенням розв'язків.
• Прецесія IAU 2006 (кути Фукусіми–Вільямса та матриця зміщення-прецесії). Новий src/precession.rs реалізує прецесію IAU 2006 (P03; Capitaine, Wallace і Chapront 2003): чотири кути Фукусіми–Вільямса (γ̄, φ̄, ψ̄, ε̄_A) як поліноми за юліанськими сторіччями TT (fw_angles) та матрицю повороту зміщення-прецесії від GCRS до середньої на дату, побудовану з них за конструкцією SOFA iauFw2m (precession_matrix із допоміжними gcrs_to_mod / mod_to_gcrs). Це перший елемент інерціальної системи поверх наявної редукції frames на основі GMST. Вісім тестів перевіряють за замкненими опорними значеннями: середню нахиленість екліптики на J2000 ε̄ = 84381.406″ = 23.4392794°, опубліковані сталі члени кутів, накопичення загальної прецесії ψ̄ ≈ 5039.998″ за сторіччя, ортонормованість матриці та det = +1, значення поблизу одиничної (лише зміщення системи відліку) на J2000 та чистий кут повороту ≈ 1.40°/сторіччя. Чесні межі (ROADMAP.md): лише прецесія — нутація IAU 2000A із 678 членів, повний ланцюг TEME→GCRS та числова перехресна перевірка SOFA/ANISE на рівні µas/<10 м — завдання наступних етапів.
• Фізика акселерометра на холодноатомному інтерферометрі (CAI) з перших принципів. src/inertial/quantum_imu.rs моделює триімпульсний атомний інтерферометр Маха–Цендера з перших принципів, а не за даними з паспорта: ефективний хвильовий вектор k_eff = 4π/λ, фаза інтерферометра Φ = k_eff·a·T², квантовий проєкційний (дробовий) шум σ_Φ = 1/(C·√N), чутливість до прискорення на один постріл, спад контрасту C(t) = C₀·e^(−t/τ) і — головне — CaiAccelerometer::q_va(), що виводить PSD білого прискорення, яку класична AccelModel уже споживає, з кількості атомів, часу опитування та контрасту. Модель тепер охоплює також зв'язок з вібраціями — домінантний доданок у реальних пристроях: передавальну функцію «прискорення→фаза» інтерферометра |H(ω)| = (4/ω²)sin²(ωT/2) (accel_transfer_function), дисперсію фази за білої PSD σ_Φ² = k_eff²·S_a·T³/3 (vibration_phase_variance_white, з числовою перевіркою інтегралом по смузі vibration_phase_variance_band), ранг-1 проєкцію вздовж променя beam_axis_projection та CaiAccelerometer::vibration_phase_noise / vibration_limited_accel (остання зводиться до нижньої межі √(S_a/(3T)), що не залежить від k_eff). Одинадцять тестів перевіряють фізику вручну (Rb-87 k_eff ≈ 1.61×10⁷, Φ(1 g) ≈ 1.58×10⁴ rad, нижня межа дробового шуму σ_a ≈ 0.13 µg на постріл проти нижньої межі вібрацій ≈ 5,9 µg, закони масштабування 1/T², 1/√N і T³). Чесні межі в docs/QUANTUM.md: це охоплює нижню межу проєкційного шуму та режим, обмежений вібраціями, вище за неї; шум фази лазера, систематичні ефекти Коріоліса й світлового зсуву та сценарії валідації PHARAO/CARIOQA залишаються завданнями наступних етапів.
• Квантовий акселерометр CAI підключено до інерційного сценарію. Акселерометр в сценарії інерційного зчислення шляху тепер зводиться до нового ImuKind — Classical (наявний датчик із коефіцієнтами з паспорта) або QuantumCai, коли він має необов'язковий блок [cai] (CaiCfg: довжина хвилі, інтервал між імпульсами, кількість атомів, контраст, час циклу та необов'язкова vibration_psd платформи). PSD випадкового блукання швидкості датчика quantum_cai q_va виводиться з фізики інтерферометра — нижня межа дробового шуму плюс, якщо задано PSD вібрацій, внесок вібраційного обмеження в квадратурі — замість заданого коефіцієнта, а походження прогону фіксує, що шум виведено з фізики. Поле cai має вигляд skip_serializing_if = "Option::is_none", тож наявні сценарії його опускають і серіалізуються побайтово ідентично (хеш сценарію не змінюється). П'ять тестів охоплюють виведення, квадратурну суму вібрацій, вибір Classical/QuantumCai, стабільну за хешем серіалізацію та наскрізний прогін на CAI.
• Оптимізатор конструкції орбітального угруповання та геометрія «вулиць покриття». src/walker.rs отримує optimize_walker_design — безградієнтний сітковий оптимізатор, що шукає в просторі конструкцій {planes × sats × inclination} і повертає найкращу конструкцію Волкера за обраним DesignObjective — MinSatellitesForCoverage, MaxCoverage або MinWorstPdop — за вже перевіреним перебором PDOP (тест підтверджує, що він повертає переможця повного перебору). Плюс аналітичні замкнені форми вулиць покриття coverage_half_angle_rad (λ = arccos(Re/r·cos ε) − ε) і street_half_width_rad (cos c = cos λ / cos(π/s), Rider/Beste), вручну перевірені за підручниковою геометрією та такі, що виявляють прогалину недостатньої заселеності. Повний розв'язувач Райдера для мінімальної кількості супутників глобального покриття, 3-D глобус на майданчику та перехресна перевірка DOP зовнішнім інструментом залишаються завданнями наступних етапів.
• Експорт точних ефемерид SP3 з CLI. Розповсюджений сценарій орбіти/орбітального угруповання тепер можна записати у файл SP3-c: kshana <orbit.toml> --export-sp3 out.sp3, або export_sp3 = true у сценарії автоматично записує <scenario>.sp3 (api::export_sp3 / auto_export_sp3, OrbitClockScenario::to_sp3_string, необов'язкова epoch). Тест двостороннього перетворення (tests/sp3_export_roundtrip.rs) поширює орбіту зі справжнього знімка Celestrak gps-ops, експортує її, повторно розбирає й підтверджує, що відновлені позиції ECEF збігаються з істиною SGP4 протягом 24 год з точністю < 0,5 м (значно в межах допуску 10 м класу TLE). README описує роль взаємосумісності (RINEX → RTKLIB/gLAB, SP3 → продукти Ginan/точних орбіт).
• Зв'язаний фільтр Калмана годинника і позиції (перехресна коваріація блоків). src/fusion/coupled.rs CoupledPntFilter — це єдиний стековий фільтр [pos, vel, phase, freq] (оновлення у формі Джозефа), чиє вимірювання псевдодальності ρ = g·pos + c·phase + noise справді зв'язує блоки позиції та годинника — на відміну від двох незалежних двостанних фільтрів застарілого пакета злиття, що тримають перехресну коваріацію точно нульовою. Перевірено: спільна псевдодальність робить P[pos,phase] ненульовою; дві різні геометрії спільно розв'язують введені зсуви позиції та годинника, які одна дальність розділити не може; фіксація лише за годинником уточнює позицію через перехресну коваріацію (вигода, якої не можуть дати розв'язані фільтри); а NEES за Монте-Карло узгоджений із χ²(4). Це реалізація з 1-DOF (вимірність пакета злиття); 3-D розширення до 8 станів і підключення до запусковного пакета відстежуються як завдання наступних етапів.
• Моніторинг стану узгодженості фільтра Калмана (NIS/NEES). Оновлення коваріації двостанного фільтра годинника тепер у стабілізованій формі Джозефа `P⁺ = (I−KH)P(I−KH)ᵀ
  • KRKᵀ, which stays positive-semidefinite under extreme Q/R ratios (Cholesky-checked in CI at R=1e-26 / Q≈1e-30). A new src/filter_health.rsruns a Monte-Carlo consistency assessment (Bar-Shalom §5.4): pooled **NIS** (normalised innovation², target 1) and **NEES** (normalised estimation error², target 2) against 95% χ² bands, surfaced as afilter_health { nis_mean, nis_chi2_lower_95, nis_chi2_upper_95, nees_mean, nees_chi2_lower_95, nees_chi2_upper_95, consistent } block in the clock result JSON and as a green/amber card in the playground. A Q/R-mismatch sweep test proves the monitor flips to inconsistent when the process noise is mistuned by ×0.1–×10. Adds a general χ² quantile (detection::chi2_inv_cdf`, Wilson–Hilferty, звірено з таблицею).
• docs/PROVENANCE.md — єдина цитовна таблиця походження. Зводить кожен параметр датчика (годинники, інерційні, передавання часу), фізичну/алгоритмічну модель (орбіта, системи часу, системи відліку, іоно/тропо, цілісність, виявлення, глушіння, Аллан) і набір даних валідації (AIAA 2006-6753, Celestrak gps-ops) із його опублікованим джерелом — паспортом, статтею, ICD або стандартом — та чесною міткою зрілості (льотно-кваліфіковано / наземна лабораторія / космічна мета на наземній апаратурі). Має посилання з вступу README і таблиці документації; доповнює рядки provenance для кожного прогону, що вже супроводжують JSON результату.
• Типізований API сценаріїв. Диспетчеризація тепер іде за типізованим переліком ScenarioKind замість зіставлення сирого рядка kind (ScenarioKind::classify + вичерпна диспетчеризація), тож додавання пакета перевіряється під час компіляції. Нові типізовані поверхні поряд із незмінним run_toml, що повертає рядок: run_scenario(src) -> Result<RunOutput, KshanaError> зі структурованою таксономією помилок (InvalidInput / NonConvergence / Unsupported / IoError, кожна зі стабільним kind_tag()); трейт Scenario і точка розширення ExternalPack (пакет jamming підключено через неї як розібраний приклад); та інтроспекція list_scenario_kinds() (ім'я, опис, обов'язкові/необов'язкові поля для кожного виду). Прив'язки Python і WebAssembly отримують list_kinds() та error_kind(). Описано в docs/ARCHITECTURE.md.
• Справжнє орбітальне угруповання GPS + покриття робочої оболонки. scenarios/orbit-sgp4-gps.toml тепер постачається зі справжнім знімком Celestrak gps-ops (2021-07-28, 30 супутників) замість синтетичних TLE Волкера, з strict_checksum = true, тож він завантажується лише тоді, коли контрольна сума кожного TLE дійсна; scripts/fetch_tles.sh описує відтворюване оновлення, а README згадує джерело відкритих даних. Новий tests/scenario_coverage.rs перевіряє кожен пакет на ≥5 варіантах оболонки, стверджуючи скінченний/обмежений вихід, підтверджує, що нижня межа flicker-FM помітно погіршує вибіг годинника, коли її ввімкнено (тепер задано у трьох поставних сценаріях), і підтверджує, що фільтр злиття збігається за реалістичного ненульового зміщення акселерометра (у межах 3× від випадку з обнуленими зміщеннями), закриваючи прогалину реалістичності «злиття працює лише з обнуленими зміщеннями». docs/VALIDATION.md отримує таблицю робочої оболонки.
• Симуляція GNSS у вимірювальній області (вид gnss-sim). Пряма модель на рівні псевдодальності: для кожного видимого супутника вона синтезує ρ = geometric range + c·δt_rx − c·δt_sv + I + T + noise + multipath та Доплер L1, з однічастотною іоносферою Klobuchar (IS-GPS-200 §20.3.3.5.2.5) та зенітною тропосферою Saastamoinen, спроєктованою функцією відображення Niell (1996) — відкрито як блоки TOML [iono] і [tropo]. Залишки живлять миттєвий RAIM для HPL/VPL на кожну епоху, а масив JSON gnss_measurements[] несе псевдодальність, Доплер, C/N₀ та поправки іоно/тропо кожного SV. Прогін без шуму відтворює геометрію + поправки із субміліметровою точністю (тест CI). Нові src/gnss_sim.rs і scenarios/gnss-sim-raim.toml.
• Стохастичний детектор часового спуфінгу (вид spoof). Пакет спуфінгу тепер запускає справжній детектор замість детермінованого порівняння рампи з межею: чотири форми впровадження (linear_ramp, step_jump, meaconing, replay), двобічний тест енергії χ²₁ / Неймана–Пірсона за статистикою монітора із залученням годинника з порогом, заданим з цільового бюджету хибних тривог target_pfa, та ймовірність пропущеного виявлення P_md, що повідомляється як у замкненій формі, так і за Монте-Карло (mc_runs випробувань на гіпотезу — обидва погоджуються з точністю до кількох ×1/√N). Показник якості безпеки тепер 1 − P_md за операційно шкідливої (специфікаційної) величини. Нові src/detection.rs (хвостові функції Гауса, тест NP/енергії, Монте-Карло P_fa/P_md) і scenarios/spoof-meaconing.toml. Зворотна сумісність: голий [attack] rate_ns_per_s і далі приймається як лінійна рампа.

Змінено#

• Визначення показника якості безпеки (вид spoof): від аналітичної межі виявлюваності 1 − min_detectable/threshold до 1 − P_md стохастичного детектора. Поле security пакета годинника залишається швидшим аналітичним замінником.

Додано (продовження)#

• Модель РЧ-глушіння (вид jamming). Бюджетна модель завад на рівні лінії зв'язку, що перетворює потужність і геометрію глушника на втрату захоплення кожного супутника: відношення глушник/сигнал із втрат у вільному просторі та коефіцієнта підсилення приймальної антени в кожному напрямку, ефективне C/N₀ за стандартним рівнянням протидії глушінню (виграш обробки від стиснення спектра × коефіцієнт спектрального розділення Q; Kaplan і Hegarty §9,4) та настроюваний поріг супроводження, оцінений для орбітального угруповання Волкера як показник якості availability_under_jamming. Нові src/jamming.rs і scenarios/jamming-demo.toml. Чесні межі (без багатопроменевості, затінення рельєфом, AGC чи адаптивного занулення) описано в docs/CAPABILITY.md / docs/VALIDATION.md.
• Загальний N-D перебір параметрів для будь-якого виду сценарію (sweep-nd). Попередній N-D перебір стосувався лише пакета годинника. sweep-nd змінює крапкові ключі TOML сценарію [base] на декартовому добутку його осей, повторно диспетчеризує кожен вузол сітки звичайним шляхом запуску та зчитує одну або кілька метрик із результату за крапковим шляхом JSON — тож працює для кожного пакета (інерційного, gnss-ins, цілісності, спуфінгу, …) без прив'язки до типу Rust кожного пакета. Вузли сітки обчислюються паралельно в потоках ОС на нативних цілях (без доданої залежності); wasm переходить до послідовного виконання. Детерміновано й за рядками незалежно від кількості потоків. Новий приклад scenarios/sweep-nd-inertial.toml.
• Налаштовувана через TOML детермінована модель похибок IMU у пакеті gnss-ins. Триосьовий ланцюг похибок інерціальної системи без платформи (масштабний коефіцієнт, неспіввісність, g-чутливість, квантування, лінійний дрейф швидкості; IEEE Std 952-1997 §A.2, Groves 2013 §4,3) тепер доступний для кожного датчика зі сценарного файлу через необов'язковий блок [imu_*.error_model], нашарований на сталі зміщення вмикання. Якщо опустити блок, кожен датчик залишається чисто джерелом сталого зміщення, тож наявні прогони gnss-ins не змінюються. Це підключає раніше лише бібліотечну модель похибок до запусковного пакета та показника якості.

0.10.0 - 2026-06-04#

Змінено#

• Валідація на реальних даних. Багатосистемний розбірник навігаційних файлів RINEX, пропагатор GLONASS RK4 та зчитувач SP3 тепер перевіряються на справжніх файлах IGS/DLR (справжньому змішаному навігаційному файлі RINEX 3 та орбітальному продукті IGS SP3-c), а не лише на самостійно написаних зразках — із твердженням непорожніх наборів супутників і скінченних, фізично реалістичних за розміром позицій ECEF. Еталонні файли призначені лише для тестів (виключені з опублікованого крейта); див. tests/fixtures/igs/NOTICE.
• RAIM на геометрії реальної опорної орбіти. Ядра миттєвого розв'язку, розділення розв'язків (MHSS) та рівня захисту ARAIM тепер перевірено за геометрією реальної точної орбіти IGS (SP3), а не лише за синтетичними орбітальними угрупованнями: геометрію лінії візування побудовано з першої епохи SP3 на реальній наземній станції, а тести стверджують метрові рівні захисту, доступні для APV-I, що зміщення псевдодальності в 60 м спрацьовує на моніторі χ², що розділення розв'язків ідентифікує несправний супутник і що рівні ARAIM відповідають виділеній P_HMI. Закриває прогалину «перевірено лише на синтетичній геометрії» (паритет gLAB в області приймача на повній дузі RINEX залишається пунктом дорожньої карти — для нього потрібен розв'язок за псевдодальністю).

Додано#

• Довірчі інтервали для кожного вузла N-D перебору параметрів (sweep::nd_sweep_ensemble). Кожен вузол сітки N-вимірного перебору на декартовому добутку тепер можна оцінювати як ансамбль Монте-Карло із зерен, повідомляючи середнє метрики, перцентилі та бутстреп-ДІ за перцентилями 95% для кожного вузла (для обох годинників) — статистично чесний перебір замість одного випадіння на вузол. Повторно використовує механізм ансамблю/бутстрепа (metric_stat); детерміновано; runs = 1 точно зводиться до одно-зернового nd_sweep. (Узагальнення перебору на всі пакети, пов'язане з рефакторингом типізованого сценарію, та паралельне виконання лишаються.)
• Перехресна перевірка конвеєра шумів IMU за NaveGo (tests/navego_imu_crossval.rs). Зовнішня перехресна перевірка за NaveGo (інструментарій INS/GNSS з відкритим кодом від R. Gonzalez): відтворює синтетичний цикл із navego_example_allan.m на опублікованому еталонному профілі Microstrain 3DM-GX3-35 і підтверджує, що наша оцінка перекривної ADEV відновлює коефіцієнти випадкового блукання швидкості та кута за NaveGo (ADEV(1 s) = σ·√dt) з відхиленням менш як 5% та з очікуваним нахилом −1/2 для білого шуму. (Записаний журнал STIM300 .mat обсягом 40 МБ не завантажується: це обмежено бінарним форматом.)
• Тісно зв'язане оновлення GNSS/INS (за псевдодальністю). GnssInsEkf::update_tightly_coupled (і обгортка ClosedLoopInsGnss::fuse_tightly_coupled) реалізують раніше відсутнє вимірювання в області дальності: інновація — це різниця між прогнозованою дальністю від положення за INS до кожного супутника та виміряною псевдодальністю, з якобіаном лінії візування за похибкою положення. Оскільки кожен супутник — це скалярне вимірювання, фільтр продовжує коригування за менш ніж чотирьох супутників, коли вільно зв'язаного рішення PVT не існує. П'ять тестів охоплюють обнулення за чотирьох супутників, корекцію за двох супутників (PVT неможливий), спостережуваність уздовж лінії візування за одного супутника та перевірку вхідних даних. Лише псевдодальність; фаза несівної та явний стан годинника приймача залишаються в дорожній карті. Невикористану функцію cargo tight_coupling (яка закривала стару заглушку помилки) вилучено.
• Пакет сценаріїв вільно зв'язаного GNSS/INS (kind = "gnss-ins", src/fusion/pack.rs). Поєднує тривісний стрепдаун-навігатор і 15-станову EKF похибок (closed_loop / gnss_ins_ekf) у сценарій, який можна запустити, з показником якості: EKF підлаштовує механізацію під зашумлені виправлення GNSS, поки покриття є, а потім продовжує рух під час відсутності сигналу, замінюючи скидання за істинними даними в застарілому скалярному пакеті з 1 ступенем свободи справжнім злиттям. Результат містить ряд злитої горизонтальної похибки, оцінений показник якості положення (доступність / RMS під час відсутності сигналу / holdover) та RMS вільної INS у розімкненому контурі для порівняння; пара квантового та класичного IMU відрізняється лише істинним зсувом. Запускається з точки входу CLI/Python/wasm із прикладом scenarios/gnss-ins.toml. Чесне формулювання: лише вільний зв'язок, одна детермінована траєкторія, а злита похибка під час відсутності сигналу обмежена знизу похибкою початкової орієнтації під час передавання (тому не стверджується, що вона масштабується із зсувом): надійні висновки такі: злиття перевершує автономне числення шляху для зміщеного датчика, а датчик із меншим зсувом краще тримається автономно.
• Проєктування орбітального угруповання на основі перевіреного ядра SGP4 (src/walker.rs). Новий модуль walker видає спроєктований візерунок Walker-delta (i: T/P/F) як середні елементи SGP4, тож синтетичне орбітальне угруповання поширюється тим самим шляхом SGP4, який перевірено до 4,12 мм за векторами AIAA 2006-6753, а не аналітичним кеплерівським генератором. Поверх нього: pdop_sweep складає таблицю покриття та медіанного/найгіршого PDOP за сіткою проєктів {planes × sats × inclination}, а coverage_revisit повідомляє частку покриття та проміжки між прольотами (найгірший/середній) для наземної точки. Перевірено фізичними монотонностями, яких має дотримуватися компромісне дослідження (більше супутників ⇒ вище покриття, нижчий PDOP, коротший проміжок між прольотами). Окремо як тестову фікстуру додано справжній знімок TLE Celestrak gps-ops (2021-07-28, 30 діючих супутників GPS), і шлях геометрії реальні TLE → SGP4 → ECEF перевірено за ним (уся оболонка MEO в межах 1%, дев'ять супутників у полі зору за PDOP 1,64) поряд з наявними шляхами реальних даних SP3 і RINEX.
• Ефективні ступені свободи, специфічні для типу шуму, для довірчих інтервалів Аллана. allan::edf_overlapping_adev реалізує замкнені формули з NIST SP 1065, таблиця 5 (простий набір Stable32) для всіх п'яти канонічних типів степеневого шуму: білий/фліккер PM, білий/фліккер FM, випадкове блукання FM. Вони замінюють консервативну кількість без перекриття як ступені свободи χ². Нове перелічення PowerLawNoise і функція classify_power_law визначають домінантний тип за нахилом модифікованої девіації Аллана запису (MDEV відрізняє білий PM від фліккер-PM там, де ADEV не може), а overlapping_adev_curve тепер додає до кожної точки експортованої кривої ADEV визначений тип шуму, його edf та 95% довірчу смугу (AdevPoint отримує noise/edf/ci_lo/ci_hi, адитивно зі значеннями serde за замовчуванням). Перевірено двома способами: п'ять формул збігаються зі значеннями, обчисленими вручну, до 1e-12, а ансамбль Монте-Карло білого FM із 4 000 записів підтверджує, що формула передбачає фактичний edf хі-квадрат оцінювача в межах 20% (і що вона суттєво краща за консервативну кількість). Вісім нових тестів.
• Стохастична модель двостороннього передавання часу. timetransfer::TwoWayLink замінює вибірник лише з білим шумом фізично обґрунтованою моделлю: взаємна (синфазна) затримка шляху скасовується в оцінці (m_AB - m_BA)/2 (two_way_offset_estimate, тож два незалежні односторонні вимірювання усереднюються до 1/sqrt(2)), а залишок — це невзаємна диференціальна затримка, змодельована як кольоровий процес білого FM + випадкового блукання FM (перевірений ClockModel), що дає ряду похибки синхронізації реалістичну сигнатуру Аллана (sigma_y^2(tau) = q_rw*tau/3) замість плоского білого шуму. LinkCfg отримує q_wf_s/q_rw_s (значення serde за замовчуванням 0 ⇒ стара поведінка лише з білим шумом, біт у біт), показник якості лінії повідомляє adev_tau0 (девіація Аллана моделі на базовому кроці), а сценарій/CLI timetransfer її показують. Еталонний показник якості перезафіксовано. Шість тестів із виведенням вручну (скасування синфазної складової, двосторонній виграш sqrt(2), закон RWFM tau/3 через власний step() лінії, еквівалентність старій поведінці за q=0, детермінованість і наскрізна доступність показника якості).
• Числова відповідність Stable32 для оцінювачів родини Аллана (NBS14). tests/allan_reference.rs перевіряє оцінювачі перекривної ADEV, модифікованої ADEV, девіації часу та перекривної девіації Адамара за еталонними девіаціями Stable32 для канонічного набору даних NBS14 (W. J. Riley, Handbook of Frequency Stability Analysis, NIST SP 1065, ~с. 107) за tau = 1, 2 з відносним допуском 1e-4 — фактична згода ~1e-6. Це прив'язує математику оцінювачів до фактичної еталонної реалізації, а не лише до аналітичної самоузгодженості самих оцінювачів. Використано лише публічні еталонні числа; стороннього коду немає.
• Вертикальна діаграма цілісності Stanford, експортована сценарієм integrity. Сценарій integrity, який можна запустити, тепер експортує вертикальну діаграму Stanford(-ESA) разом із картою доступності HPL/VPL: на кожній захищеній епосі згенерована із зерном, відтворювана вибірка помилки дальності без несправності відображається через геометрію на фактичну вертикальну похибку положення та класифікується за VPL і вертикальним порогом тривоги (Available / System-Unavailable / Misleading / Hazardously-Misleading). Діаграма (точки за епохами + кількості за областями) міститься в JSON результату, а кількості подій цілісності / HMI — у підсумку CLI, тож класифікатор Stanford, раніше доступний лише як бібліотека, досяжний наскрізно. IntegrityScenario отримує поле seed (за замовчуванням 0), що керує реалізацією похибки; сама карта доступності залишається лише геометричною і не залежить від зерна.
• Бюджет ризику цілісності ARAIM (P_HMI) для рівнів захисту. raim::araim_raim виводить горизонтальний і вертикальний рівні захисту з явного бюджету ризику цілісності, а не з фіксованого множника K_md: для рішення за всіма видимими супутниками та кожного підрішення з виключенням одного супутника вона будує (prior, detection threshold, σ) для кожного режиму за кожною віссю, після чого araim_protection_level знаходить найменший PL, сумарна ймовірність небезпечно оманливої інформації якого (araim_integrity_risk, P_HMI = Σ_k p_fault,k · Q((PL − T_k)/σ_k), Blanch et al. Baseline ARAIM) відповідає виділеному P_HMI. Результат повідомляє ризик цілісності, який рівні фактично досягають, тож користувач може явно обмінювати цілісність на поріг тривоги. Шість тестів із виведенням вручну (замкнені формули для одного режиму без несправності та з порогом, підсумовування/монотонність за кількох режимів, наскрізний захист без несправності, де у 10⁵ раза жорсткіший бюджет піднімає PL, виявлення/ідентифікація несправності та поріг надлишковості для шести супутників). Одиночна несправність MHSS — базова лінія ARAIM; одночасні несправності кількох підмножин SV, режим несправності всього орбітального угруповання та перевірка за еталонним набором даних gLAB задокументовані як розширення.
• Двошвидкісна компенсація coning/sculling для стрепдаун-механізації. inertial::mechanization::coning_sculling_compensate згортає високочастотні складові coning (орієнтація) та обертання+sculling (швидкість) з упорядкованих приростів IMU підінтервалів грубого оновлення, тож NavState::step_increments помірної частоти відтворює рух, випрямлений вібрацією, який грубий крок за сирими сумами пропускає. Перевірочний тест веде середовище coning+sculling на 10 Гц протягом 60 с і порівнює істину з високою частотою, наївне грубе інтегрування та грубе інтегрування зі згортанням: згортання зменшує похибку положення приблизно в 18 раза (від метрів наївного дрейфу до субдециметрів), підтверджуючи, що складові coning/sculling є суттєвими. Псевдонім типу ScalarErrorBudget називає старий 1-DOF AccelModel тим, чим він є, на відміну від тривісного навігатора NavState.
• Аналізатор файлів спостережень RINEX. Новий модуль rinex_obs читає файл спостережень RINEX 3.0x / 4,00 — фактичні вимірювання приймача — і завершує пару RINEX разом із наявним аналізатором навігаційних повідомлень. parse_obs декодує заголовок (версія/тип, переліки SYS / # / OBS TYPES для кожної системи з рядками продовження, наближене положення, інтервал, час першого спостереження) і записи кожної епохи для кожного супутника: псевдодальність, фаза несівної, Доплер і потужність сигналу, з ключами за кодом спостереження RINEX 3 (C1C, L1C, …) разом із прапорцями втрати захоплення (LLI) та потужності сигналу (SSI), причому порожнє поле зберігається як відсутнє, а не як нуль. Чесний обсяг: це приймання у стандартному форматі (реальний журнал спостережень RTKLIB/gLAB/станції IGS на вході, типізовані вимірювання на виході), а не рушій позиціонування: тут немає ні рішення за псевдодальністю, ні PPP, ні RTK.
• Засіб запису CCSDS OEM (Orbit Ephemeris Message). Новий модуль oem експортує пропаговане орбітальне угруповання як чинне повідомлення CCSDS 502.0-B OEM 2,0 — формат ефемерид KVN, який приймають GMAT, Orekit, STK і більшість інструментів динаміки польоту. OemFile::from_propagators дискретизує інерційний (TEME) стан кожного супутника — положення і швидкість, узяті прямо з пропагатора без земного обертання, на відміну від експорту SP3 — на сітку часу, а OemFile::to_oem_string серіалізує заголовок CCSDS_OEM_VERS/CREATION_DATE/ ORIGINATOR та по одному сегменту META_START … META_STOP на супутник (OBJECT_NAME/OBJECT_ID/CENTER_NAME/REF_FRAME = TEME/TIME_SYSTEM = GPS/ START_TIME/STOP_TIME), після яких ідуть його рядки epoch X Y Z X_DOT Y_DOT Z_DOT (км, км/с). Значення CREATION_DATE задає викликач, ніколи не годинник реального часу, тому вихідні дані побайтово однакові між прогонами (контракт відтворюваності). Це аналог для ефемерид космічного апарата експорту GNSS SP3: орбіту Kshana тепер можна передати інструменту динаміки польоту в стандартному форматі.
• Точна ефемерида SP3 як джерело пропагації. Sp3File::interpolator будує для кожного супутника Sp3Interpolator, який заповнює положення між табульованими епохами SP3 поліномом Лагранжа 9-го порядку (стандартна практика IGS) і повертає його в спільну систему TEME, що відкривається як Propagator::Sp3Precise. Файл точних орбіт IGS/аналітичного центру тепер може керувати тим самим конвеєром геометрії/видимості/цілісності, що й бортові та аналітичні пропагатори. Перевірено циклом туди й назад: орбіта Кеплера, записана в SP3 і прочитана заново через інтерполятор, збігається з оригіналом із субметровою точністю у вузлах і < 100 м посеред інтервалу. Інтерполяція годинника — наступна.
• Бортова ефемерида ГЛОНАСС (завершує мульти-GNSS RINEX nav). Новий модуль glonass: ГЛОНАСС передає не кеплерівські елементи, а вектор стану у земній системі ПЗ-90 (положення, швидкість, місячно-сонячне прискорення). parse_glonass_nav читає записи RINEX 3 R, а положення супутника в будь-який момент отримують інтегруванням Рунге–Кутти 4-го порядку рівнянь руху з ICD ГЛОНАСС (центральна гравітація + J2 + коріолісові/відцентрові складові обертання Землі + передане прискорення). Відкрито як Propagator::Glonass, тож супутники ГЛОНАСС проходять конвеєром орбітального угруповання/видимості/цілісності нарівні з кеплерівськими системами; один блок орбітального угруповання rinex тепер може поєднувати GPS, Galileo, QZSS, BeiDou і ГЛОНАСС.
• Мульти-GNSS навігація RINEX (GPS, Galileo, QZSS, BeiDou). Аналізатор навігації RINEX 3 тепер декодує записи Galileo (E), QZSS (J) і BeiDou (C, MEO/IGSO) поряд із GPS (G): вони мають спільну кеплерівську структуру та алгоритм користувача, і кожна обчислюється зі своєю гравітаційною сталою та швидкістю обертання Землі (μ для Galileo/BeiDou, Ω̇ₑ для BeiDou). Файл зі змішаними орбітальними угрупованнями дає їх усі, і вони проходять конвеєром орбітального угруповання/видимості/цілісності як Propagator::Rinex. Геостаціонарні супутники BeiDou використовують інший поворот координат і пропускаються, доки немає еталонної фікстури для перевірки. Обхід записів використовує кількість рядків для кожної системи, що виправляє прихований дефект, коли чотирирядкові записи ГЛОНАСС/SBAS пропускалися так, ніби мали вісім рядків. ГЛОНАСС (модель вектора стану) — наступна.
• Читання та запис точних ефемерид SP3-c/d. Новий модуль sp3 розбирає файли точних орбіт SP3 від IGS/аналітичних центрів (parse_sp3) — постоброблений продукт положення/годинника в ECEF, який рушії PPP (Ginan, RTKLIB, gLAB) вважають еталонним, — у структурований Sp3File (заголовок, сітка епох, положення кожного супутника км→м, годинник мкс, а для продуктів V ще й швидкість дм/с→м/с), зберігаючи сентинели SP3 для недійсних значень. Зворотний напрямок також охоплено: Sp3File::from_propagators будує SP3 із пропагованого орбітального угруповання (TEME→ECEF на кожну епоху), а to_sp3_string його серіалізує, тож орбіти Kshana можна експортувати у форматі, який приймають зовнішні інструменти PPP: цикл читання↔запису. Інтерполяція епох і джерело пропагатора SP3 — наступні.
• Бортова ефемерида RINEX як джерело орбітального угруповання, яке можна запустити. Орбітальне угруповання тепер приймає вбудований блок rinex (навігаційний текст RINEX 3 для GPS) поряд з наявним параметром tle, тож реальний файл бортових даних керує сценарієм наскрізно з CLI, Python або браузерного майданчика: RINEX на вході, геометрія PNT на виході. Новий scenarios/orbit-rinex.toml демонструє доступність GNSS і DOP для восьми супутників GPS, побудованих безпосередньо із бортових записів. (Лише GPS LNAV; мульти-GNSS і SP3 — наступні.)
• Бортова ефемерида RINEX як джерело пропагації. Розібраний RinexEphemeris тепер перетворюється на orbit::Propagator (Propagator::Rinex): положення — це бортова орбіта за IS-GPS-200, повернута з ECEF у спільну інерційну систему TEME (sv_position_teme, з коректним щодо високосних секунд часом GPS→UT1), швидкість — центральною скінченною різницею, а також кеплерівський орбітальний період. Реальні бортові дані GPS тепер можуть керувати тим самим конвеєром геометрії, видимості та цілісності (RAIM), що й аналітичні пропагатори SGP4/Кеплера. (Ще не відкрито як вид сценарію з файлом RINEX: це та мульти-GNSS/SP3 — наступні.)

0.9.2 - 2026-06-03#

Додано#

• Архівний DOI. Випуски тепер депонуються в Zenodo, і їм присвоюється DOI для цитування.

0.9.1 - 2026-06-03#

Змінено#

• Документація. README оновлено до інституційного рівня: огляд можливостей усього стеку v0.9.0, розділ «Версії та випуски», чистий заголовок із новим знаком і стислий рядок стану. Змін у рушії немає.

0.9.0 - 2026-06-03#

Цей випуск додає три суттєві області можливостей поверх основи SGP4 0.8.0: справжню тривісну стрепдаун-INS, вільно зв'язану EKF похибок GNSS/INS із замкненим зворотним зв'язком, справжній RAIM за знімком і розділенням розв'язків (у стилі ARAIM) з HPL/VPL та сценарій integrity, який можна запустити, а також перший крок до сумісності форматів GNSS (приймання ефемерид GPS у RINEX-3).

Додано#

• Аналізатор навігаційних повідомлень GPS у RINEX 3 (src/rinex.rs). Перший крок до сумісності форматів GNSS: parse_nav читає навігаційний файл RINEX 3.x і декодує кожен запис бортової ефемериди GPS (G) — восьмирядковий блок SV/епоха + BROADCAST ORBIT — у RinexEphemeris із кеплерівських елементів і поправок годинника, з назвами полів і одиницями за IS-GPS-200. Обробляє формат чисел із плаваючою комою з експонентою D у стилі Fortran (parse_d) і розкладку з фіксованою шириною стовпців; записи для систем, відмінних від GPS, пропускаються, а не відхиляються, тож змішаний файл усе одно дає свої ефемериди GPS. Чотири тести: розбір експоненти D (включно з порожніми значеннями та помилками), повністю декодований запис за відомими значеннями полів із перевіркою правдоподібності великої півосі GPS (√A² ≈ 26 560 км), пропуск систем, відмінних від GPS, і випадок порожнього файлу.
• Бортова ефемерида GPS → положення в ECEF (src/rinex.rs). RinexEphemeris::sv_position_ecef(t_tow) обчислює земне положення супутника з розібраної ефемериди за алгоритмом користувача IS-GPS-200 §20.3.3.4.3.1: розв'язок рівняння Кеплера методом Ньютона для ексцентричної аномалії, поправки другої гармоніки до аргументу широти / радіуса / нахилу та поворот в ECEF з урахуванням обертання Землі від опорної епохи (із приписаними специфікацією μ і Ω̇ₑ для GPS та згортанням tk на перехід тижня). Три тести: геоцентричний радіус лишається в діапазоні GPS (≈ 26 560 км), земна швидкість становить ~3,9 км/с, а обчислення на повний тиждень убік відтворює те саме положення.
• Зсув годинника супутника GPS з релятивістською поправкою (src/rinex.rs). RinexEphemeris::sv_clock_bias_s(t_tow) обчислює бортовий поліном годинника af0 + af1·Δt + af2·Δt² навколо Toc плюс релятивістський ексцентриситетний доданок F·e·√A·sin Ek (IS-GPS-200 §20.3.3.3.3.1). Нова EpochUtc::gps_time_of_week перетворює календарну епоху запису на час тижня GPS через арифметику юліанських днів від епохи GPS (1980-01-06), а розв'язок Кеплера спільний із обчисленням положення. Тести: час тижня GPS для неділі/вівторка/суботи (межі тижнів) і зсув годинника, де домінує af0, з наявним обмеженим релятивістським доданком. Групову затримку L1 TGD відкрито, але навмисно не враховано. Чесний обсяг: джерело Propagator, Galileo/BeiDou/ГЛОНАСС і SP3 лишаються наступними кроками. (docs/CAPABILITY.md оновлено відповідно.)
• Вид сценарію integrity, який користувач може запустити (scenarios/integrity-raim.toml). Можливість доступності RAIM тепер досяжна з CLI/TOML, як і кожен інший пакет: kind = "integrity" розбирає IntegrityScenario (орбіта користувача, одне чи кілька орбітальних угруповань GNSS, маска висоти та конфігурація цілісності (sigma, P_fa, P_md, AL_H, AL_V)), запускає constellation_raim_availability і видає карту доступності HPL/VPL за епохами у JSON та самодостатній SVG — рівні захисту в часі на тлі порогів тривоги, зі смугою доступності зеленого/червоного кольору. kshana scenarios/integrity-raim.toml записує JSON, діаграму та звіт HTML. Вбудований сценарій (24 супутники Walker, двочастотні виміри дальності 1 м, пороги APV-I) повідомляє доступність ~95 %; він документує, що одночастотний RAIM не відповідає вертикальному порогу APV-I для одного орбітального угруповання, тому для вертикального наведення використовують SBAS/двочастотність/ARAIM. Тести охоплюють диспетчеризацію, JSON карти доступності та SVG.
• RAIM-доступність над орбітальним угрупованням, яку можна запустити (src/raim.rs). Модуль цілісності не мав викликача: constellation_raim_availability робить його справжньою наскрізною точкою входу: на кожній епосі сітки часу вона пропагує видимі супутники (тими самими пропагаторами Propagator SGP4/Кеплера, які використовує рушій), обчислює рівні захисту без несправності та оцінює доступність щодо горизонтального/вертикального порогів тривоги, повертаючи RaimAvailabilityReport, серіалізований через serde (для кожної епохи n_visible/HPL/VPL/available плюс частка доступності). RaimConfig об'єднує (sigma, P_fa, P_md, AL_H, AL_V), а raim_availability_epoch для окремої епохи відкрито для викликачів, які самі розв'язують геометрію. Три тести: епоха, оцінена як доступна за порогів APV-I на геометрії з десяти супутників, зроблена недоступною неможливо жорстким порогом, і рівні None за менш ніж п'яти супутників; а також наскрізний прогін на орбітальному угрупованні Walker із 24 супутників, що дає скінченну карту доступності й серіалізується. (Шість супутників — поріг надлишковості залишкового RAIM — чесно не відповідають APV-I навіть за дальності 1 м; доступність APV-I потребує щільнішої геометрії, яку використовує тест.)
• Накопичувач діаграми цілісності Stanford(-ESA) (src/raim.rs). Стандартний спосіб підсумувати монітор цілісності за багато епох: він наносить фактичну похибку положення (x) проти рівня захисту (y) і класифікує кожну епоху за діагоналлю y = x та порогом тривоги як Available (PL обмежує похибку, у межах AL), SystemUnavailable (PL обмежує похибку, але перевищує AL: безпечно, але непридатно), MisleadingInformation (PL < похибка ≤ AL) або HazardouslyMisleadingInformation (PL < похибка і похибка > AL: небезпечний збій). classify_stanford — чистий класифікатор; StanfordDiagram накопичує точки (error, PL) щодо фіксованого порогу тривоги, показуючи кількості за областями, доступність, підсумки подій цілісності та точки, серіалізовані через serde, для побудови графіків/експорту в JSON. Чотири тести: кожна область (включно з межею обмеженості error == PL), накопичення кількостей/доступності та цикл JSON туди й назад. Це поверхня звітування для рівнів захисту RAIM; підключення її до сценарію орбітального угруповання та перевірка за публічним набором даних лишаються пунктами дорожньої карти.
• RAIM за розділенням розв'язків (у стилі ARAIM) (src/raim.rs). Монітор цілісності з багатьма гіпотезами поряд із наявним залишково-парітетним хі-квадрат snapshot_raim. Для розв'язку за методом найменших квадратів за всіма видимими супутниками та кожного підрішення з виключенням одного супутника він формує розділення Δ_k = x_k − x₀ — гауссове з нульовим середнім без несправності та з коваріацією Cov(x_k) − Cov(x₀) (тотожність вкладених оцінювачів, чинна, бо розв'язок за всіма видимими супутниками є BLUE) — і тому він як виявляє несправність, так і ідентифікує несправний супутник (той, чиє виключення дає найбільше нормоване розділення). Горизонтальні/вертикальні рівні захисту визначаються за стандартним розподілом MHSS PL = max(K_md·σ₀, max_k[K_fa·σ_ss,k + K_md·σ_k]) з K_fa = Φ⁻¹(1−P_fa/2), K_md = Φ⁻¹(1−P_md). Нові normal_cdf/normal_quantile без залежностей, побудовані на наявній регуляризованій неповній гамма-функції модуля (erf(x) = P(½,x²)). Чотири тести з виведенням вручну: нормальна CDF / квантиль за підручниковими значеннями (Φ(1,95996)=0,975, хвіст 1e-7 = 5,1993, симетрія); геометрія без несправності, яка не дає тривоги й дає скінченні додатні HPL/VPL; зсув одного супутника в 60 σ, який виявлено і правильно ідентифіковано (excluded_sv == 2); а також поріг надлишковості для шести супутників. Закриває з боку алгоритму прогалину P0 аудиту «тавтологічна цілісність: немає справжніх RAIM/HPL/VPL»; перевірка за набором даних gLAB і накопичувач діаграми Stanford лишаються пунктами дорожньої карти.
• Інтеграція GNSS/INS із замкненим контуром (src/fusion/closed_loop.rs). ClosedLoopInsGnss поєднує ядро EKF похибок із тривісною стрепдаун-механізацією: кожен відлік IMU коригується поточними оцінками зсувів, механізується вперед, а коваріація EKF поширюється в часі з відповідним навігаційним контекстом; кожне виправлення положення/швидкості GNSS формує інновацію INS−GNSS і повертає оцінені положення, швидкість, похибку орієнтації (ψ, як обертання кватерніона) та зсуви акселерометрів/гіроскопів у рішення, скидаючи середнє похибки стану. Повернення орієнтації (а не лише зсувів) потрібне для стійкості: нахил і зсув акселерометра — зв'язана пара, тож корекція одного без другого розбігається. INS і GNSS порівнюються в локальній дотичній площині NED з використанням власних радіусів кривини механізації (нова mechanization::radii_of_curvature; NavState::omega_ie_n/omega_en_n відкрито). Це чесна заміна скидання за істинними даними гібридного пакета. Три тести: замкнений контур, що зводить уведену похибку положення 8 м / −5 м до <0,1 м; допоміжне рішення, що лишається в межах метрів (<6 м) на траєкторії руху, тоді як вільна INS розбігається понад 100 м; і віховий бенчмарк: RMS положення зливного рішення за Монте-Карло за 60 с відсутності GNSS перевершує автономний розімкнений лічильник шляху більш як у 2 раза (≈4 раза за різними зернами). Чесне обмеження, задокументоване в модулі: у вільно зв'язаному режимі зсув акселерометра та нахил розділяються лише слабко (обидва зв'язані через гравітацію), тому надається обмежений, виправлений стан і чистий вхід у відсутність сигналу, а не точне інерційне калібрування; багатша динаміка та тісно зв'язане розширення лишаються пунктами дорожньої карти.
• Ядро EKF похибок для вільно зв'язаного GNSS/INS (src/fusion/gnss_ins_ekf.rs). 15-станний розширений фільтр Калмана похибок — δx = [δp, δv, ψ, b_a, b_g] — з динамікою похибок стрепдауна за Groves 2013 §14,2 (зв'язок питомої сили/нахилу, коріоліс, проєкція зсувів із тіла в навігаційну систему, моделі зсувів Гаусса–Маркова), дискретним переходом першого порядку Φ = I + F·dt та вільно зв'язаним оновленням за вимірюванням положення+швидкості (H = [I₃ 0 0 0 0; 0 I₃ 0 0 0]) у формі Джозефа. Щільна лінійна алгебра без залежностей (обернена матриця за Гауссом–Жорданом, оновлення коваріації за Джозефом). Функція cargo tight_coupling закриває задокументоване, ще не реалізоване оновлення за псевдодальністю/Доплером. 7 тестів із виведеними вручну очікуваннями: тотожність кососиметричної матриці/векторного добутку, перевірена обернена матриця 3×3, коваріація, що лишається симетричною/додатно напіввизначеною під час передбачення (а невизначеність положення без допомоги зростає), виправлення положення, що зменшує коваріацію положення, точне відновлення відомої похибки положення за аналітичного коефіцієнта Калмана P/(P+R) і менші корекції за більшого шуму вимірювання. Це ядро, яке замінить скидання за істинними даними в розімкненому контурі гібридного пакета зворотним зв'язком у замкненому контурі (підключення пакета та перевірка за NaveGo — далі).
• Детермінована модель похибок IMU для 3-осьового стрепдаун-навігатора (src/inertial/imu_errors.rs). ImuErrorModel спотворює істинну пару (ω, f) у системі координат тіла на виміряну через п'ять систематичних категорій (IEEE Std 952-1997 §A.2; Groves 2013 §4,3, таблиця 4,1): масштабний коефіцієнт (похибка підсилення за віссю в ppm), неспіввісність / перехресний зв'язок (позадіагональна неортогональність тріади), g-чутливість (зсув швидкості гіроскопа, пропорційний питомій силі), квантування (округлення до молодшого розряду виходу) та лінійне наростання швидкості (лінійний у часі дрейф — третя область Аллана), а також постійний зсув увімкнення. Кожен доданок за замовчуванням нульовий, тож ImuErrorModel::ideal() — прозорий наскрізний прохід, і наявні сценарії не зачіпаються. Для кожного джерела похибки є тест ізоляції (масштаб лінійний до <0,01%, перехресна неспіввісність над рівнем VRW, g-чутливий зсув, сітка молодшого розряду, лінійне наростання), а наскрізний тест проводить навігаційну похибку через механізацію зі спотвореного IMU. Не змодельовано: похибка випрямлення вібрації, дрейф за градієнтом температури. (Поставлений пакет сценаріїв inertial досі працює зі старим скалярним бюджетом з 1 ступенем свободи; ця модель живить 3-осьову бібліотеку.)
• Компенсація coning і sculling для стрепдаун-інтегратора. Шлях орієнтації додає двовідліковий coning_increment (½ Δθ_prev × Δθ_cur); перевірено, що грубе за частотою (30 Гц, 5 відліків на цикл) інтегрування середовища coning на 5 Гц відстежує істину з високою частотою в ≥ 3 раза краще з поправкою, ніж за наївного підсумовування приростів. Шлях швидкості додає sculling_increment (½ Δθ × Δv, Groves, рів. 5,82) і розв'язує приріст швидкості тіла через нове оновлення на основі приростів NavState::step_increments з використанням відносного до тіла обертання Δθ_rel = Δθ_b − C_n^b ζ, тож платформа, закріплена на Землі, не отримує хибного sculling, а справжня вібрація запускає повний доданок.
• Повна тривісна стрепдаун-механізація в системі NED (src/inertial/mechanization.rs). NavState { q, v_ned, p_llh } просувається через step(gyro_b, accel_f_b, dt) за стандартними рівняннями NED у земній системі (Groves §5,4): орієнтація тіло→NED із поправкою на швидкість переходу від інерційної до навігаційної системи ω_in = ω_ie + ω_en (обертання Землі + швидкість перенесення); питома сила розв'язується з тіла в NED через DCM; швидкість інтегрує v̇ = f_n − (2 ω_ie + ω_en) × v + g_n (коріоліс/перенесення + гравітація); геодезичне положення — через меридіанний і поперечний радіуси кривини. Гравітація — це замкнена формула Соміліани за WGS-84, нормальна (виска) гравітація, з поправкою NIMA на висоту у вільному повітрі, ніколи не жорстко задана стала. Це справжній тривісний навігатор, що замінює шлях скалярного бюджету похибок з 1 ступенем свободи. Перевірено фізичними інваріантами: платформа, жорстко закріплена на Землі, що обертається, на 45° пн. ш. (відчуває швидкість обертання Землі + 1 g) лишається в межах 1 мм протягом 60 с; горизонтальна питома сила на північ дає v_N ≈ a·t і зміщення ½ a t²; нормальна гравітація збігається з відомими значеннями на поверхні екватора/полюса/45° та градієнтом у вільному повітрі.
• Тривісне подання орієнтації для стрепдаун-INS (src/inertial/attitude.rs). Тип одиничного кватерніона Quaternion (скаляр першим, конвенція Гамільтона), що несе обертання тіло→навігаційна система, з поданням DCM (to_dcm/from_dcm за методом Шеппарда), добутком Гамільтона, конструкторами з вісі-кута та вектора обертання (точна експоненційна відповідність) і кінематикою кватерніона: як оновлення швидкості RK першого порядку (q̇ = ½ q ⊗ ω), так і оновлення вектора обертання з поправкою на coning. Двовідліковий coning_increment (Savage / Bryan–Lewantowski, ½ Δθ_prev × Δθ_cur) дає доданок перехресного зв'язку швидкості обертання, який скалярне числення шляху опускає. Це основа орієнтації для повної 3-осьової механізації, що замінює старий шлях бюджету похибок з 1 ступенем свободи. Перевірено за замкненими обертаннями: поширення за сталої швидкості збігається з кватерніоном вісь-кут до 1e-6, DCM ортонормовані з одиничним визначником, а coning зникає для руху вздовж однієї осі. (src/inertial.rs тепер є каталогом модуля src/inertial/; публічний шлях crate::inertial не змінився.)
• Геодезично коректна видимість наземної станції (src/frames.rs). elevation, is_visible і visible_count обчислюють висоту супутника над горизонтом наземної станції відносно нормалі до еліпсоїда WGS-84 (справжньої місцевої вертикалі), а не геоцентричного радіуса: вони відрізняються до ~0,19° геодезичного відхилення, чого досить, щоб супутники поблизу горизонту потрапляли в маску висоти або випадали з неї. Перевірено наскрізно (орбітальне угруповання Walker пропаговано, повернуто TEME→ECEF і пораховано з геодезичного пункту) і порівняно з геоцентричним наближенням.

Змінено#

• Надійність CI. Завдання test-python-bindings тепер збирає wheel за допомогою PyO3/maturin-action (контейнер manylinux) замість безпосереднього maturin build на хості, що усуває періодичний конфлікт rustup rustfmt-preview/cargo-fmt на образі виконавця. Завдання deny встановлює cargo-deny як попередньо зібраний двійковий файл через taiki-e/install-action замість cargo-deny-action на основі Docker, що усуває тайм-аут завантаження з реєстру Docker Hub. Жодна зміна не впливає на виконувані перевірки.

0.8.0 - 2026-06-02#

Додано#

• Інерційну швидкість відкрито для подальшого використання. Propagator::velocity_eci і Propagator::state_eci (що повертає StateEci { r_m, v_m_s }) передають аналітичну швидкість TEME, яку SGP4 уже обчислює (раніше її відкидали), викликачам у м/с; Orbit::velocity_eci дає кеплерівському шляху узгоджену швидкість. Перевірочний тест AIAA 2006-6753 тепер також перевіряє швидкість для кожного еталонного рядка (найгірша похибка швидкості 1.85e-9 км/с за всіма 666 станами) і фіксує кількість порівнюваних рядків рівно на 666.

• Суворіший розбір TLE без панік. Рядки мусять бути ASCII і нарізаються безпечно (більше немає паніки з байтовим індексом на багатобайтовому вводі); елементи перевіряються на діапазон (нахил, ексцентриситет, середній рух); контрольну суму у стовпці 69 можна примусово перевіряти через ParseOpts { strict_checksum } / parse_propagators_opts і новий прапорець strict_checksum у ConstellationCfg (за замовчуванням поблажливо).

• Крива девіації Аллана у виводі. Кожен прогін годинника тепер повідомляє adev_curve ([{tau_s, adev, n_samples}]), а браузерний майданчик показує діаграму «Стабільність годинника (ADEV)» у подвійному логарифмічному масштабі.

• Перевірка вхідної сітки часу. TimeCfg::validate відхиляє нескінченну чи нечислову, нульову, від'ємну або завелику сітку часу (крок більший за тривалість або понад MAX_TIME_STEPS відліків) до будь-якого виділення пам'яті, тож некоректний сценарій повертає помилку, а не панікує чи вичерпує пам'ять.

• Ансамблі Монте-Карло для інерційного пакета. runs = N для інерційного сценарію запускає N зерен і повідомляє для кожної метрики середнє, стандартне відхилення, перцентилі та перцентильно-бутстрепний 95% довірчий інтервал (ensemble). Кожен інерційний прогін тепер несе прапорець monte_carlo, тож показник якості однієї реалізації більше не плутають із розподілом. (CEP/2DRMS навмисно не повідомляються: вони потребують 3-осьової моделі з дорожньої карти.)

• Режим майданчика з підказками. Браузерний майданчик більше не кидає вас на суцільну стіну TOML: смуга «Почніть тут» з картками сценаріїв в один клік завантажує й запускає опрацьований приклад, повзунки відкривають універсальні параметри (зерно, поріг часу) без редагування TOML, примітка «Як це читати» пояснює результат, а повний TOML — одним згортанням далі. Кожен прогін можна поділитися: Скопіювати посилання для поширення кодує весь сценарій у фрагмент URL (нічого не вивантажується), тож посилання відтворює той самий прогін під час завантаження. Кодек має модульні тести (web/share.test.mjs, виконуються в CI).

• N-вимірні перебори параметрів (src/sweep.rs). nd_sweep оцінює метрику на повному декартовому добутку кількох діапазонів SweepAxis (дослідження компромісів за кількома параметрами) у рядковому порядку, детерміновано. Адитивно: наявний API 1-D перебору не змінився. Довірчі інтервали бутстрепа для вузлів і узагальнення за межі пакета годинника лишаються в дорожній карті.

• Справжній RAIM за знімком (src/raim.rs). Справжній автономний контроль цілісності приймача в області положення: він будує геометрію ліній візування до видимих супутників, формує розв'язок за методом найменших квадратів і залишки, виконує χ²-тест виявлення несправності за залишками (точний поріг із χ²/нецентрального χ² на неповній гамма-функції без залежностей) та обчислює горизонтальний і вертикальний рівні захисту (HPL/VPL) на основі нахилу із зсувом пропущеного виявлення, виведеним для налаштованих P_fa/P_md. Це відмінне від показника цілісності конвеєра сценаріїв (самоузгодженості фільтра), і воно ще не підключене до нього; виключення несправностей, бюджетування порога тривоги/P_HMI та ARAIM лишаються в дорожній карті.

• Набір стабільності частоти: MDEV, TDEV, HDEV + довірчі інтервали (src/allan.rs). Поряд з перекривною ADEV: модифікована девіація Аллана (відрізняє білий від фліккерного фазового шуму), девіація часу (TDEV = tau/sqrt(3) * MDEV) та девіація Адамара (точно відкидає лінійний дрейф частоти і збігається для розбіжних типів червоного шуму). Довірчі інтервали на основі χ² (deviation_ci) використовують пару нормальних/χ² квантилів без залежностей (Acklam + Wilson-Hilferty) із консервативним edf без перекриття; edf, специфічний для типу шуму, та числова відповідність Stable32 лишаються в дорожній карті.

• Редукція систем відліку (src/frames.rs). Обертання TEME↔ECEF на основі GMST (за тим самим зоряним часом IAU-1982, що й пропагатор), точне WGS-84 геодезичні↔ECEF з ітераційним оберненим перетворенням із початком за Боврінгом (машинна точність на всіх висотах, включно з MEO/GEO) і геодезичний спостерігач наземної станції, що повертає азимут / висоту / дальність у місцевій системі «схід–північ–вгору». Рух полюса та субвідсекундна нутація не застосовуються (лише GMST, субкілометрова похибка на трасі на поверхні); точний ланцюг CIO за ITRF — у дорожній карті.

• Основа шкал часу (src/timescales.rs). API юліанських дат без залежностей (григоріанська цивільна дата ↔ JD, MJD), повна цілочисельна історія високосних секунд IERS (UTC↔TAI, 10 с у 1972 році до 37 с з 2017 року), визначений зсув TAI→TT, поправка UT1 через заданий DUT1 та кут обертання Землі IAU-2000. Це часова основа, на якій спирається (запланована) редукція земних систем відліку. Моменти — це юліанські дати з одним f64 (роздільність ~50 мкс поблизу поточної епохи; двоскладова JD — у дорожній карті), а епоха «гумової секунди» до 1972 року не змодельована: обидва обмеження задокументовано в модулі.

• Відтворюваність і походження. Детермінований генератор SBOM CycloneDX (scripts/gen-sbom.sh) та атестація походження збірки SLSA для випускного двійкового файлу та SBOM; інструментарій випуску зафіксовано, щоб відповідати CI. Гарантії детермінованості, міжплатформенне застереження щодо libm та підхід фіксації еталонів задокументовано в docs/REPRODUCIBILITY.md.

• Тести на властивості та фазінг (tests/property.rs). Детерміновані рандомізовані тести (без нових залежностей) перевіряють інваріанти на тисячах вхідних даних: аналізатори TLE і сценаріїв ніколи не панікують на сміттєвих, не-ASCII, змінених або обрізаних вхідних даних; TimeCfg::validate ніколи не панікує на сітках NaN/inf/від'ємних; контрольна сума TLE узгоджена і стосується лише стовпця 69; цикл геодезичні↔ECEF туди й назад і обертання TEME→ECEF зберігають норму по всій земній кулі та в широкому діапазоні висот.

Змінено#

• Еталонні тести тепер фіксують показники якості поле за полем для чотирьох еталонних сценаріїв (з допуском, який поглинає міжплатформенний джитер libm), замінюючи попередні перевірки лише нерівностей, тож мовчазну числову регресію виявляють негайно.
• schema_version в артефактах результатів підвищено з 0.1 до 0.7 (його було заморожено, поки рушій розвивався).
• cargo-deny тепер забороняє (а не лише попереджає про) відкликані залежності.
• Нова документація: CAPABILITY.md (чесна карта обсягу), SCHEMA.md (довідник полів результату), INTEGRITY.md, QUANTUM-MODELS.md, REAL_TLE_GUIDE.md. Захист CI завершується помилкою, якщо значок версії в README розходиться з Cargo.toml.

0.7.0 - 2026-06-02#

Додано#

• Пропагація орбіт SGP4/SDP4. Повна реалізація стандартного пропагатора спрощених збурень без залежностей: SGP4 для навколоземних орбіт разом із розширенням SDP4 для глибокого космосу (місячно-сонячні секулярні та періодичні збурення й резонанс геопотенціалу 12 год / 24 год). Її перевірено за офіційними векторами перевірки AIAA 2006-6753 («Revisiting Spacetrack Report #3»): усі 666 еталонних станів для навколоземних, глибококосмічних, резонансних випадків і випадків кодів помилок збігаються з найгіршою похибкою положення близько 4 мм. Це модель, відносно якої визначають двострокові набори елементів, тож вона відтворює реальні орбітальні угруповання, зокрема орбіти GNSS ~12 год, які є глибококосмічними й резонансними і яких не може охопити попередня двотільна модель із секулярним J2.
• Орбітальне угруповання, задане як повні двострокові набори елементів (рядок 1 + рядок 2), тепер пропагується за SGP4/SDP4; орбітальне угруповання, задане елементами лише рядка 2, зберігає аналітичну кеплерівську двотільну пропагацію без змін. Обидві форми можна змішувати в одному блоці. Новий еталонний сценарій orbit-sgp4-gps.toml (орбітальне угруповання MEO, подібне до GPS, у реальному двострочному форматі, пропаговане за SGP4): підставте поточний набір Celestrak «gps-ops», щоб вивчати чинне орбітальне угруповання.

0.6.0 - 2026-06-02#

Додано#

• Демонстратор активної атаки спуфінгу. Новий вид сценарію spoof вводить зростаючий хибний спуфінг часу та запускає для кожного годинника монітор цілісності за допомогою годинника, повідомляючи, чи виявлено спуфінг і коли, а також чи досягає він експлуатаційної специфікації невиявленим, перетворюючи показник якості безпеки на конкретну демонстрацію атаки/захисту. Новий еталонний сценарій spoof-attack.toml.
• Доступність для кількох орбітальних угруповань. Орбітальний сценарій може поєднувати кілька орбітальних угруповань (список [[constellations]] поряд з основним [constellation]) для мульти-GNSS доступності та геометричного чинника DOP, наприклад GPS плюс Galileo. Новий еталонний сценарій orbit-multignss.toml.

0.5.0 - 2026-06-02#

Додано#

• Звіт-картка HTML. Кожен прогін тепер також створює самодостатню HTML-картку з фірмовим оформленням: однорядковий підсумок, діаграму (вбудовану як інертне зображення data-URI) та повний JSON, які CLI записує поряд із JSON і SVG. Одиничний файл-артефакт, яким можна поділитися, для результату дослідження чи додатка.
• Спільний оцінювач злиття датчиків. Новий вид сценарію fusion запускає єдиний рекурсивний фільтр Калмана як навігаційне рішення: він зливає стан годинника [phase, frequency] і стан положення [position, velocity], підлаштовується під GNSS (вивчаючи зсув частоти та швидкість) і доповнюється оптичним передаванням часу під час відсутності сигналу, замість складання незалежних предикторів. Він повідомляє злитий holdover часу/положення та цілісність за спільною коваріацією. Новий еталонний сценарій fusion-pnt.toml.
• Повніша модель шуму IMU. Акселерометр тепер моделює решту членів варіації Аллана, окрім сталого зсуву та випадкового блукання швидкості: нестабільність зсуву (фліккерна підлога 1/f на стандартному коефіцієнті нестабільності зсуву за Алланом із повторним використанням фліккерного синтезу годинника) та випадкове блукання прискорення. Нові необов'язкові поля інерційного сценарію bias_instability і q_aa; повторне виправлення GNSS перекалібровує залишковий дрейф зсуву.
• Реальна геометрія орбітального угруповання з TLE. Орбітальне угруповання можна задати блоком двострокових наборів елементів (стандартний формат NORAD/Celestrak) через поле tle, тож доступність і геометричний чинник DOP використовують опубліковану геометрію реального орбітального угруповання замість синтетичного візерунка Walker. Рушій читає середні кеплерівські елементи кожного TLE і пропагує їх двотільно, а не за SGP4, що обґрунтовано для дослідження знімка від спільної епохи. Новий еталонний сценарій orbit-real-tle.toml.

0.4.0 - 2026-06-02#

Додано#

• Перебори параметрів у дослідженні компромісів. Новий вид сценарію sweep змінює один параметр (threshold_ns, duration_s, quantum_q_wf або classical_q_wf) у лінійному чи логарифмічному діапазоні й записує обраний показник якості в кожній точці для обох годинників, створюючи порівняльну діаграму «як holdover масштабується зі стабільністю годинника?», потрібну для вибору проєктного компромісу. Новий еталонний сценарій sweep-clock-stability.toml.
• Довірчі смуги Монте-Карло. Сценарій holdover годинника може запускати багато реалізацій (нове необов'язкове поле runs): кожен показник якості тоді повідомляється як середнє з розкидом між 5-м і 95-м перцентилями, а діаграма затінює 5–95% обвідну похибки навколо медіани для кожного годинника. За замовчуванням лишається одиничний прогін. Новий еталонний сценарій clock-ensemble.toml.
• Ексцентричні орбіти та дрейф J2. Тип орбіти тепер — повна кеплерівська орбіта (велика піввісь, ексцентриситет, нахил, RAAN, аргумент перигею, середня аномалія), що пропагується розв'язком рівняння Кеплера, з необов'язковими секулярною нодальною регресією J2 та апсидальною прецесією. Нові необов'язкові поля сценарію eccentricity, argp_deg і j2 та еталонний сценарій orbit-molniya.toml (користувач на сильно ексцентричній орбіті з критичним нахилом і періодом 12 год). Кругові орбіти зберігають початковий замкнений шлях біт у біт.
• Гібридний пакет (комбінований PNT) тепер повідомляє цілісність і безпеку, тож усі чотири пакети охоплюють повний набір експлуатаційних показників якості. Цілісність — це охоплення межею захисту в каналі часу від оцінювача Калмана, підлаштованого під істинні дані, поки GNSS номінальний, і заново прив'язаного (вільніше) на кожній оптичній ресинхронізації; її межа включає підлогу шуму вимірювання лінії, тож годинник, значно кращий за лінію, оцінюється за фактичним шумом наданого рішення. Безпека — це оцінка виявлення спуфінгу за допомогою годинника щодо специфікації часу.

Змінено#

• Примітки до випуску тепер формуються з добірного розділу CHANGELOG для тега (scripts/changelog-extract.sh), тож кожен випуск на GitHub підкреслює, що змінилося, замість переліку сирих комітів.

0.3.0 - 2026-06-02#

Додано#

• Показник якості безпеки (раніше незаповнений): оцінка виявлення спуфінгу за допомогою годинника для пакетів holdover годинника та орбіти. Вона моделює монітор цілісності, який перехресно звіряє час, виведений із GNSS, із власним екстрапольованим прогнозом годинника на когерентному вікні; поріг виявлення поєднує усереднений шум вимірювання з невизначеністю екстраполяції годинника, тож тихіший годинник виявляє менші, повільніші спуфінги часу. Оцінка повідомляється в [0, 1] відносно специфікації часу, завершуючи шість експлуатаційних показників якості.
• Точність положення, виведена з геометрії, для орбітального пакета: за геометрією ліній візування до видимих супутників він формує матрицю плану та її коваріаційний чинник Q = (HᵀH)⁻¹, що дає чинники погіршення точності (GDOP/PDOP/HDOP/VDOP/TDOP). Точність положення — це DOP положення, помножений на настроювану еквівалентну для користувача похибку дальності (нове необов'язкове поле сценарію sigma_uere_m). Результат орбіти тепер несе підсумок геометрії (частка відліків з виправленням, найкращі та медіанні PDOP і сигма положення).
• Майданчик у браузері (web/), який виконує рушій на стороні клієнта як WebAssembly: оберіть еталонний сценарій або відредагуйте TOML, запустіть його й побачте підсумок, діаграму та повний JSON, нічого не вивантажуючи. Робочий процес pages збирає й публікує його на GitHub Pages, а новий експорт WebAssembly summary підтримує відображення.
• Підписані вісі y на діаграмах SVG: лінії сітки, числові підписи поділок і заголовок осі з одиницями (через спільну допоміжну функцію chart), щоб величини можна було прочитати.
• Робочий процес публікації пакетів (publish) для crates.io, PyPI та npm, кожен залежить від токена свого реєстру й запускається опублікованим випуском.

0.2.0 - 2026-06-02#

Додано#

• Фліккерна (1/f) підлога FM для моделі похибок годинника, синтезована як сума процесів Орнштейна–Уленбека з логарифмічним розташуванням і відкалібрована так, щоб плоска підлога девіації Аллана була на настроюваному рівні. За замовчуванням вимкнена; вмикається для кожного годинника через необов'язкове поле сценарію flicker_floor.
• Канал гіроскопа для інерційної моделі: залишковий зсув гіроскопа та випадкове блукання кута керують похибкою орієнтації (нахилу), яка зв'язує гравітацію з горизонтальною похибкою питомої сили, домінантним механізмом зростання похибки стрепдауна. За замовчуванням вимкнено; вмикається для кожного датчика через необов'язкові поля gyro_bias і q_arw.
• Двостановий (фаза, частота) оцінювач годинника Калмана з точною дискретизацією шуму процесу за van Loan. Екстраполяція від відомого стану точно відтворює аналітичне зростання похибки holdover (q_wf*T + q_rw*T^3/3), а фільтр додатково дає онлайнову межу невизначеності в 1 сигму.
• Прогін годинника тепер повідомляє показник якості цілісності (раніше незаповнений): частку відліків відсутності сигналу, де похибка лишається в межі захисту фільтра 3 сигма, відображену в JSON-результаті та підсумку CLI.
• Доступність GNSS, виведена з геометрії: пропагація кругових орбіт, генератор орбітального угруповання Walker-delta та видимість за лінією візування (затінення Землею плюс маска висоти) дають часову шкалу доступності з реальної орбітальної геометрії. Новий вид сценарію orbit та еталонний сценарій orbit-gnss-challenged.toml (космічний апарат усередині оболонки GNSS з перервним покриттям).
• Необов'язкове розширення Python (PyO3, abi3), що відкриває run, run_full та version, упаковане за допомогою maturin (pyproject.toml) і зібране для Linux, macOS та Windows робочим процесом wheels за тегом випуску. Прив'язка — необов'язкова залежність, ввімкнена функцією: типова збірка, тести та перевірка залежностей не зачіпаються.
• Необов'язковий модуль WebAssembly (wasm-bindgen), що відкриває run, chart_svg та version, зібраний за допомогою wasm-pack під функцією wasm; getrandom обмежено цільовою платформою, щоб використовувати джерело ентропії браузера на wasm32.
• Спільна диспетчеризація api::run_toml, яку використовують CLI та обидві прив'язки, тож командний рядок і прив'язки не можуть розійтися.

Змінено#

• Оцінювання holdover тепер враховує сегменти: часові шкали відсутності сигналу розбиваються на суцільні сегменти під час повторного захоплення GNSS, а повідомлений holdover — це найгірше (найкоротше) екстраполювання серед них. Сценарії з однією відсутністю сигналу не змінюються. Стосується оцінювачів годинника, інерційного та гібридного.
• Повідомлений kind інерційної моделі тепер — inertial (було accelerometer), що відображає об'єднані канали акселерометра та гіроскопа.

0.1.0 - 2026-06-01#

Початковий випуск.

Додано#

• Детермінований рушій симуляції для гібридного квантово-класичного PNT: спільний інтерфейс моделі похибок, декларативні сценарії доступності GNSS, оцінювачі holdover / числення шляху та оцінювання показників якості за стандартними експлуатаційними критеріями PNT. Результати відтворювані з scenario + seed + engine version (версійований, самоописовий JSON із хешем сценарію) і відтворюються як діаграми SVG. CLI диспетчеризує сценарії за kind.
• Чотири пакети датчиків, кожен відкалібрований за опублікованими даними та перевірений за стандартним співвідношенням:
  • Holdover годинника: білий FM, випадкове блукання FM і лінійне старіння; перевірено за перекривною девіацією Аллана (Riley, NIST SP 1065). Чипний атомний годинник проти стронцієвого оптичного решітчастого годинника.
  • Інерційне числення шляху: залишковий зсув + випадкове блукання швидкості, двічі проінтегровані до похибки положення; перевірено за співвідношеннями зростання похибки Грувза. Холодноатомний проти навігаційного акселерометра.
  • Передавання часу: тремтіння часу оптичної проти радіочастотної лінії → точність синхронізації → односторонні вимірювання дальності.
  • Гібридне злиття (завершальний пакет): комбінований набір PNT, який має утримувати і час, і положення, з необов'язковою підтримкою годинника оптичним міжсупутниковим передаванням часу.
• Один цитований еталонний сценарій на пакет у scenarios/, де кожен числовий параметр має рецензоване джерело provenance.
• Захист відтворюваності та чистоти репозиторію; CI (формат, clippy, тести, захисти, MSRV) і конвеєр випуску за тегом, який повторно виконує всі перевірки.
• Документація: README зі схемами архітектури, звіт про стан перевірки, посібник для учасників, політика безпеки та кодекс поведінки; ліцензія Apache-2.0; шаблони issue/PR і конфігурація Dependabot.
• Нейтрально щодо постачальників у всьому тексті; рецензовані наукові та метрологічні цитування збережено.
• Чистота ліцензії Apache-2.0: заголовки SPDX у всіх вихідних файлах, NOTICE з повідомленням про торговельну марку, підтвердження Developer Certificate of Origin (DCO) для внесків і застосування cargo-deny до ліцензій/бюлетенів залежностей у CI.
• Позиціювання open-core (README): безкоштовний рушій Apache-2.0 плюс доступні комерційна підтримка, інтеграція та пропрієтарні розширення від Ashforde OÜ — утримувані послугами, а не ліцензійними платежами.
• CITATION.cff, щоб програмне забезпечення можна було цитувати.