Конечно такого примера я не приведу, я не настолько специалист ни в Functional Safety ни в общей архитектуре разных OEM.
Более того, я не пытаюсь утверждать что такое решение возникло именно в результате соображений безопасности, я всего лишь сделал предположение о возможной причине. Предположение я основывал на своем опыте разработки ADAS систем, где парадигма «если что непонятное — гаси систему, отправляй юзера в сервис» применяется практически повсеместно.
Я не делал данный уровень системы и не делал проектов непосредственно для VAG, сужу по рассказам коллег писавших диагностику для VAGа.
Мне было обьяснено что если в машину изначально не укомплектованную, скажем, кондиционером или подогревом сидений попытаться их добавить системв при старте определит «неучтенные» сообщения на шине и откажется подниматься. Придеться перешивать/конфигурировать все ECU на данной ветке шины. Пока у вас есть слитые из официального сервиса софт и прошивки — это делается.
Не уверен как у VAG, но цифровые подписи прошивок уже вполне идут в массы для других OEM, так что сделать свой вариант прошивки действительно сложно.
С точки зрения пользователя — вы правы.
С точки зрения OEM, который из-за цепной аварии причиненной сгоревшими лампочками может нарваться на иск в десятки и сотни миллионов евро — легкое неудобство пользователя может оказаться сильно дешевле.
Это может быть сознательный дизайн, вполне в духе ISO26262. Система критична для поддержания безопасности, degraded mode невозможен — выключаем все от греха…
Главное чтоб лампочка на приборке светилась и запись в диагностике была.
Я (видимо неудачно) пытался сказать что система контроля и предотвращений неофициальных изменений там уже есть. Просто на данном этапе она сравнительно легко обходится, в том числе из-за доступности слитого внутреннего софта и прошивок.
Думаю ковровая имплементация over-the-air апдейтов поменяет ситуацию.
Для остальных производителей ситуация аналогична, просто из-за меньшей распространенности нужный софт/прошивки получить сложнее.
Для этого не только не надо ждать будущего, но и Теслу тоже ждать не нужно. Попробуйте в банальный Гольф воткнуть железку, которой не было в изначальном комплекте.
Пока автопроизводителю будут выгодны данные функции — они в машинах будут. ОТА выгодна самим ОЕМ, насколько я вижу в ближайшие 5 лет такое будет у всех не low-cost. Автопарковка с помощью телефона или нахождение машины, опять же насколько вижу я, тоже весьма популярны. V2X это вообще практически необходимая основа для высших уровней автоматизации вождения. Телеметрия опять же выгодня ОЕМ. Я плохо себе представляю сколько происшествий должно произойти и какая волна «хайпа» должна подняться чтоб хотя б одна из этих функций не стала массовой в ближайшие 10 лет.
Платформа разрабатывается далеко не ради одной модели и обновляется далеко не каджый год. Для примера посмотрите сколько всего построено на VW MQB платформе. Для существующих/выходящих в ближайшие пару лет моделей уже никто ничего переделывать не будет. Для перспективных же платформ вопросы безопасности уже вполне решаются. Требования на файрвол, фильтрацию и шифрование я видел в ТЗ как минимум 3 разных ОЕМ, только вот на рынок эти модели выйдут после 2020.
Извините, но речь не идет только о комбинации мультимедиа + Интернет.
Во-первых на Интернет завязывается все больше систем лезущих глубоко внутрь, например: OTA, парковка по мобильнику, V2x, дорожная информация, телеметрия… Всем этим системам нужен доступ «внутрь», на CAN и не только, потому некий гейтвей будет в любом случае, неважно если самостоятельным устройством или в рамках инфотеймента.
Во-вторых, как уже говорилось выше, текущий инфотеймент это очень многофункциональный комбайн, в которам далеко не только плеер. Выдрать в самостоятельные блоки навигацию, body controller, многофункциональный дисплей с настройками всего и вся и легкой диагностической иформацией и, собственно, плеер будет недешево, очень. Не сколько в производстве, но в разработке и валидации.
Вы не поверите, но требования к экспериментальным автомобилям тоже давно известны и устаканились. В некоторых странах даже специальные номера под это дело есть.
Из собственного опыта: сложность «сертификации» конечно зависит от обьема изменений, но для случая «добавить пару камер, лидар и радар и интерфейс для управления тормозом/газом» подготовка документов, при наличии опыта, занимает 5-6 человекомесяцев.
Я понимаю что опыт есть, раз вообще такую возможность рассматриваете. Я скорее о том, что не вижу смысла тратить столько времени на ковыряние в достаточно старом и уже отжившем свое продукте.
Если протокол подробно описан — может быть реализована/описана и конфигурация сенсора по CANб тогда можно попробовать включить.
Искать значения в EEPROM как-то совсем уж реверс-инжиниринг, оно того стоит?
Два канала CAN это слишком большая роскошь, мало кто из OEM с таким хочет связываться.
Обычно сигнал от AEB ходит постоянно, просто основную часть времени он командует idle, ничего не делаем. Чтоб торможение началось должна пройти цепочка изменения состояний, что-то типа idle->prefill->brake.
К вящей безопасности можно сделать запрос степени торможения отдельным сигналом, но это увеличит латентность системы и усложнит интеграцию, потому такое решение не однозначно лучше.
Торможение скорее всего инициируется посылкой обычного пакета, просто на другом конце провода должен соответствующий модуль сидеть, со своей логикой и механизмами проверки, что-то типа: лидар -> AEB -> интерфейс тормозов. Могут быть как 3 независимых модуля так и блокировка 2в1, но в любом случае все 3 должны быть увязаны.
Таки совершенно не обязательно прозрачные. У многих «бюджетных» автопроизводителей лобовые стекла, для уменьшения нагрева салона, данный диапазон не пропускают. Приходится или просить автопроизводителя делать «окошко» под лидар или ставить его снаружи.
В серии, насколько я знаю, пока не работает, только прототипы. Для хорошей работы SLAM нужны точные измерения по достаточно широкому FOV, это пока дорого.
SLAM используются и чтоб уточнить/подтвердить свое месторасположение относительно статических обьектов. Так позицию «по навигации» до суб-сантиметровой точности можно уточнить.
Не надо ванговать, они уже почти есть, просто вбейте в поисковик ISO 26262 и Automotive Spice. К этому добавятся только де юре нормы на минимальную «производительность» автоматических/автономных систем.
Более того, я не пытаюсь утверждать что такое решение возникло именно в результате соображений безопасности, я всего лишь сделал предположение о возможной причине. Предположение я основывал на своем опыте разработки ADAS систем, где парадигма «если что непонятное — гаси систему, отправляй юзера в сервис» применяется практически повсеместно.
Мне было обьяснено что если в машину изначально не укомплектованную, скажем, кондиционером или подогревом сидений попытаться их добавить системв при старте определит «неучтенные» сообщения на шине и откажется подниматься. Придеться перешивать/конфигурировать все ECU на данной ветке шины. Пока у вас есть слитые из официального сервиса софт и прошивки — это делается.
Не уверен как у VAG, но цифровые подписи прошивок уже вполне идут в массы для других OEM, так что сделать свой вариант прошивки действительно сложно.
С точки зрения OEM, который из-за цепной аварии причиненной сгоревшими лампочками может нарваться на иск в десятки и сотни миллионов евро — легкое неудобство пользователя может оказаться сильно дешевле.
Главное чтоб лампочка на приборке светилась и запись в диагностике была.
Думаю ковровая имплементация over-the-air апдейтов поменяет ситуацию.
Для остальных производителей ситуация аналогична, просто из-за меньшей распространенности нужный софт/прошивки получить сложнее.
Платформа разрабатывается далеко не ради одной модели и обновляется далеко не каджый год. Для примера посмотрите сколько всего построено на VW MQB платформе. Для существующих/выходящих в ближайшие пару лет моделей уже никто ничего переделывать не будет. Для перспективных же платформ вопросы безопасности уже вполне решаются. Требования на файрвол, фильтрацию и шифрование я видел в ТЗ как минимум 3 разных ОЕМ, только вот на рынок эти модели выйдут после 2020.
Во-первых на Интернет завязывается все больше систем лезущих глубоко внутрь, например: OTA, парковка по мобильнику, V2x, дорожная информация, телеметрия… Всем этим системам нужен доступ «внутрь», на CAN и не только, потому некий гейтвей будет в любом случае, неважно если самостоятельным устройством или в рамках инфотеймента.
Во-вторых, как уже говорилось выше, текущий инфотеймент это очень многофункциональный комбайн, в которам далеко не только плеер. Выдрать в самостоятельные блоки навигацию, body controller, многофункциональный дисплей с настройками всего и вся и легкой диагностической иформацией и, собственно, плеер будет недешево, очень. Не сколько в производстве, но в разработке и валидации.
Из собственного опыта: сложность «сертификации» конечно зависит от обьема изменений, но для случая «добавить пару камер, лидар и радар и интерфейс для управления тормозом/газом» подготовка документов, при наличии опыта, занимает 5-6 человекомесяцев.
Искать значения в EEPROM как-то совсем уж реверс-инжиниринг, оно того стоит?
Обычно сигнал от AEB ходит постоянно, просто основную часть времени он командует idle, ничего не делаем. Чтоб торможение началось должна пройти цепочка изменения состояний, что-то типа idle->prefill->brake.
К вящей безопасности можно сделать запрос степени торможения отдельным сигналом, но это увеличит латентность системы и усложнит интеграцию, потому такое решение не однозначно лучше.