
Комментарии 12
добро пожаловать в Automotive
Еще поставили датчик на КПП

Я вам советую в плане схемотехнических решений немного прокачать стандарты типа AEQ и т.п., иначе рискуете попасть на непрерывные переделки во время эксплуатации.
Синхронный интерфейс SPI не предназначен для протяженных линий, не советую его использовать. Для быстрого восстановления I2C (который тоже не предназначен) можно попробовать использовать усилители шины и экранирование. Для прототипа должно сойти, в дальнейшем советую перейти на какую-нибудь суровую шину типа MIL-STD 1553.
Большое спасибо за развернутый и экспертный фидбек!
По стандартам абсолютно с вами согласен, вы, видимо, имели в виду AEC-Q (100/200). В макете собирали из того, что было под рукой "здесь и сейчас", но в ТЗ на предсерийную кастомную плату (ПАК СПД-1) закладываем именно Automotive Grade. Иначе при -30°C плата не выживет.
Про I2C/SPI на проводах - это были те самые грабли, на которые нам нужно было наступить самим, чтобы подтвердить теорию практикой. За идею с усилителем I2C и хорошим экраном отдельное спасибо!
MIL-STD 1553 - легенда, но мы делаем коммерческий продукт. Стоимость уже очень кусается. Клиенты нас не поймут)
Поэтомусмотрим в сторону классики: либо уход в аналоговый сигнал от точки съема (стандарт IEPE / токовая петля) с оцифровкой уже в защищенном основном блоке, либо вынос АЦП к датчику и передача "наверх" по изолированному RS-485 / CAN.
Как считаете, что из этого будет оптимальнее по соотношению цена/надежность?
Аналоговый сигнал - вряд ли получится избавиться от помех. Поэтому я бы даже не рассматривал. Даже если вам удастся сделать нормально на тестовом подключении, вы же хотите массовый продукт делать - значит надо рассчитывать на обычную квалификацию установщиков.
Вам нужна пропускная способность с каждого датчика 1Мб/с, насколько я понял. Скорее всего, с синхронизацией по времени. В условиях помех.
Как вариант: CAN FD.
На RS-485 придется навешивать протокол с контрольными суммами, подтверждением приема, повторами и т.п. Значит, придется метки времени ставить, это дополнительная нагрузка. Интерфейс точка-точка. Иначе накладные расходы на адресацию всю пропускную способность съедят. Значит, увеличение количества приемопередатчиков (и цены) в центральном модуле.
В принципе, данные можно сжимать на датчике. Думаю, раз в 10 получится уменьшить объем. Но увеличатся требования к процессорам.
Также советую стенд в лаборатории собрать - пропустить шины между десятком мощных реле, которые асинхронно коммутируют 12 В от автомобильного аккумулятора 10-100 Гц. Это позволит быстро оценивать варианты по BER.
Самый дешевый и надежный вариант - переход в частотную область. На датчиках поставить ГУН (можно цифровой), на центральном модуле ЧМ детектор. Будут проблемы с калибровкой и компенсацией по температуре, но их можно решить.
Огромное спасибо за глубокий комментарий!
Идея со стендом из коммутирующих реле для стресс-теста на BER — это просто золото. Обязательно заложим в наш R&D план.
По поводу аналогового сигнала - согласен на 100%. Кабель обязательно пережмут пластиковой стяжкой, экран лопнет, и тд. Оцифровывать нужно строго в точке съема.
А вот дальше начинается самая интересная развилка:
Путь А: Делаем MCU (с модулем FPU) на одной плате с МЭМС-датчиком. Сигнал никуда не бежит, сжимается локально (БПФ), и по длинному кабелю в кабину летит только короткий текстовый статус. И вот для него RS-485 хватает с запасом.
Главный минус: Физика и кондуктивный теплообмен. Чтобы поймать ВЧ-акустику (микротрещины), мы прикручиваем алюминиевый корпус стальным болтом к чугуну ДВС. Через этот тепловой мост плата мгновенно нагреется до температуры мотора, обдув воздухом не спасет. Ставить сложный MCU в классе AEC-Q100 Grade 1 или 0 - значит ударить себестоимости продукта.
Путь Б: Оставляем на горячем картере только МЭМС-датчик + АЦП + Трансивер (легко достать в исполнении до 125°C). А вычислительный MCU выносим на 1-2 метра на раму (в холодную зону АКБ), где можно ставить дешевые промышленные процессоры. И вот здесь ваша идея с CAN FD как нельзя кстати! Гнать 1 Мб/с сырого аудиопотока от горячей точки съема до холодных "мозгов" по RS-485 - боль, а CAN FD проглотит это спокойно.
Будем тестить тему с реле и связку "АЦП -> CAN FD -> Выносной MCU". Еще раз огромное спасибо за крутой консалтинг!
Все-таки, подумайте над переходом в частотную область. Если предполагается крупносерийный выпуск, это превзойдет по цене и надежности все остальные решения. Проблема только в хорошей аналоговой схемотехнике.
Если есть задача обеспечить работоспособность в широком диапазоне температур посмотрите в сторону взаимно-связанных генераторов. Это если первый раунд нормально закончите, конечно.
Спасибо за совет. Аналоговая фильтрация для снижения себестоимости в крупной серии - шаг логичный, держим его в уме на будущее.
Но сейчас мы осознанно остаемся в «цифре» из-за постоянно плавающих оборотов грузовика и переключений передач КПП. Нам критически важен Order Tracking. В цифре мы просто берем текущие RPM из CAN-шины и за миллисекунды программно сдвигаем окно поиска частоты вслед за изменением скорости. Делать узкополосный перестраиваемый аналоговый фильтр, который будет так же быстро и точно «бегать» по спектру за педалью газа (и не поплывет при 120°C) - это усложнение R&D для нашего этапа.
Вторая причина - гибкость продукта. Сегодня мы диагностируем КПП и ДВС, а завтра залили новые профили под другой редуктор с иными передаточными числами, вообще не перепаивая плату. Поэтому для MVP и первых серий мы выбираем микроконтроллеры.
Спасибо за ваши комментарии! Приятно общаться с профессионалом.
Спасибо за ваши комментарии! Приятно общаться с профессионалом.
Спасибо за вежливую форму "мы все поняли, спасибо, не мешай"
Для тех, кто будет читать. Не надо усложнять, зачем узкополосные перестраиваемые фильтры (если не считать таковым ЧМ-детектор)?
теплый аналоговый Путь С:
На двигателе ставите ЧМ-модулятор сигнала с датчика в область 100 кГц и выше. Например, ВСГ - схема простая, термостабильная и дешевая, но довольно сложная в расчетах. Так что, действительно, усложнение R&D имеет место быть.
Гнать по кабелю ВЧ ЧМ сигнал - помехи будут отсутствовать в принципе.
В устройстве сбора данных (в относительно холодном месте) ставите ЧМ-детекторы и АЦП. Обрабатывайте, как считаете нужным.
Если фура едет по глухой тайге без связи, и в этот момент ваш алгоритм на борту вычисляет, что коробка начала разваливаться. Отправить JSON в облако не выходит. Что происходит дальше? Уведомление просто теряется, или прибор как-то накапливает эти данные до появления связи?
Отличный вопрос. Ответ короткий: ни один байт не теряется, всё работает по принципу "черного ящика".
Так как математику процессор считает локально, на выходе получается не огромный аудиофайл, а крошечный текстовый лог на пару байт: дата, узел, процент износа. В зоне без связи этот лог пишется во внутреннюю память нашего блока и дублируется в штатный ГЛОНАСС-трекер тягача. Как только появляется нестабильный 2G - весь накопленный архив за секунду улетает на сервер диспетчера.
Ну и главное - физика износа металла. От появления первых микротрещин в шестерне до реального клина агрегата проходят недели. Поэтому, даже если прибор нашел дефект в глухом лесу, а завгар получил уведомление только через 3 дня - у автопарка всё равно останется фора в пару недель, чтобы спокойно купить запчасти к возвращению машины на базу.
Граничные вычисления в коммерческой логистике