Когда мне было 20 лет, я научил свою тогдашнюю девушку водить машину. Как и у меня, у нее были две руки, две ноги, приличное зрение (после коррекции, отмечает DMV), хорошее ухо и человеческий мозг. Я хорошо понимал ее навыки пространственного мышления, ее склонность к риску и то, как она отреагирует на коучинг (не очень хорошо). Все это означало, что, наблюдая с пассажирского сиденья, я мог понять, что она делает, догадываться, почему она это делает, утверждать, было ли это хорошей практикой вождения, и давать ей действенные отзывы.

Теперь рассмотрим разницу между обучением водителю и программированием компьютера.

Хотя бы раз в день во время кодирования я спрашиваю: «А почему ЭТО случилось?» Конечно, компьютер не ответит. Компьютер не может объяснить, что он видел, потому что он не видит. Он не может объяснить, о чем думает, потому что не думает. Бесполезно объяснять ему, каким должен быть результат или как он должен быть получен. Только когда я пойду и изменю выполняемый набор инструкций, его поведение изменится - надеюсь, к лучшему.

Неудобная правда заключается в том, что программное обеспечение для автоматизированных транспортных средств - это тот же самый вид программного обеспечения, которое мы всегда писали, с добавлением нескольких моделей машинного обучения, которые лучше работают с узкими задачами. Остальной код - это операционная система; драйверы, взаимодействующие со специализированным оборудованием; распределенные процессы, преобразующие данные в другие данные, затем в другие данные, а затем в решения; мониторы готовы подать сигнал тревоги в случае зависания одного из этих процессов. И это просто чувство-план-действие, управление одним роботом, к которому мы привыкли. В производственном масштабе добавьте картографические серверы, устройства дистанционного управления, связь V2X и (о да!) Пользовательский интерфейс. Все это программное обеспечение: некоторые написаны сообществом разработчиков ПО с открытым исходным кодом, некоторые - поставщиками, некоторые - интеграторами. В основном вручную.

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

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

Рассмотрим пример из собственного опыта. В RightHook мы разрабатываем многоагентную имитацию реактивного движения, которая похожа на написание автоматизированного планировщика маршрута транспортного средства, который запускается одновременно на тысячах агентов. Когда мы впервые создали прототип логики знака остановки, наш первый тест - подъехать к знаку остановки и остановиться перед ним - сработал хорошо. Затем мы создали сценарий, в котором пешеход пересек середину квартала перед машиной, примерно за 12 метров до знака «Стоп». Наш смоделированный автомобиль остановился красиво для пешехода, затем открыл дроссельную заслонку и проехал через знак остановки, как будто его даже не было. Самое замечательное в детерминированном автономном моделировании транспортного средства - это возможность запускать один и тот же сценарий снова и снова и получать тот же результат. Пройдя через наш код, мы обнаружили, что при остановке для пешехода автомобиль считал себя уже остановившимся перед знаком «Стоп». Мы переписали ошибочный код и добавили тест, чтобы убедиться, что ошибка никогда не останется не исправленной.

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

Несколько фактов о багах. Ошибки не всегда легко найти, особенно в системе, которая предназначена для работы в режиме реального времени. (Не смоделированный) мир не останавливается, когда вы попадаете в точку останова. Во-вторых, ошибки не обязательно являются экзотическими. Разработчики совершают множество ошибок снова и снова, что иногда приводит к безобидным, а иногда и к смертельным результатам. Единичные ошибки, перенос углов, преобразование единиц измерения, неправильное понимание библиотек и API - все это известные подводные камни, но профессионалы не всегда с ними справляются идеально. Наконец, ошибки в одном автономном стеке не обязательно должны совпадать с другим. Даже при использовании одних и тех же алгоритмов крайне маловероятно, что два стека будут иметь одинаковую реализацию.

Что же тогда такое «длинный хвост» автономного вождения? Неужели дети в костюмах на Хэллоуин? Кенгуру? Рекламы на бортах автобусов? Или, скорее, длинный хвост бросает вызов каждому программному проекту? Бесконечная очередь банальных, но сложных ошибок, которые нужно диагностировать, исправлять и не допускать повторения. Индустрия беспилотных автомобилей потерпела поражение. Это не был экзотический сценарий, но похоже, что что-то пошло не так.

Наконец, какое решение? Как нам устранить все ошибки, чтобы сосредоточиться на последних нескольких процентах надежности?

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

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

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