Низкоорбитальная спутниковая группировка в ВКР: моделирование покрытия и метрики QoS
24 марта 2026 года на орбиту выведены первые 16 аппаратов российской низкоорбитальной группировки — страна включилась в гонку за высокоскоростным спутниковым интернетом, где пока лидирует Starlink. Для выпускника ИТ- или радиотехнического направления это не абстрактная новость, а готовый полигон для дипломного исследования: LEO-сети ломают привычные допущения наземных систем — задержка скачет из-за handover, покрытие зависит от орбитальной динамики, а наземный сегмент требует оркестрации и мониторинга не хуже, чем облачный. Разберём, как превратить этот тренд в защищаемую ВКР с расчётами, схемами и измеримыми метриками, а не в реферат «про спутники».
Три темы ВКР, которые вырастают из этой новости
Вариант 1. Моделирование зоны покрытия и пропускной способности LEO-группировки
Актуальность. Первые 16 аппаратов — это только начало развёртывания; вопрос «сколько спутников нужно, чтобы обслужить заданный регион» стоит перед проектировщиками прямо сейчас, а открытых методик для дипломного уровня мало.
Цель: разработать программный комплекс расчёта покрытия и оценки пропускной способности группировки для заданной территории.
- Проанализировать орбитальные параметры LEO-систем и модели распространения радиоволн;
- реализовать расчёт положений аппаратов по TLE-данным (SGP4) и построение зон видимости;
- выполнить расчёт энергетического бюджета линии для Ka/Ku-диапазона;
- оценить агрегированную пропускную способность и сравнить сценарии 16 / 60 / 150 аппаратов.
Структура: Глава 1 — обзор LEO-систем, орбитальная механика, стандарты 3GPP TR 38.811 и ITU-R; Глава 2 — архитектура ПО, алгоритмы прогноза положения спутников, схемы БД эфемерид; Глава 3 — верификация модели на эталонных расчётах и оценка погрешности.
Вариант 2. Наземный сегмент управления: микросервисы в Kubernetes с мониторингом OpenTelemetry
Актуальность. Запуск группировки — начало эксплуатации. Наземная инфраструктура (станции сопряжения, планировщик сеансов, биллинг, телеметрия) строится как распределённая система, и требования к ней жёстче, чем к обычному вебу: связь с аппаратом есть 5–10 минут за виток.
Цель: спроектировать отказоустойчивый наземный сегмент с гарантированным временем реакции на отказ.
- Сформулировать требования по ISO/IEC 25010 и ГОСТ 34.602-89;
- спроектировать микросервисную архитектуру (gRPC внутри, REST наружу), схемы развёртывания в Kubernetes;
- настроить сбор трассировок и метрик через OpenTelemetry + Prometheus;
- обосновать целевые RTO/RPO и проверить их хаос-тестами.
Структура: Глава 1 — анализ архитектурных стилей и предметной области; Глава 2 — проектирование (диаграммы C4, спецификации API, схема развёртывания); Глава 3 — нагрузочное тестирование, расчёт TCO.
Вариант 3. Сравнительный анализ протоколов канального уровня для низкоорбитальных сетей
Актуальность. Пока операторы конкурируют, в отрасли нет единого мнения: строить на DVB-S2X, на 5G NTN (3GPP Release 17) или гибридизировать с LPWAN для телеметрии. Сравнение с численными критериями — полноценная аналитическая работа.
Цель: выбрать протокольный стек для сценария «высокоскоростной доступ + служебный канал телеметрии».
- Систематизировать требования к каналу (задержка, джиттер, потери, энергопотребление);
- построить матрицу критериев и применить метод анализа иерархий;
- провести имитационное моделирование в NS-3 или симуляторе NTN;
- оценить экономику вариантов.
Структура: Глава 1 — теория и стандарты; Глава 2 — модель и методика оценки; Глава 3 — результаты экспериментов и рекомендации.
Аналитическая глава: как не скатиться в пересказ пресс-релиза
Первая глава — место, где большинство работ теряет баллы. Новость о запуске 16 аппаратов здесь работает как обоснование динамики рынка, но не как доказательство. Опирайтесь на измеримые сущности:
- параметры орбит (высота 500–1200 км, наклонение, число плоскостей) и их влияние на задержку распространения;
- стандарты и спецификации: 3GPP TR 38.811, DVB-S2X, ISO/IEC 25010 для нефункциональных требований;
- госты оформления: ГОСТ 34.602-89 для ТЗ на систему, ГОСТ 19.201-78 — если продукт чисто программный, ГОСТ 34.601-90 — стадии разработки.
| Технология | Задержка (RTT) | Пропускная способность | Энергопотребление терминала | Ниша применения |
|---|---|---|---|---|
| DVB-S2X | 25–60 мс | до 100+ Мбит/с на луч | высокое | широкополосный доступ |
| 5G NTN (R17) | 30–80 мс | гибко, зависит от полосы | среднее | интеграция с наземной сетью |
| LoRa / LPWAN | секунды | единицы кбит/с | низкое | телеметрия, IoT-датчики |
Проектная часть: что рисовать и что кодить
Проектная глава должна содержать артефакты, а не абзацы. Минимальный набор: диаграмма контекста и контейнеров (C4), схема развёртывания, спецификация API, диаграмма последовательности для критичного сценария (например, «планирование сеанса связи при входе спутника в зону видимости»).
Если тема связана с расчётом орбит, ядро проекта занимает немного кода — здесь важна корректность:
from sgp4.api import Satrec, jday
sat = Satrec.twoline2rv(tle_line1, tle_line2) # эфемериды из TLE
jd, fr = jday(2026, 3, 24, 12, 0, 0) # момент расчёта
err, r_eci, v_eci = sat.sgp4(jd, fr) # положение и скорость, км и км/с
Дальше координаты переводятся в топоцентрическую систему, считается угол места и азимут относительно станции сопряжения. Такой расчёт занимает 40 строк и даёт на защите куда больше веса, чем глава на 15 страниц.
Тестирование, метрики и то, о чём забывают в 90% работ
Нагрузочное тестирование спутникового сегмента напрямую железом не провести — и это нормально. Используйте имитационное моделирование и обоснованную экстраполяцию. Что закладывать в третью главу:
- QoS-метрики: задержка (медиана и 95-й перцентиль), джиттер, доля потерь пакетов, время прерывания при handover;
- Метрики надёжности наземного сегмента: RTO ≤ 5 мин, RPO ≤ 1 мин, доступность 99,9% (SLA), поведение при потере узла Kubernetes;
- Инструментарий: Prometheus + Grafana для сбора и визуализации, OpenTelemetry для сквозной трассировки запросов между сервисами, k6 или Locust для нагрузки.
| Метрика | Способ получения | Целевое значение (пример) |
|---|---|---|
| Задержка RTT | расчёт + имитационная модель | ≤ 60 мс для 95% запросов |
| Время handover | модель NS-3 | ≤ 100 мс, без разрыва сессии |
| RTO | хаос-тест, отключение pod | ≤ 5 мин |
| Доступность | Prometheus + расчёт SLA | 99,9% в месяц |
Чему вы научитесь на такой работе
- Обосновывать выбор стека через матрицу критериев, а не фразой «широко используется».
- Строить модели орбитальной динамики и считать бюджет линии связи.
- Проектировать распределённую систему и подтверждать отказоустойчивость экспериментом.
- Оформлять техническую документацию по ГОСТ 34 и описывать качество ПО через ISO/IEC 25010.
Три ошибки, которые чаще всего рубят баллы
- Подмена терминов без обоснования. «Развернём в Kubernetes» пишут, не объясняя, почему не хватает виртуальных машин. Решение — таблица сравнения вариантов с критериями (стоимость, масштабирование, сложность эксплуатации).
- Отсутствие измеримых метрик. Глава «тестирование» без чисел и методики их получения не проверяема. Заранее зафиксируйте, что и чем измеряете.
- Игнорирование ГОСТ 34.602-89. ТЗ, собранное на коленке, разваливает структуру работы. Сверьте состав разделов ТЗ до, а не после написания кода.
Частые вопросы студентов
Обязательно ли писать работающий код для такой темы?
Для технических направлений — да, хотя бы прототип. Достаточно расчётного модуля на 300–600 строк, который выдаёт воспроизводимые результаты. Аналитическая ВКР без кода допустима, но защищается сложнее: нужно доказать новизну методики.
Где брать данные для расчётов, если нет доступа к реальной телеметрии?
Используйте открытые TLE-каталоги (Celestrak), публичные спецификации 3GPP и параметры, опубликованные в отраслевых отчётах. Все источники указывайте в списке литературы — это ценится на защите выше «данных из головы».
Как оформить UML-диаграммы и схемы развёртывания?
Рисуйте в нотациях C4 или UML 2.5, экспортируйте в векторный формат и вставляйте в приложения. Каждая схема должна упоминаться в тексте и иметь подпись с расшифровкой обозначений.
Насколько сложно защитить тему, если группировка ещё только разворачивается?
Наоборот: отсутствие устоявшихся практик — ваш плюс. Вы предлагаете методику, а не пересказываете чужую. Если тема кажется слишком объёмной, её стоит сузить до одного сегмента — например, только наземной инфраструктуры.
Чек-лист перед сдачей
- Актуальность подкреплена ссылками на источники с датами, а не общими словами.
- Задачи во введении дословно совпадают с выводами по главам.
- Есть минимум 3 схемы: архитектура, алгоритм, сценарий взаимодействия.
- ТЗ оформлено по ГОСТ 34.602-89 или ГОСТ 19.201-78.
- Каждая метрика имеет методику измерения и целевое значение.
- Список литературы содержит нормативные документы и стандарты, а не только статьи из интернета.
Если тема уже выбрана, но не хватает времени на расчёты, схемы или оформление — с этим помогают справиться быстрее. Средний срок выполнения работы под ключ — от 120 часов работы эксперта, первая консультация бесплатная: обсудим вашу тему и подскажем, что в ней стоит усилить. Можно заказать диплом по своему направлению, а можно взять только отдельный блок — модель, расчётную часть или оформление.
Источник: Россия запустила первую группировку спутников для создания лучшей версии Starlink (опубликовано 2026-03-24)