Цифровой двойник лунной заправочной станции в дипломе: от телеметрии к экономике миссии
Artemis II — это не «ещё один полёт к Луне», а проверка гипотезы: спутник Земли превращается из мемориала в стратегическую площадку, где сходятся наука, политика и космическая экономика. Как только на орбите появляется инфраструктура, которую нужно обслуживать, у ИТ-специальностей возникает вполне земная задача — строить информационные системы, способные работать там, где канал на десятки секунд запаздывает, железо не заменить, а телеметрия стоит дороже, чем сервер в дата-центре. Именно этот разрыв между «модным трендом» и «защищаемой инженерной задачей» чаще всего и проваливают на защите. Ниже — как превратить новость в конкретную ВКР с расчётами, схемами и метриками.
Три темы ВКР, которые вытекают из статьи
Тема 1. Цифровой двойник заправочной станции: прогноз остатка топлива и планирование дозаправок
Актуальность. Статья прямо говорит: борьба идёт за то, кто первым построит станцию. Победит не тот, у кого больше баков, а тот, кто точнее считает расход и окна дозаправки. Это классическая задача для информационной системы поддержки жизненного цикла.
- Цель: разработать прототип цифрового двойника, который по потоку телеметрии прогнозирует остаток компонентов топлива и формирует расписание дозаправок.
- Задачи: анализ источников телеметрии и модели расхода; выбор модели прогнозирования; проектирование архитектуры двойника и хранилища временных рядов; оценка точности и накладных расходов.
- Структура: гл. 1 — анализ предметной области и стандартов обмена (CCSDS, DTN); гл. 2 — архитектура, UML-диаграммы, схема БД, алгоритм прогноза; гл. 3 — эксперименты на синтетическом наборе данных, метрики, экономика внедрения.
Тема 2. Отказоустойчивый контур доставки телеметрии для дальних миссий
Актуальность. Пока Artemis II доказывает жизнеспособность сценария, эксплуатация станции упрётся в связь: разрывы, задержки, ограниченные окна видимости. Здесь ВКР перестаёт быть «сайтом с графиками» и становится распределённой системой.
- Цель: спроектировать контур доставки телеметрии с гарантией полноты при нестабильном канале.
- Задачи: сравнительный анализ HTTP/MQTT/DTN Bundle Protocol; проектирование буферизации на борту и на ретрансляторе; протокол дедупликации и упорядочивания; нагрузочное тестирование с имитацией задержек и потерь.
- Структура: гл. 1 — обзор протоколов и стандартов; гл. 2 — архитектура контура, sequence-диаграммы, отказоустойчивость; гл. 3 — стенд, сценарии отказов, расчёт RTO/RPO.
Тема 3. Экономическая модель космической заправки как обоснование ИТ-решения
Актуальность. Раз речь о «космической экономике», значит, кто-то должен считать, сколько стоит килограмм топлива на орбите Луны и какие ИТ-системы сокращают эту стоимость. Такая тема спасает дипломы, где «нет внедрения»: эффект считается на модели.
- Цель: построить модель совокупной стоимости владения (TCO) заправочной станции и оценить вклад ИС планирования в её снижение.
- Задачи: декомпозиция затрат (доставка, хранение, потери при перекачке, простой); модель сценариев; расчёт чувствительности; привязка метрик ИС к экономическим показателям.
- Структура: гл. 1 — анализ рынка и подходов к оценке; гл. 2 — модель и её программная реализация; гл. 3 — сценарные расчёты, окупаемость, ограничения модели.
Аналитическая глава: как сравнивать решения, а не пересказывать документацию
Первая глава обычно превращается в реферат. Чтобы этого избежать, привяжите анализ к статье: Artemis II — это проверка сценария, значит, требования к ИС формулируются из условий эксплуатации, а не из «хочется микросервисы». Введите 3–4 критерия (задержка доставки, полнота данных, стоимость эксплуатации, сложность сопровождения) и сведите варианты в таблицу — комиссия любит таблицы.
| Вариант обмена | Устойчивость к разрывам | Задержка | Сложность реализации | Когда выбирать |
|---|---|---|---|---|
| REST/HTTP | Низкая | Секунды-минуты | Низкая | Наземный сегмент, внутренние сервисы |
| MQTT | Средняя (QoS 1–2) | Секунды | Средняя | Датчики, телеметрия в реальном времени |
| gRPC | Низкая | Миллисекунды | Средняя | Связка сервисов ЦОД, не канал на Луну |
| DTN / Bundle Protocol | Высокая (store-and-forward) | Минуты и часы | Высокая | Канал с разрывами и длинными окнами видимости |
Обоснование стека пишите по схеме «требование → критерий → вариант → цена выбора». И зафиксируйте это в ТЗ по ГОСТ 34.602-89: там как раз есть места под требования к системе и к видам обеспечения. Одна оговорка: не тащите в диплом Kubernetes «для красоты» — он уместен для наземного сегмента (планировщик, API, обработка пакетов), но не для бортового контура с 64 МБ памяти.
Проектная часть: что должно быть на схемах
Проектирование в такой ВКР — это не только диаграмма классов. Минимум, который ожидает комиссия:
- Контекстная диаграмма (C4 level 1): борт, ретранслятор, наземная станция, цифровой двойник, потребители данных.
- Диаграмма последовательности для кейса «потеря пакета»: кто буферизует, кто подтверждает, что происходит с дубликатами.
- Схема потоков данных с временными метками и единицами измерения — половина вопросов на защите снимается, если у вас везде «кг/с» и «секунды UTC», а не абстрактные «единицы».
- Алгоритм прогноза в виде блок-схемы плюс псевдокод — этого достаточно, если нет времени на полноценный ML.
// Фрагмент сообщения телеметрии: минимум, который нужен двойнику
{
"ts_utc": "2026-04-02T11:14:07Z",
"object_id": "LRS-01",
"tank_id": "OX-A",
"mass_kg": 1240.5,
"temp_k": 91.3,
"pressure_kpa": 312.0,
"seq": 88412,
"link_session": "DSN-43-A"
}
Обратите внимание: поля seq и link_session — не украшение, а обязательные атрибуты для дедупликации и восстановления порядка при DTN-доставке. Именно на них строятся ваши выводы в третьей главе.
Тестирование и метрики: чем измерять, если станция не построена
Самый частый провал — глава «Тестирование» из трёх скриншотов. Выход простой: имитационный стенд. Эмулятор канала задаёт задержку и вероятность потерь, генератор телеметрии выдаёт поток по расписанию окон видимости, а вы снимаете метрики. Инструментарий — OpenTelemetry плюс любой сборщик временных рядов.
| Метрика | Как считать | Целевой ориентир | Свойство по ISO/IEC 25010 |
|---|---|---|---|
| Полнота доставки телеметрии | Доставленные / отправленные сообщения за сессию | ≥ 0,995 | Надёжность |
| p95 задержки доставки | Гистограмма по времени от генерации до записи в БД | ≤ 1,5 окна видимости | Производительность |
| RTO | Время восстановления после сбоя узла | ≤ 10 мин | Надёжность |
| RPO | Объём потерянных данных на момент сбоя | ≤ 1 сессия | Надёжность |
| MTTR | Среднее время до восстановления | по логам инцидентов | Сопровождаемость |
Дальше — оценка точности прогноза: MAE и MAPE по остатку топлива. Если получилось MAPE в районе 3–7 % на синтетике — это нормальный, честно защищаемый результат при условии, что вы описали генератор данных и его допущения.
Чему вы научитесь на такой работе
- Обосновывать архитектуру через условия эксплуатации, а не через моду.
- Проектировать отказоустойчивые потоки данных и считать RTO/RPO, а не просто «использовать Kafka».
- Строить имитационные стенды и оформлять методику эксперимента так, чтобы её можно было повторить.
- Связывать технические метрики с экономикой: TCO, потери, простой.
- Готовить документацию по ГОСТ 34 и ГОСТ Р 19 — навык, который проверяют на реальных проектах.
- «Мы использовали DTN, потому что это космос» — без сравнения с альтернативами и без расчёта цены сложности. Лечится таблицей выше и разделом «ограничения решения».
- Метрики без методики — «система быстрая, нагрузка 1000 запросов». Укажите частоту, длительность прогона, размер выборки и что считается ошибкой.
- ТЗ, написанное после кода — и не соответствующее ГОСТ 34.602-89. Комиссия сверяет состав требований с содержанием глав; расхождение видно сразу.
Вопросы, которые задают чаще всего
Как смоделировать канал «Земля — Луна», если реального стенда нет?
Достаточно эмулятора с параметрами: задержка 1,3–2,6 с в одну сторону, окна видимости по расписанию, вероятность потери пакета, ограничение полосы. Опишите параметры в третьей главе как допущения модели — это честнее, чем «тестирование проводилось в реальных условиях».
Обязательно ли писать работающий код?
Зависит от кафедры, но прототип всегда выигрывает. Минимально жизнеспособный вариант: генератор телеметрии, приёмник с буфером, хранилище и расчёт метрик. Это 500–800 строк — вполне посильно за месяц.
Где брать тестовые данные?
Открытые наборы по спутниковой телеметрии, синтетика по физическим моделям расхода, либо данные с учебных стендов кафедры. Главное — зафиксировать происхождение и ограничения набора в отдельном подразделе.
Как оформлять UML-диаграммы, чтобы их приняли?
Единая нотация в рамках всей работы, подписи на русском, обязательная легенда, ссылка из текста на каждую диаграмму. Диаграмма без упоминания в тексте — минус балл.
Чек-лист перед сдачей
- Каждая задача из введения закрыта выводом в соответствующей главе.
- Есть сравнение минимум трёх альтернатив с критериями и обоснованием выбора.
- Метрики сопровождаются методикой: условия, длительность, объём выборки.
- Схемы пронумерованы, подписаны и упомянуты в тексте.
- ТЗ и структура работы соответствуют ГОСТ 34.602-89, оформление — ГОСТ Р 19.
- Указаны ограничения решения и направления развития — это признак зрелой работы.
- Источник по теме процитирован корректно, дата публикации указана.
Источник: Флаг воткнули еще в 1969-м. Теперь речь идет о том, кто первым построит на Луне заправочную станцию (опубликовано 2026-03-30)