Когда я только шел в AV два года назад, я думал, “а как оно там?”. Было ощущение, что AV это почти полностью про компьютерное зрение и прочее AI, т.е. ну совсем не моё и что лично мне там делать был большой вопрос. Но на деле оказалось, что это сильно не так, около 90% работы в данном домене вообще никак не связанны с AI задачами. На сегодня есть ощущение что у меня сложилась относительно полная картина о том, что же может ждать разработчика в автономных каретах. Тут я не планирую вдаваться ни в какие технические решения, а просто приведу общий обзор потенциальных направлений работы для IT-специалистов в данном домене.

Направления работ

Основных направлений работа несколько: автономный стек, инфраструктура, железо, безопасность, облака и аналитика. Само собой есть еще множество более мелких направлений, я выдели самые крупные. Наверное самыми неожиданными в списке будут два последних пункта, но без них реально никуда.

Автономный стек

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

Основной акцента в этой области будет на исполнении маршрута, компьютерном зрении и детектировании объектов, предсказании поведения других участников дорожного движения, построении траекторий, выборе наилучшей траектории из имеющихся, локализация машины в пространстве, контроля за ODD и т.д. Команды в которых придется работать всегда крайне крутые, много PhD, люди часто делают то, что никто и никогда до них еще не делал. Задачи интересный, но и конкуренция очень высокая. Отбор как в космонавты? Очень даже может быть.

Инфраструктура

Я, кстати, в Motional изначально попал в инфраструктуру. Когда мне HR сказал об этом направлении, ощущение было… “я что, DevOps?”. Но нет, это вообще не про DevOps, а про Robotics Infrastructure. Если вы когда-либо слышали такие слова как ROS, DDS, то это именно оно.

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

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

Железо

Мне кажется, самоходные кареты просто рай для железячников. Во-первых, тут реально требуется очень много специалистов в области железа. Во-вторых, железо очень разное, часто специально созданное под решение конкретных задач в конкретной компании. Для всего этого железа надо дорабатывать драйвера, запускать Linux или QNX, портировать ПО. Многие задачи так или иначе пересекаются с механизмами захвата и передачи видео потока (GStreamer, RTP). При этом наиболее впечатлившим лично меня моментом была железяка, которая позволяет загрузить нейронку напрямую и получать поток из детектированных на видео объектов. Наверное, для кого-то это банальность, но…

Облака

Облаков в той или иной форме оказывается неожиданно много. Автономная машина 4-ого уровня (а у фактически всех AV компаний цель именно такая) без централизованного управления сравнительно беспомощна и облака выглядят наиболее разумным решением всех проблем с какими автономная система может столкнуться. А столкнуться она может с:

Планирование маршрута

Что бы куда-то приехать, нужно рассчитать маршрут. Тут, с одной стороны, классический поиск кратчайшего пути, а с другой попытка остаться в рамках ODD, т.к. сильно не факт что машина знает как проехать по любой улице в городе, удовлетворить пассажира по требованиям к маршруту, отследить закрытые по тем или иным причинам маршруты и т.д.

Удаленное управление

На сегодня это самое близкое мне направление. Сюда входит организация помощи машине человеком если автономный стек не знает что делать дальше. В рамках 4-ого уровня автономности таких ситуаций будет много. По большому счету тут окажутся все ситуации которые попадают в исключения ПДД. Самым простым и наглядным примером можно считать объезд препятствия по встречке. Такой маневр будет за пределами ODD, но иногда его совершать надо. Тут то живой человек за удаленным компьютером и пригодится, т.к. только он может разрешить автономному стеку это сделать.

Построение 3D карты

В данной сфере будет много геометрии и тех или иных преобразований облаков точек полученных с радаров и лидаров в 3D пространства, а так же разметка и обновление карт и т.п. Почему в облаках? Потому что в рамках 4-ого уровня машина может ехать только по знакомой территории и эту территорию так или иначе нужно подготовить в (полу)автоматическом режиме. Что-то, безусловно, можно сделать и в машине на ходу, но с учетом объемов данных скорее всего хотя бы часть работы будет в облаке.

Анализ логов

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

Безопасность и надежность

В этой области для меня реально были сюрпризы. Кстати, я не описался, тут есть и безопасность (security) и надежность (safety). Направления совершенно разные и, по большому счету, не пересекающиеся.

Безопасность

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

Надежность

А вот это направление неожиданное, если только разработчик не из какого-то другого транспортного направления (автомобилестроение, авиация, кораблестроение). Всем рулит его величество ISO 26262, вокруг которого всё и вертится.

Сюда попадет всё, начиная от анализа требований и выдвижения специфических ограничений связанных с надежностью, заканчивая требованиям к правилам написания кода (AUTOSAR C++, MISRA C++) и статическому анализу кода. Всё это приводит к очень серьезному отношению к качеству кода и техническому долгу. Более качественной кодовой базы, на моей практике, я вообще не встречал.

Аналитика

В большинстве направлений в IT (кроме банкинга, наверное), аналитики птицы редкие и не шибко уважаемые. В случае с самоходными каретами ситуация в корне отличается. Тут хотелось бы польстить направлению и сказать об осознанности работающих в нём людей, но я не буду. На мой взгляд основным стимулом для активного привлечения аналитиков является тот самый ISO 26262, который накладывает ограничения на управления требованиями и делает требования необходимыми артефактами. При этом лично мне это очень нравится, т.к. все аналитики – это люди с профильным образованием (робототехника, ИИ и т.п.) и возможность получить хорошо продуманные и структурированные требования бесценна.

UI всяческое

В отличие от многих других направлений, в самоходных каретах UI представлен крайне мало и довольно специфичен. Во-первых, в любой машине будет присутствовать какой-либо HMI (Human Machine Interface) в виде планшета. Скорее всего это будет какая-то планшетка на Android. Во-вторых, так как речь идет про 4-й уровень автономности, будут иметь место утилиты для помощи в разметке дорог. В-третьих будет что-либо для удаленного управления автомобилем и коммуникаций с пользователем. Для второго и третьего случаев скорее всего будут иметь место какие-то приложения на Qt с активным использованием GPU для отрисовки 3D пространства.

Языки и стандарты

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

C++

С++ является одним из основных языком для разработки автономного стека. Как мне видится основная причина в этом снова в ISO 26262, накладывающем ограничения на надежность кодовой базы для компонентов уровня ASIL-D. Несмотря на то, что компонент уровня ASIL-D в машине обычно не много (основная масса компонентов QM уровня), они там есть и им как-то надо интегрироваться с остальными подсистемами, да и единообразие в коде штука полезная. В роли транспортного уровня (снова обычно) будет выступать DDS (стандарт описывающий pub-sup систему). Интереснее детали – смотрите ROS!

Сразу напрашивается вопрос, “а почему не Rust?”, он же безопасный и вообще. Насколько я понимаю ситуацию, Rust действительно можно использовать для компонент уровня QM. При этом, какого-то улучшения в вопросах безопасности решения по сравнению с C++, который основательно обвесили статическими и динамическими анализаторами (всё как в ISO 26262 любят), он не дает. А зачем вносить неразбериху и неоднородность в кодовую базу и получать проблемы интеграции со специфическими C++ библиотеками? В итоге Rust вроде и подошел бы, но его нет и скорее всего не будет как минимум до тех пор, пока не появится реализация DDS для Rust коммерческого уровня.

Python

Количество Pyhon-а в коде будет варьироваться от подразделения к подразделению. Само собой его невероятно много у ученых и основательно меньше у всех остальных. Python как всегда популярен в автоматизации процессов и тестировании, в остальных задачах практически не заметен.

А в облаках…

А в облаках как в облаках. На мой взгляд, каких-то отличий он любого другого AWS/GCP продуктов ожидать не стоит. Задачи разноплановые, начиная от достаточного тяжелого процессинга логов или управления аудио и видеоптоками, заканчивая обеспечением работы рабочих станций операторов поддержки и удаленного управления флотом. Задачи найдутся на любой вкус, но каких-то серьезных отличий от любого другого не AV направления ожидать не стоит.

Тестирование

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

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

В чем подвохи?

Ну и, наверное, стоит сказать о том, какие потенциальные подвохи есть в данной доменной области. Во-первых, ни одной коммерчески эксплуатируемой автономной системы 4-ого уровня на дороге на момент написания заметки нет, в лучшем случае есть тестовые запуски коммерческой эксплуатации, часто с safety driver за рулём. Во-вторых, на рынке текущий момент на рынке есть всего 2 (!!) машины 3-его уровня автономности (Хонда и Мерседес). Всё это означает что совершенно любая компания занимающаяся самоходными каретами не генерирует прибыли и зависит от инвестиций. На рынке периодически случаются поглощения, куда реже закрытия компаний. Как пойдет всё дальше никто не знает, но все полагают что хорошо, т.к. рынок невероятно жирный и заскочившие в него в числе первых получат огромные прибыли. Таким образом, если хочется чего-то очень стабильного, на десятилетия (пользуясь случаем передаю привет Autodesk), то работа в самоходных каретах не самая лучшая опция. Во всех остальных случаях, самоходные кареты крайне интересное направление работы.