Беспилотный транспорт в городе: скрытые риски и протоколы безопасности

Его работа зависит от того, как система распознаёт пешехода у края тротуара, реагирует на перекрытую полосу и выбирает действие, когда сигналы от камеры, радара и карты расходятся. В таких ситуациях цена ошибки измеряется не только ремонтом автомобиля. На кону безопасность людей и вопрос, кто отвечает за последствия.

Поэтому пробег автономного парка сам по себе мало говорит о готовности технологии к повседневной эксплуатации. Он показывает, что система умеет двигаться в определённых условиях. Но городская среда постоянно подбрасывает сочетания факторов, которые трудно исчерпывающе воспроизвести на тестовом маршруте: временные знаки, припаркованные у перехода фургоны, дорожные работы, жесты регулировщика, снег на разметке. Разговор о безопасности беспилотного транспорта в городских условиях начинается именно с этой разницы между демонстрацией работоспособности и управлением риском.

Статистика против реальности: почему городская среда сложнее шоссе

Сводная статистика аварийности удобна для сравнения, но у неё есть пределы. На результат влияют выбранная территория, тип дорог, пробег, состав транспортного потока и способ классификации происшествий. Важно и то, с чем именно сравнивают беспилотник: с водителем-человеком в тех же условиях или с общей статистикой поездок, где маршруты и обстоятельства могут быть другими.

Не вся система с автоматизацией одинаково автономна. В автомобилях с системами помощи водитель должен следить за дорогой и быть готовым вмешаться. В беспилотном автомобиле заданной степени автоматизации такую задачу в пределах определённой зоны выполняет система, хотя условия её работы и порядок действий при сбое всё равно ограничены. Если объединить эти случаи в одну цифру, сравнение становится менее полезным: в статистике окажутся разные режимы управления и разные обязанности человека.

Для города особенно важен не только факт столкновения, но и его контекст. На прямом участке шоссе задача может сводиться к удержанию дистанции и распознаванию препятствия. На перекрёстке система одновременно оценивает сигнал светофора, положение машин, намерения пешеходов и возможность безопасно завершить манёвр. Причём поведение участников движения не всегда соответствует правилам. Пешеход может начать переход вне перехода, велосипедист внезапно изменить траекторию, а водитель соседнего автомобиля жестом предложить проехать.

Такой эпизод трудно описать одной метрикой аварийности. Нужно знать, что автомобиль видел, какие данные получила система, какие действия рассматривала и почему выбрала конкретное. Без этих сведений цифра в отчёте не отвечает на главный вопрос: ошибка возникла из-за отказа оборудования, пределов распознавания или неверной логики принятия решения?

Средняя аварийность описывает парк в целом. Для городской безопасности важны сценарии, в которых система теряет уверенность и должна выбрать безопасное действие.

Условия работы тоже меняются от района к району. Улица с понятной разметкой и стабильной связью не равна участку, где дорогу перекрыли, а временный знак поставили рядом с постоянным. Снег может закрыть линии разметки, блики затруднить работу камеры, а плотная парковка сузить обзор на переходе. Эти обстоятельства не означают, что беспилотный автомобиль обязательно ошибётся. Они показывают, почему результат испытания на одном маршруте нельзя автоматически переносить на весь город.

Анатомия сбоев: отказ техники и ограничение алгоритма

Разбирать инцидент удобнее, если различать два класса проблем. Первый связан с неисправностью компонента или ошибкой в его работе. Второй возникает, когда оборудование функционирует, но система сталкивается с ситуацией, которую она распознаёт или оценивает недостаточно надёжно.

ISO 26262 посвящён функциональной безопасности дорожных транспортных средств и работе с опасностями, вызванными отказами электрических и электронных систем. В центре внимания здесь, например, неисправность тормозного привода, потеря сигнала датчика или дефект программного компонента. Для анализа используют инженерные методы оценки отказов и их последствий. В стандарте предусмотрены уровни ASIL, которые помогают соотносить опасность сценария с требованиями к мерам безопасности.

ISO 21448, известный как SOTIF, рассматривает другой класс рисков: опасное поведение, которое может возникнуть и при исправных компонентах, если система имеет функциональные ограничения или неверно использует доступную информацию. Камера может работать штатно, но не распознать объект в сложном освещении. Алгоритм может корректно получить данные, но ошибочно оценить ситуацию с жестом регулировщика. Это не обязательно означает поломку детали. Слабое место может находиться в возможностях системы, в данных, на которых она обучалась, или в правилах, по которым она выбирает действие.

Для автономного автомобиля эти рамки дополняют друг друга. Наличие резервного датчика может помочь при отказе основного, но не гарантирует правильного решения, если оба источника данных не дают системе надёжно понять, что происходит. И наоборот, качественная модель распознавания не заменит безопасное поведение при потере питания или связи с критическим компонентом.

Практическая работа начинается с описания сценариев. Инженеры определяют, какие условия могут привести к опасной ситуации, как система должна их обнаруживать и что делать при неопределённости. Затем сценарии проверяют в симуляции, на испытательном полигоне и, где это допустимо, в реальном движении. Каждый способ проверки имеет ограничения. Симуляция позволяет многократно воспроизводить редкие события, но зависит от точности модели. Натурные испытания дают данные из реальной среды, однако не могут заранее охватить все сочетания погоды, поведения людей и состояния дороги.

Стандарты безопасности: от ISO 26262 до внедрения ГОСТ Р ИСО 21448

Стандарты задают общую инженерную рамку, но сами по себе не превращают автомобиль в безопасную систему и не заменяют решение регулятора о допуске к эксплуатации. Их значение в другом: они помогают разработчикам последовательно описывать опасности, распределять ответственность между участниками разработки и документировать работу с рисками.

Для SOTIF это особенно важно, потому что функциональные ограничения не всегда можно устранить простой заменой неисправной детали. Разработчику приходится находить ситуации, в которых система может ошибиться, уточнять условия её работы и проверять, как она ведёт себя при нехватке информации. Результатом становится не обещание, что сбоя не будет, а обоснование того, как выявляют и снижают риск.

В России появился национальный стандарт ГОСТ Р ИСО 21448-2025, посвящённый безопасности заданной функциональности. Его появление даёт участникам рынка общую нормативную точку отсчёта и возможность выстраивать процессы с учётом национального стандарта. При этом нельзя сводить вопрос к формуле «есть ГОСТ — есть безопасность». Документ не доказывает автоматически, что конкретная система испытана на всех типичных для конкретного города сценариях. И отсутствие ссылки на него само по себе не позволяет заключить, что производитель вообще не способен документировать результаты своих проверок.

Для российских условий важна содержательная часть валидации. Разработчику нужно понимать, как система работает при скрытой снегом разметке, на нерегулируемом переходе, рядом с дорожными работами и в потоке, где одновременно присутствуют легковые автомобили, автобусы, маршрутный транспорт и велосипедисты. Это не универсальный список и не требование стандарта, а набор примеров факторов, которые могут повлиять на работу системы в конкретной зоне эксплуатации.

Документация здесь не должна превращаться в стопку отчётов, созданных ради аудита. Хороший процесс связывает сценарий с наблюдаемым поведением автомобиля: что именно система обнаружила, какой риск оценила и какой манёвр выбрала. Если в испытании обнаружилась слабость, важно проследить, как изменение программного обеспечения повлияло на прежние результаты. Иначе исправление одного случая может незаметно ухудшить поведение в другом.

Для оператора и производителя это означает заметную работу до начала коммерческих поездок: сбор данных, моделирование, испытания, анализ изменений и описание ограничений системы. Масштаб такой работы зависит от конструкции автомобиля, территории эксплуатации и выбранного подхода к проверке. Универсальную долю затрат на SOTIF-валидацию назвать нельзя: она меняется от проекта к проекту, а неподтверждённая точность здесь скорее вводит в заблуждение.

Киберуязвимости и V2X: новые векторы атак на автономные парки

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

Одна группа рисков связана с ошибками в программном обеспечении и недостаточным разграничением доступа. Если разные функции автомобиля используют общие привилегии, проблема в одном компоненте может затронуть больше систем, чем предполагалось. Поэтому важно разделять критические контуры, контролировать доступ и регулярно проверять, какие данные могут передаваться между компонентами.

Обновления по воздуху позволяют менять программное обеспечение без доставки каждой машины в сервис. Но удобство создаёт и новую задачу: оператор должен подтвердить подлинность обновления, контролировать его распространение и иметь безопасный порядок действий, если после установки обнаружится проблема. Важна не только защита сервера обновлений. Нужны также проверка пакета на стороне автомобиля и возможность не допустить запуска неподтверждённого кода.

Отдельная область риска связана с V2X, обменом данными между автомобилем и другими объектами, например элементами дорожной инфраструктуры. Такая связь может передавать полезную информацию, но автомобиль не должен безусловно доверять каждому полученному сигналу. Он должен учитывать происхождение сообщения, его актуальность и согласованность с данными собственных датчиков. Иначе ошибочная или подменённая информация способна повлиять на решение системы.

Связь с телеоператором также нуждается в ясных границах. Удалённый специалист может помогать разбирать сложную ситуацию или подтверждать доступность маршрута, однако это не обязательно означает, что он управляет автомобилем в реальном времени. Если канал связи недоступен, автомобиль должен иметь заранее определённый безопасный режим: например, остановиться в допустимом месте или выполнить другое действие, предусмотренное проектом. Конкретное поведение зависит от конструкции системы и условий эксплуатации.

Практическая защита складывается из нескольких привычек инженерной дисциплины:

1. Разделять критические автомобильные функции и менее чувствительные внешние сервисы, чтобы сбой одного компонента не открывал доступ ко всему контуру.

2. Проверять обновления и фиксировать, какая версия программного обеспечения установлена на каждом автомобиле.

3. Сопоставлять внешние сообщения с данными собственных датчиков и не считать сигнал инфраструктуры безусловной командой.

4. Заранее описывать безопасное поведение при потере связи, сбое сервиса или подозрительной активности.

5. Сохранять данные, необходимые для анализа инцидента, с соблюдением правил безопасности и защиты информации.

Кибербезопасность здесь не отдельный модуль, который можно установить после завершения разработки. Она связана с архитектурой автомобиля, организацией обновлений и тем, как оператор реагирует на нештатную ситуацию. Чем больше машин в парке, тем важнее единый порядок управления версиями, обнаружения аномалий и расследования событий. При этом наличие такого порядка не гарантирует, что атака невозможна. Его задача состоит в том, чтобы снижать вероятность компрометации и ограничивать последствия.

Регуляторный надзор: как отчетность NHTSA формирует культуру прозрачности

В США NHTSA использует Standing General Order (SGO) как механизм сбора сведений о некоторых происшествиях, связанных с системами автоматизации. Порядок распространяется на определённых производителей и операторов и охватывает случаи, подпадающие под установленные критерии. Это не означает, что любой инцидент с беспилотником автоматически должен передаваться регулятору по одному универсальному правилу. Обязанности зависят от применимых требований и обстоятельств конкретного случая.

Смысл такой отчётности выходит за пределы отдельной формы. Регулятор получает возможность сопоставлять сведения о происшествиях, задавать вопросы и следить за тем, как меняется характер событий. Для внешнего наблюдателя это помогает увидеть, какие инциденты попадают в поле внимания, хотя сама база не заменяет расследование и не всегда содержит весь контекст, необходимый для оценки причин.

Особенно важно не смешивать регистрацию события с установленной ответственностью. Сам факт внесения информации в отчётность не доказывает, что виноват производитель, оператор или другой участник движения. Сначала нужно разобраться, что происходило, какие функции были активны и кто контролировал автомобиль в этот момент. Регуляторная отчётность создаёт основу для проверки, а не готовый вывод о виновности.

Отчётность полезна тогда, когда за записью об инциденте можно восстановить контекст: условия движения, режим работы системы и последовательность решений.

Для оператора это означает необходимость наладить сбор данных и внутренний разбор происшествий. Нужно понимать, какие сведения сохраняются, как быстро их можно связать с конкретной поездкой и кто отвечает за взаимодействие с регулятором. Такая функция требует компетентных сотрудников, но её организационная форма зависит от размера компании и требований, применимых к конкретной деятельности. Универсального требования создавать отдельную должность для каждого оператора из одного только факта существования SGO не следует.

Отчётность важна и для разговора о правовых аспектах эксплуатации роботакси. При происшествии могут возникнуть вопросы к изготовителю, оператору парка, поставщику программного обеспечения и человеку, который дистанционно наблюдал за поездкой. Ответ зависит от обстоятельств, действующих правил и того, как распределены обязанности. Поэтому фраза «виноват алгоритм» не помогает ни пострадавшему, ни расследованию. Нужно установить, какая часть системы приняла решение, какие ограничения были заявлены и соблюдались ли процедуры эксплуатации.

Риски для городской программы не ограничиваются страхованием или требованиями отчётности. Если автомобиль не может безопасно проехать временно изменённый участок, он может задержать движение или потребовать помощи. Если система часто выбирает осторожную остановку там, где обычный водитель продолжил бы путь, это снижает пропускную способность и усложняет работу службы поддержки. Если маршруты проложены только по наиболее предсказуемым улицам, польза для части города окажется ограниченной.

Поэтому интеграция беспилотного транспорта требует работы не только над автомобилем. Оператору нужно согласовать маршруты и сценарии эксплуатации с реальными особенностями улиц, предусмотреть взаимодействие с дорожными службами и определить порядок помощи при блокировке движения. Город, со своей стороны, должен учитывать, как автономные машины взаимодействуют с пешеходами, общественным транспортом, велосипедистами и обычными водителями. Технология не существует отдельно от этой среды.

Экономика барьеров: что скрывается за стоимостью поездки

Экономику роботакси часто сводят к цене автомобиля и выручке за поездку. Для города такой расчёт неполон. В нём должны учитываться работа дистанционного мониторинга, техническое обслуживание, обновления программного обеспечения, проверки безопасности, страхование, реагирование на инциденты и взаимодействие с регулирующими органами. Набор расходов и их доля зависят от модели бизнеса и местных правил; точку безубыточности нельзя вывести из универсального количества машин или одной заданной загрузки.

Капитальные затраты связаны с автомобилем, сенсорами, вычислительной платформой и инфраструктурой, которую проекту требуется поддерживать. Эксплуатационные расходы складываются из обслуживания парка, диспетчеризации, ремонта и анализа данных. К ним добавляется работа с безопасностью: испытания новых версий, проверка сценариев, защита цифровых систем и расследование отклонений. Если обновление меняет поведение автомобиля, его нельзя оценивать только как обычный программный релиз. Нужно понимать, что именно изменилось и не затронута ли уже проверенная функция.

Страхование тоже нельзя описать одной рыночной надбавкой. Условия зависят от юрисдикции, распределения обязанностей, данных об эксплуатации и характера покрытия. Пока рынок накапливает опыт, сравнивать цену полиса для роботакси с полисом обычного такси без одинаковых условий и подтверждённых данных некорректно. Для оператора важнее выяснить, какие риски покрываются, как рассматриваются происшествия и какие сведения нужны страховщику для оценки парка.

Масштабирование способно снизить часть расходов, но не отменяет инженерную сложность. Большой парк может эффективнее использовать диспетчерскую инфраструктуру, однако одновременно усложняет контроль версий программного обеспечения, анализ событий и реагирование на проблему, затронувшую несколько машин. Рост числа автомобилей поэтому не гарантирует автоматического улучшения экономики. Он увеличивает и потенциальную выручку, и цену организационной ошибки.

Для оценки проекта полезнее разложить расчёт на проверяемые предположения: сколько времени автомобиль проводит в работе, как часто ему требуется вмешательство, как устроено обслуживание, где действует разрешение на поездки и какую часть маршрутов система действительно может выполнять автономно. Если оператор не раскрывает эти условия, итоговая цифра окупаемости мало что говорит. Особенно если в неё не включены расходы на валидацию, поддержку и работу с нестандартными ситуациями.

Городская автономность не упирается в один решающий барьер. Риск складывается из множества элементов: возможностей сенсоров, логики алгоритма, качества связи, организации парка и правил эксплуатации. Вопрос не в том, можно ли однажды проехать без водителя по знакомому маршруту. Вопрос в том, насколько система предсказуема, когда город меняется вокруг неё, и можно ли после ошибки понять, что произошло и как не допустить повторения.

Поэтому оценивать безопасность автономных автомобилей в городе стоит по двум направлениям. Первое касается поведения машины в заранее описанных и проверенных сценариях. Второе касается прозрачности: какие ограничения заявлены, как оператор отслеживает инциденты и каким образом изменяет систему после выявленных проблем. Именно эта связка инженерной проверки и честной отчётности делает беспилотный транспорт частью городской среды, а не просто технологической демонстрацией.