Ответ на пост «Теслам нельзя!!! Враг не пройдёт!!!»⁠⁠1

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

Вот берете вы конкурента, детально изучаете, как вы принимаете решение что должно быть на вашем продукте, а что нет?

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

Как испытания происходят: часть а/м же испытывается на треке?

До трека есть целая куча тестов. Начиная с уровня виртуального железа, где проверяется работа математической модели, до уровня конкретного модуля (например, блок контроля КПП, или блок контроля салона, и т.п.), где можно проверить работу разных частей программы. Также можно проверять работу этих модулей в так называемых HiL (Hardware-in-Loop), по сути большие компьютеры, симулирующие поведение машины, в которых проверяемое устройство ведёт себя точно так же, как в настоящей машине. Только в этом случае нет угрозы повреждения авто в случае неправильной работы модуля. Потом уже проверенные модули собирают в ранние прототипы авто. Интересно, что в случае с ранними прототипами авто, ещё не существует производственной линии и конвейера именно для этих прототипов, и они собираются полностью вручную.

Какие критерии того, что а/м может не доехать до конечного потребителя и отправится на производственную доработку?

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

О "зелёных квотах" если что то известно, расскажите.

Что это? Может быть мы это под другим именем знаем?