LINUX.ORG.RU

Linux в автомобиле

 


0

2

Обсуждаем интересные возможности применения Linux (именно с десктопным стеком технологий - т.е иксы/вялый, glibc и т.п.) в автомобилях.

Сейчас почему-то чаще всего попадается либо QNX, либо Android, ранее чаще всего был WinCE. Но может в каких-то автомобилях был Linux? Почему по вашему мнению не юзали пингвина в авто?

Хех, прикольный тред. Попробую ответить выборочно.

В ЭБУ ни какие финтифлюшки линукса нафих не нужны.

Смотря в каком ЭБУ. Если это ADAS например или powertrain, то нет, не нужны. Если infotainment, то нужны. Штука в том, что в современной машине сейчас электронные блоки управления фактически отдельные компьютеры, которые соединены в сеть Ethernet. Причём, на одной плате может стоять как микроконтроллер, на котором вращается RTOS (частенько поставка AUTOSAR от Vector или Elektrobit), так и микропроцессор на котором вращается ОС общего назначения. На той же плате вполне может стоять Ethernet коммутатор чтобы их соединять в сеть и несколько портов может смотреть во вне для подключения других ЭБУ.

advanced driver-assistance systems (ADAS). Это ЭБУ или нет?

ЭБУ. Пример: на одной плате стоит микроконтроллер с RTOS и отдельный SoC с полностью проприетарной прошивкой в виде блоба. К SoC’у подключена камера, которая смотрит по направлению движения автомобиля. Захват и обработка изображения происходят на SoC’е, который отдаёт микроконтроллеру метаинформацию по обнаруженным объектам, их координаты, etc. RTOS на микроконтроллере эту информацию принимает и отдаёт в Ethernet всем заинтересованным ЭБУ.

«мозги» машины - это исключительно система управления ДВС, а с помощью CAN-шины к ней подключены остальные модули.

Исторически это конечно верно, но в современной машине от крупных европейских и американских автопроизводителей powertrain это теперь лишь унаследованная часть целой сети. Назвать это «мозгами» теперь трудно.

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

У нас такое было из-за спец. требований, но у VW не взлетело.

или в багажнике лежит большая коробка с нейропроцами

Отдельный SoC на плате примерно 80x170 мм. «Места знать надо» :D

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

Тяжело представить. Современный автомобиль (особенно с ADAS, то есть уровень L2/L2+ автономности минимум), это 120-180 различных ЭБУ. Дело потихоньку движется в сторону уменьшения их числа за счёт более производительных SoC’ов, но никто в здравом уме не повесит эти функции на один MCU или SoC. Если только ооочень сильно экономить будут.

Прикинь, процессоры уже давно многоядерные! Не говоря уже о десятках процессоров в авто, связанных шиной CАN.

Тут такое дело… теперь не только процессоры, но и микроконтроллеры многоядерные которые умеют в Ethernet.

Во первых ситуация когда что-то «тормозит» ЭБУ в нормальных блоках невозможна - он хоть и подключен к CAN, но фактически все таски в нем строго ограничены по времени.

Возможна! Приоритеты задач планировщику люди задают руками в AUTOSAR (по крайней мере, в классическом, про адаптивный не знаю). Каждая задача выполняет набор заранее выданных ей функций и зачастую запускается периодически. Если какая-то из функций по той или иной причине выполняется «слишком долго» (то есть сопоставимо с периодом самой задачи), то нормальная периодичность выполнения задачи нарушается, а отсюда задержки, потерянные кадры, и т.п. Особенно вкусно, если так начинает тупить задача высокого приоритета, потому что тянет за собой нарушения периодичности более низкоприоритетных задач. Разгневанный OEM вываливает на тебя кучу логов и требует решения, а ты сидишь, чешешь репу, запускаешь симуляцию и трассировку :)

dsl
()