Опубликовано: 20.09.2026 | Источник: TechCrunch

Семантический анализ (служебный блок, можно удалить при вставке): поддомен — AI/ML + автономные системы (с элементами SRE и ИБ); роль — Data/ML-инженер, отвечающий за контур безопасности и телеметрию. Схема структуры — C. Primary keyword: «удалённое управление автономным транспортом в ВКР». LSI: ROS 2, DDS, MQTT, OpenTelemetry, CARLA, ODD, minimal risk condition, teleoperation latency, MTTR, disengagement rate, SOTIF. Сущности: ГОСТ 34, ISO/IEC 25010, OpenTelemetry, C4/UML, ISO 21448 (SOTIF), метрики поддомена.

Анализ автономных роботакси для ВКР: удалённое вмешательство и метрики безопасности

Введение

TechCrunch выяснил: сотрудникам экстренных служб приходилось брать управление на себя и вручную отгонять автомобили Waymo — минимум в двух случаях это происходило прямо на месте активного преступления. Формально машина «ехала сама». Фактически в контур управления вошёл человек, который не проходил никакого обучения работе с роботакси. Это не курьёз, а чистая инженерная задача: как система обнаруживает, что её операционная зона больше не покрывает реальность, кто получает приоритет управления и что происходит с каналом связи в этот момент.

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

Частые вопросы студентов по таким темам

1. Где брать данные, если доступа к логам Waymo нет и не будет?

Реальные логи закрыты, и это нормально. Открытые источники: Waymo Open Dataset, nuScenes, Argoverse — там есть сцены с пешеходами, спецтранспортом и сложными перекрёстками. Для сценариев вмешательства хорошо работает синтетика: CARLA или LGSVL позволяют программно воспроизвести «скорая перекрыла полосу», «оцепление», «автомобиль на месте ДТП». В главе про методы честно напишите, что используете симуляционный стенд из-за ограничений доступа к промышленным данным — это выглядит зрело, а не как отговорка.

2. Нужно ли ссылаться на ISO 26262 и выдумывать сертификацию?

Сертифицировать дипломный прототип не нужно и невозможно. Но сослаться на функциональную безопасность уместно: ISO 26262 задаёт уровни ASIL, а ISO 21448 (SOTIF) как раз про нештатные сценарии, где алгоритм работает «как спроектирован», но реальность иная. Именно в эту рамку идеально ложатся полицейские, перехватившие управление роботакси. Стандарты упоминаем в главе 1, но не заявляем соответствие.

3. Как считать эффективность, чтобы цифры не выглядели выдуманными?

Считайте то, что можно измерить на стенде: время от обнаружения аномалии до передачи управления оператору (MTTR), p95/p99 задержку канала, долю сценариев, завершённых переходом в Minimal Risk Condition, число выходов автопилота из ODD на 1000 км пробега. Каждую метрику — с формулой, источником данных и доверительным интервалом. Если в разделе «эффективность» нет ни одной формулы, комиссия почти наверняка спросит, откуда взялись проценты.

4. Обязательно ли собирать машину на макетке?

Нет. Достаточно SIL-стенда (software-in-the-loop): ROS 2 + симулятор + записанный трафик шины. HIL с реальным контроллером — плюс к оценке, но не обязателен, если вы честно описали допущения модели и ограничения переноса результатов на физический автомобиль.

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

• Тема 1. Подсистема удалённого ассистирования роботакси с арбитражем приоритетов управления.
  Актуальность: статья показывает, что третья сторона (полиция) может вмешаться в управление вне штатного протокола — значит, нужен формальный арбитр приоритетов.
  Цель: разработать модуль согласования управления между автопилотом, удалённым оператором и внешним воздействием.
  Задачи: классифицировать источники команд; спроектировать конечный автомат режимов; реализовать таймаут-политику при потере канала; протестировать на сценариях с экстренными службами.
  Структура: Гл.1 — анализ ODD и нештатных сценариев; Гл.2 — проектирование арбитра и протокола; Гл.3 — испытания в CARLA и расчёт MTTR.
• Тема 2. Телеметрия и мониторинг парка автономных ТС на базе OpenTelemetry.
  Актуальность: нельзя управлять тем, что не измеряешь: после инцидента нужно восстановить, кто и когда держал управление.
  Цель: построить наблюдаемость edge-узлов роботакси с трассировкой решений планировщика.
  Задачи: определить набор метрик и трасс; настроить коллектор и экспортёры; собрать дашборды; проверить деградацию при обрыве сети.
  Структура: Гл.1 — обзор подходов к наблюдаемости; Гл.2 — архитектура сбора данных; Гл.3 — эксперименты и оценка накладных расходов.
• Тема 3. Оценка безопасности сценариев взаимодействия с первыми респондентами (SOTIF-подход).
  Актуальность: активная сцена преступления — это сценарий, которого, скорее всего, не было в обучающем наборе, и он не покрыт требованиями.
  Цель: построить методику выявления опасных сценариев и оценки остаточного риска.
  Задачи: сформировать каталог сценариев; оценить покрытие ODD; предложить контрмеры; рассчитать остаточный риск до/после.
  Структура: Гл.1 — теория SOTIF и ODD; Гл.2 — модель угроз и сценариев; Гл.3 — оценка и рекомендации.

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

1. Глава 1 — анализ: где заканчивается ODD и начинается человек

Возьмите из статьи конкретный факт — вмешательство экстренных служб — и превратите его в класс сценариев. Полезно ввести три сущности: ODD (операционная область, в которой автопилот гарантирует работу), инцидент (событие вне ODD или с высоким риском) и MRM/MRC (маневр и состояние минимального риска). Дальше — таблица соответствия: какой сценарий какому требованию противоречит.

Схему взаимодействия удобно рисовать как C4-контекст. Текстовый слепок для вставки в пояснительную записку:

[First responder / Police] --> (Внешний интерфейс предписаний)
                                     |
                                     v
(Диспетчер удалённой поддержки) <--> (Шлюз телеметрии) <--> [Robotaxi Edge]
                                     |                              |
                                     v                              v
                            (Хранилище инцидентов)        (Арбитр управления)

2. Глава 2 — проектирование арбитра управления

Сердце работы — формальное правило: кто владеет управлением прямо сейчас и на каком основании. Ниже псевдокод, который можно развить в реальный модуль на Python или C++ с ROS 2. Логика описывается явно, с таймаутами, потому что обрыв канала — самый частый отказ в полевых условиях.

# Арбитр управления: автономия -> удалённый оператор -> внешнее предписание -> MRC
class ControlArbiter:
    # приоритет растёт сверху вниз: внешнее предписание сильнее автопилота
    PRIORITY = {"autonomy": 0, "remote_assist": 1, "external_order": 2, "mrc": 3}

    def __init__(self, telemetry, rtt_limit_ms=300):
        self.telemetry = telemetry
        self.rtt_limit_ms = rtt_limit_ms

    def resolve(self, request, scene_flags):
        # 1. Экстренные службы на месте -> уступаем и удерживаем позицию
        if scene_flags.emergency_vehicle_present:
            return "external_order", "yield_and_hold"

        # 2. Запрос удалённого оператора принимаем только при живом канале
        if request.source == "remote_assist":
            if self.telemetry.rtt_p99_ms > self.rtt_limit_ms:
                return "mrc", "pull_over_safe_spot"   # деградация вместо риска
            return "remote_assist", "trajectory_hint"

        return "autonomy", "continue"

Рядом — конфигурация сборщика телеметрии, чтобы каждый переход режима фиксировался как трасса, а не как строчка в логе:

receivers:
  otlp:
    protocols: { grpc: {}, http: {} }
processors:
  batch: { timeout: 2s }
  attributes/edge:
    actions: [{ key: "vehicle.id", from_attribute: "resource.vehicle_id", action: "upsert" }]
exporters:
  otlp/collector:
    endpoint: "telemetry-gw.internal:4317"
service:
  pipelines:
    traces:  { receivers: [otlp], processors: [attributes/edge, batch], exporters: [otlp/collector] }
    metrics: { receivers: [otlp], processors: [batch], exporters: [otlp/collector] }

В главе 2 обязательны: диаграмма состояний (autonomy / assist / external / mrc) и таблица сообщений протокола с полями, таймаутами и кодами ошибок. Развёртывание edge-компонентов описывайте через Kubernetes с ограничением ресурсов — иначе на защите спросят, почему планировщик «съел» всю память на бортовом компьютере.

3. Глава 3 — метрики, стенд и статистика

Здесь работа либо становится убедительной, либо рассыпается. Выберите 4–6 метрик и держитесь их во всех выводах.

Статистику не выдумывайте: 30–50 прогонов на сценарий, проверка на нормальность, затем t-тест или критерий Уилкоксона, доверительные интервалы на графиках. Пометьте допущения: симуляция не воспроизводит поведение реальных водителей, перенос выводов ограничен — честное ограничение повышает доверие к работе, а не понижает.

4. Нормоконтроль и стандарты качества

Структуру пояснительной записки удобно вести по ГОСТ 34 (стадии и этапы создания автоматизированных систем), а требования к качеству — по ISO/IEC 25010: у вас как минимум задействованы надёжность, безопасность и удобство использования интерфейса оператора. Каждую метрику раздела «эффективность» привяжите к характеристике качества — тогда раздел перестаёт быть набором чисел и становится частью системы требований. Не забудьте, что «ВКР на заказ» без собственного понимания метрик разваливается на первом же вопросе комиссии.

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

• формализовать нештатные сценарии и границы ODD, а не только «обучать модель»;
• проектировать арбитраж приоритетов управления с таймаут-политикой и деградацией в MRC;
• строить наблюдаемость edge-системы на OpenTelemetry и отделять метрику от лога;
• считать MTTR, перцентили задержки и долю безопасных завершений с доверительными интервалами;
• оформлять требования, схемы и приложения так, чтобы они проходили нормоконтроль с первого раза.

Источник: Who’s driving Waymo’s self-driving cars? Sometimes, the police. (опубликовано 2026-03-25)