Опубликовано: 19.10.2026 | Источник: SecurityLab (RSS)

Автономные экспедиции к Венере в ВКР: сенсорная фузия и отказоустойчивые ML-модели

В заметке про китайский проект речь идёт о том, что экспедиции к Венере хотят сделать автономными, а в заголовке мелькают керамика, лазеры и «маленькая хитрость» с углекислым газом. Для выпускника ИТ здесь ценна не сама космическая экзотика, а инженерная рамка: система должна работать там, где связь редкая, датчики деградируют, а решение принимать нужно на месте. Именно из этого получается защищаемая ВКР по AI/ML — не «обзор Венеры», а проект edge-контура с сенсорной фузией, проверкой отказов и понятными метриками. Ниже — как разложить такую тему по главам, какие схемы нарисовать и что считать, чтобы на защите звучали не общие слова, а архитектура, эксперимент и результат.

С чего начать, если Венера есть только на картинке: вопросы студентов

Где брать данные, если реальной миссии к Венере у меня нет?

Используйте три источника: открытые планетарные датасеты, симулятор и синтетические сценарии. Для бакалаврской ВКР достаточно одного полигона в Gazebo/ROS 2 и набора записанных «прогонов» с шумом, задержками и отказами датчиков. В тексте обязательно опишите генерацию данных и разделение train/validation/test по траекториям, а не по случайным строкам — иначе получите утечку данных и слишком оптимистичные метрики.

Какой стек выбрать: Python, C++ или что-то ещё?

Для прототипа хватает Python и ROS 2: быстрее собрать сенсорную фузию, детектор аномалий и логирование. C++ берите только для «горячего» участка, если по метрикам видно, что Python не укладывается в p95 latency. В ВКР не нужно доказывать промышленную готовность — нужно показать обоснованный выбор, замеры и границы применимости.

Как проверить отказоустойчивость без реального планетохода?

Через fault injection: программно «ломайте» один или два сенсора, добавляйте шум, задержку, пропуски кадров и смотрите, как ведёт себя модуль фузии. Монте-Карло по 100–300 прогонам даёт нормальную статистику для главы 3. Считайте не только F1, но и availability, p95 latency, число переходов в деградированный режим.

Как оформить архитектуру и код, чтобы не придрался нормоконтроль?

Архитектуру показывайте через C4 Level 1–2 и UML sequence для сценария «отказ дальномера». Текстовое описание — по ГОСТ 34/19, если в вузе требуют документы по автоматизированным системам. Полный код в основной текст не вставляйте: вынесите в приложение, а в главе 2 оставьте ключевой фрагмент, схему компонентов и таблицу принятых решений.

Темы ВКР, которые вырастают из новости

Новость полезна как повод сузить задачу до одного проверяемого сценария. Не берите «всю автономную миссию» — возьмите участок, где ИТ-решение можно измерить.

• Сенсорная фузия для автономного планетохода при деградации датчиков

  Актуальность: статья обещает автономность в агрессивной среде, значит, система не может рассчитывать на идеальные показания сенсоров. В ВКР вы моделируете отказ дальномера или камеры и проверяете, что модуль комплексирования не разваливается.

  Цель: разработать модуль сенсорной фузии для набора IMU + дальномер + камера/лидар с контролем достоверности и деградацией.

  Задачи: сравнить EKF/UKF и взвешенное голосование; спроектировать архитектуру по C4; реализовать симуляцию в ROS 2/Gazebo; провести fault injection и посчитать RMSE, F1, p95 latency, availability.

  Структура: глава 1 — анализ среды и требований по ISO/IEC 25010; глава 2 — архитектура, алгоритм и код; глава 3 — эксперименты, метрики и оценка деградации.

• ML-детектор аномалий телеметрии для автономной миссии

  Актуальность: керамика, лазеры и CO₂-«хитрость» — инженерные решения, но в ИТ-части миссии всё равно нужна телеметрия и раннее обнаружение отказов. В ВКР можно уйти от космоса в общий edge-мониторинг, а Венеру оставить как极限-кейс.

  Цель: построить детектор аномалий по временным рядам телеметрии с низкой задержкой на борту.

  Задачи: сформировать синтетический датасет; выбрать Isolation Forest или автоэнкодер; настроить сбор метрик через OpenTelemetry; оценить precision/recall/F1 и p95 latency; сравнить с пороговым baseline.

  Структура: глава 1 — обзор методов и постановка задачи; глава 2 — пайплайн данных и модель; глава 3 — эксперименты, ошибки первого и второго рода, рекомендации.

• Отказоустойчивая edge-архитектура автономной экспедиции

  Актуальность: если связь с Землёй редкая, решение должно приниматься локально. Это уже не про ML-модель, а про архитектуру: изоляция компонентов, fallback-политики, телеметрия и управление рисками.

  Цель: спроектировать edge-контур с деградацией функций и наблюдаемостью.

  Задачи: описать C4-контекст и контейнеры; построить UML sequence для отказа сенсора; реализовать fallback-политику; провести chaos testing; посчитать availability, MTTR и объём телеметрии.

  Структура: глава 1 — анализ архитектурных паттернов; глава 2 — проектирование и реализация; глава 3 — сценарии отказов и метрики надёжности.

Основная часть: как разложить кейс по главам

Глава 1: ограничения Венеры превращаем в требования, а не в описание планеты

В первой главе не нужно пересказывать научную новость на десять страниц. Возьмите из статьи триггер: автономная экспедиция в среде, где оборудование и связь — узкое место. Дальше формализуйте это в требования к ИТ-системе. Поможет таблица «фактор → требование → метрика».

Нарисуйте C4 Level 1 — кто взаимодействует с системой, и C4 Level 2 — контейнеры: сенсорный слой, модуль фузии, детектор аномалий, планировщик, телеметрия. Для сценария «дальнометр выдаёт шум» добавьте UML sequence: сигнал приходит, валидатор его отбрасывает, фузия переходит в безопасный режим, событие уходит в лог. Это уже не картинка ради картинки, а доказательство, что вы понимаете поведение системы.

Глава 2: edge-контур и сенсорная фузия без магии

Проектируйте контур линейно: датчики → предобработка → валидация → фузия → детектор аномалий → решение → actuator. В главе 2 объясните, почему выбрали конкретный фильтр и как ограничили его сложность. Например, для бакалаврской ВКР достаточно EKF и простого gate по достоверности, если затем вы честно покажете границы: на каких сценариях алгоритм ошибается.

from dataclasses import dataclass
from statistics import median

@dataclass
class SensorFrame:
    name: str
    value: float
    conf: float

def robust_fusion(frames: list[SensorFrame]):
    valid = [f for f in frames if f.conf > 0.3]
    if len(valid) < 2:
        return {"mode": "degraded", "value": None}

    values = [f.value for f in valid]
    weights = [f.conf for f in valid]
    fused = sum(v * w for v, w in zip(values, weights)) / sum(weights)
    spread = max(values) - min(values)

    # Мягкий gate: при большом разбросе не доверяем среднему
    if spread > 2 * abs(median(values)) * 0.1:
        return {"mode": "suspect", "value": median(values)}

    return {"mode": "ok", "value": fused}

Код в главе 2 — иллюстративный. Полную реализацию, тесты и конфиги выносите в приложение. В тексте покажите, какие решения приняты: почему порог confidence равен 0.3, как выбирается медиана при подозрении на выброс, что происходит при переходе в degraded. Это те вопросы, которые задают на защите, и на них лучше ответить таблицей параметров, а не фразой «подобрано экспериментально».

Глава 3: метрики, OpenTelemetry и честная эффективность

Эффективность в такой ВКР — не «модель работает хорошо», а набор измеримых величин. Для ML-части смотрите F1, precision/recall и RMSE; для edge-части — p95 latency, потребление памяти, availability и MTTR. Если вы ссылаетесь на качество ПО, привяжите метрики к ISO/IEC 25010: надёжность, производительность, удобство сопровождения. Для наблюдаемости используйте OpenTelemetry: даже учебный стенд выигрывает, когда события и метрики собраны единообразно.

Нормоконтроль: ГОСТ 34/19, C4/UML и приложения

Если вы решаете, как написать ВКР по автономным системам и не утонуть в оформлении, начните с карты документов. ГОСТ 34/19 пригодится для технического задания и описания автоматизированной системы, C4/UML — для архитектуры, а приложения — для кода, конфигов и протоколов экспериментов. Не вставляйте скриншоты терминала вместо листинга: нормоконтроль любит структуру, подписи и ссылки в тексте. Каждая диаграмма должна упоминаться в тексте, иначе она превращается в декорацию.

Чему вы научитесь на таком кейсе

• Переводить экстремальные условия из новости в требования, ограничения и метрики.
• Проектировать сенсорную фузию с валидацией данных и безопасной деградацией.
• Считать F1, RMSE, p95 latency и availability, а потом объяснять их на защите.
• Оформлять архитектуру через C4/UML и документы по ГОСТ 34/19.
• Настраивать наблюдаемость edge-контура через OpenTelemetry и журналы экспериментов.

Чек-лист перед сдачей

Типичные ошибки студентов

Мягкий следующий шаг

Источник: Венера не даёт себя изучать, но китайцы придумали, как её обмануть: керамика, лазеры и маленькая хитрость с углекислым газом (опубликовано 2026-03-30)