День 3: Послідовність обробки даних вимірювань

Лектор: Андрій Ніколаєв, кандидат технічних наук, старший науковий співробітник, лабораторія навігаційних систем

Дата: березень 2003 року

Вступ до подорожі

Вітаємо на третьому дні нашої пригоди! Сьогодні студенти прийшли вчасно, і Андрій розпочав коротку лекцію, щоб занурити нас у суть координатно-часової навігаційної системи забезпечення (СКНОУ). Ми розглянемо послідовність обробки даних вимірювань, яка відображає етапи, описані в попередній обробці даних. Тут сирі сигнали перетворюються на цінні навігаційні дані. Розберемо цей процес крок за кроком, уважно зосереджуючись на формулах, що становлять основу цих перетворень.

Подорож даних: розширена версія з формулами

DATA-PIZZA 2.0

Нескінченний цикл кухні — алгоритмічне мистецтво

🏠 0. ІНІЦІАЛІЗАЦІЯ РЕЦЕПТУ

                            recipe_params ← LOAD_DEFAULT_RECIPE()
                        

Технічне відображення:

INIT_DEFAULT_FILTER_PARAMS

WHILE oven_is_hot (system_is_running)

∞

🥘 ОТРИМАННЯ ІНГРЕДІЄНТІВ

                                ingredients ← GATHER FROM Pantry()
                            

Raw Data → GNSS Frames → NRS Buffer

Технічне відображення:

ACQUIRE raw GNSS frames FROM each NRS

🧽 ПІДГОТОВКА ТА ОЧИЩЕННЯ

PREP ingredients

SCALE ingredients

DISCARD spoiled_items

Технічне відображення:

UNPACK frames

DECODE DI → integers, CONVERT to SI units

DETECT & REMOVE outliers

🍞 ЗАМІШУВАННЯ ТІСТА

                                dough ← MIX ingredients USING recipe_params
                            

ANALYZE dough_texture()

REST dough UNTIL synced_clock()

STORE dough IN WalkInFridge

Технічне відображення:

FILTER data USING current params

RUN statistical_analysis

TIME_ALIGN DI

PUSH filtered_data TO RPKNP_DB

🧂 КОРЕКЦІЇ СМАКУ

                                kitchen_context ← FETCH FROM WalkInFridge
                            

SEASON sauce USING kitchen_context

Технічне відображення:

PULL geo_context / models FROM RPKNP_DB

APPLY measurement_corrections

🔍 ПЕРЕВІРКА ЦІЛІСНОСТІ

                                integrity_flag ← VERIFY oven_temp_and_hygiene()
                            

Технічне відображення:

MONITOR navigation-field integrity

🍕 ВИПІКАННЯ ТА ФОРМУВАННЯ DCI

                                pizza ← BAKE dough WITH integrity_flag
                            

Технічне відображення:

BUILD optimal_DCI WITH integrity_flag

✅ КОНТРОЛЬ ЯКОСТІ ТА ДОСТАВКА

                                IF INSPECT pizza == PASS
                            

                                  SLICE_AND_BOX pizza FOR Delivery
                            

                                  recipe_params ← SEND_SLICE_TO_CCS_GET_TUNING()
                            

                                  ARCHIVE {dough, pizza, logs} IN WalkInFridge
                            

                                ELSE
                            

                                  LOG "🍕 Burnt pie – discarded"
                            

Технічне відображення:

VALIDATE dci_packet

ENCODE DCI FOR end-user distribution

FORWARD MI/DI TO CCS & GET new filter params

STORE {filtered_data, dci_packet, logs} IN RPKNP_DB

Дія «піци»	Інженерний крок	Призначення
GATHER FROM Pantry	Отримання сирих кадрів GNSS від кожної НПС	Отримання сирих даних вимірювань
PREP / SCALE	Розпакування кадрів, декодування DI, перетворення в СІ	Перетворення даних у фізичні одиниці
DISCARD spoiled items	Виявлення та видалення викидів	Видалення аномальних вимірювань
MIX / REST	Фільтрація, статистика, вирівнювання за часом	Очищення та синхронізація потоку даних
SEASON sauce	Застосування корекцій вимірювань	Компенсація іоносфери, тропосфери тощо
VERIFY oven…	Моніторинг цілісності навігаційного поля	Забезпечення цілісності навігаційного поля
BAKE	Формування оптимального DCI	Формування пакета диференціальної корекції
SLICE_AND_BOX	Кодування DCI для кінцевих користувачів	Підготовка повідомлень RTCM
SEND_SLICE_TO_CCS	Передача MI/DI до СКК та отримання нових параметрів	Замикання петлі зворотного зв’язку
ARCHIVE … IN WalkInFridge	Зберігання даних і журналів у РПКНП_БД	Історична база даних для аудиту та аналізу

Сцена 1 — Збір із комори

Шеф-кухар збирає сирі дані GNSS, представлені у вигляді сяючих кубів, що падають із супутників.

1. Отримання сирих даних: перші кроки героїв

Подорож починається з прийому сирих даних від супутникових сигналів. Ці сигнали, закодовані навігаційними повідомленнями, надходять у вигляді бінарних потоків. Перше завдання — перевірити їхню цілісність за допомогою контрольних сум, таких як CRC (циклічний контроль надмірності) або перевірки на основі XOR, як описано на етапі попередньої обробки. Це гарантує, що під час передачі не сталося пошкодження.

Псевдодальність, ключова метрика, вводиться тут за формулою:

\[ \rho = c \cdot (t_{\text{recv}} - t_{\text{send}}) \]

де:

\(c\) — швидкість світла (299 792 458 м/с)
\(t_{\text{recv}}\) — час прийому
\(t_{\text{send}}\) — час передачі

Ця формула задає основу для подальших обчислень, хоча її повне застосування з’явиться в наступних кроках.

2. Попередня обробка даних: перетворення у фізичні одиниці

Далі перевірені сирі дані перетворюються у фізичні одиниці. Це передбачає застосування масштабних коефіцієнтів для перетворення цифрових відліків у значущі вимірювання, такі як відстані чи швидкості.

Наприклад, масштабний коефіцієнт \(k\) множить сирі дані \(D_{\text{raw}}\), щоб отримати фізичне значення \(D_{\text{phys}}\):

\[ D_{\text{phys}} = k \cdot D_{\text{raw}} \]

Таблиця 5.1 з попередньої обробки детально описує ці коефіцієнти для параметрів, таких як азимут, доплерівський зсув і час. Цей крок забезпечує сумісність з навігаційними алгоритмами, хоча синхронізація часових шкал (наприклад, GPS і GLONASS) тут лише позначена як питання на майбутнє.

3. Алгоритм Кеплера та координати супутників: ефемериди

Маючи фізичні одиниці, ми обчислюємо координати супутників за допомогою даних ефемерид.

Обчислення позиції супутника GPS

Для GPS застосовується кеплерова орбітальна модель. Процес починається з середньої аномалії \(M\), яка переходить в ексцентричну аномалію \(E\) через рівняння Кеплера:

\[ M = E - e \sin(E) \]

де \(e\) — ексцентриситет. Це розв’язується ітеративно, що приводить до істинної аномалії й, нарешті, до позиції \((X, Y, Z)\) у геоцентричній земно-фіксованій системі координат (ECEF).

Обчислення позиції супутника GLONASS

Для GLONASS чисельне інтегрування (наприклад, метод Рунге-Кутти) враховує його некеплерову орбіту, як детально описано в попередній обробці. Ці обчислення критично важливі для позиціонування.

4. Корекції: обертання Землі (ефект Саньяка)

Корекції уточнюють наші дані. Ефект Саньяка, спричинений обертанням Землі, коригує псевдодальність. Корекція \(\Delta_{\omega}\) обчислюється як:

\[ \Delta_{\omega} = \frac{2 \omega_E R_E^2}{c} \cdot \sin(\phi) \]

де:

\(\omega_E\) — кутова швидкість Землі (7,2921151467 × 10⁻⁵ рад/с)
\(R_E\) — радіус Землі (6 371 000 м)
\(c\) — швидкість світла
\(\phi\) — широта

Це узгоджується з фокусом попередньої обробки на корекціях обертання, хоча іоносферні й тропосферні ефекти позначені як специфічні для UNIX удосконалення для майбутньої реалізації.

5. Аналіз якості та перевірки цілісності

Перевірки якості забезпечують надійність даних. У той час як попередня обробка зосереджується на контрольних сумах (розділ 5.1), додаткові метрики, такі як PDOP (Position Dilution of Precision — фактор погіршення точності позиціонування), можуть підвищити цілісність. Однак вони ще не деталізовані й слугують лише концептуальною заувагою, пов’язаною з формулою псевдодальності \(\rho\). Необхідний подальший розвиток поза межами поточного обсягу.

6. Формування диференціальних корекцій (DC) та вихідних даних

Нарешті, диференціальні корекції формуються за допомогою псевдодальностей. Кодова псевдодальність \(S_{C/A}\) обчислюється як:

\[ S_{C/A} = \rho + c \cdot (dt_{\text{recv}} - dt_{\text{send}}) \]

де \(dt_{\text{recv}}\) та \(dt_{\text{send}}\) — зсуви годинників приймача та супутника. Ці значення, отримані в попередній обробці, дають змогу сформувати вихідні дані, зокрема архіви сирих даних, готові до використання в навігації.

7. Гумористичний епілог: Data-Pizza 2.0

Уявіть наші дані як піцу! Кірка — це сирі дані, з соусом (фізичні одиниці), сиром (координати супутників) і додатковою начинкою (корекції). Подана гарячою, вона готова до навігації — звісно, у стилі UNIX!

Гумористична інфографіка «DATA-PIZZA», що ілюструє покроковий процес обробки даних GNSS від сирих сигналів до остаточного навігаційного рішення — Data-Pizza: від сирих інгредієнтів до навігаційного бенкету!

8. Підсумок

Ключові кроки в обробці даних вимірювань:

Прийняти та перевірити сирі дані за допомогою контрольних сум
Перетворити у фізичні одиниці за допомогою масштабних коефіцієнтів
Обчислити позиції супутників за допомогою методу Кеплера або чисельних методів
Застосувати корекції Саньяка для уточнення псевдодальностей
Сформувати диференціальні корекції для виводу

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

^До початку