Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Железо и гаджеты доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 8
добро пожаловать в 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". Еще раз огромное спасибо за крутой консалтинг!
Если фура едет по глухой тайге без связи, и в этот момент ваш алгоритм на борту вычисляет, что коробка начала разваливаться. Отправить JSON в облако не выходит. Что происходит дальше? Уведомление просто теряется, или прибор как-то накапливает эти данные до появления связи?
Отличный вопрос. Ответ короткий: ни один байт не теряется, всё работает по принципу "черного ящика".
Так как математику процессор считает локально, на выходе получается не огромный аудиофайл, а крошечный текстовый лог на пару байт: дата, узел, процент износа. В зоне без связи этот лог пишется во внутреннюю память нашего блока и дублируется в штатный ГЛОНАСС-трекер тягача. Как только появляется нестабильный 2G - весь накопленный архив за секунду улетает на сервер диспетчера.
Ну и главное - физика износа металла. От появления первых микротрещин в шестерне до реального клина агрегата проходят недели. Поэтому, даже если прибор нашел дефект в глухом лесу, а завгар получил уведомление только через 3 дня - у автопарка всё равно останется фора в пару недель, чтобы спокойно купить запчасти к возвращению машины на базу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Граничные вычисления в коммерческой логистике