Привет, Хабр! Мы — братья Лев и Марк Григорьевы. В рамках нашего R&D-проекта мы разрабатываем бортовую систему предиктивной диагностики для тяжелого коммерческого транспорта (тягачи, спецтехника).
Задачи в нашей небольшой команде разделены строго: Лев отвечает за аппаратную часть, схемотехнику и проект в целом, а Марк — за инженерию данных, разметку виброакустических датасетов и алгоритмы каскадной фильтрации.
В этой статье мы хотим поделиться набитыми шишками при проектировании прототипа: почему стримить аудио работающего двигателя фуры в облако — это экономическая утопия, как организовать непрерывный сбор данных без блокировки процессорного ядра и почему перенос цифровой обработки сигналов (DSP) на борт микроконтроллера стал для нас единственным выходом.
«Облачные» вычисления – это же хорошо?
Когда мы только приступили к проектированию, первой (и самой наивной) мыслью было создание классического IoT-сенсора. Концепция выглядела просто: берем качественный МЭМС-акселерометр, крепим на коробку передач, подключаем GSM-модем и непрерывно транслируем сырые данные на наш сервер. А уже там Python-скрипты строят спектрограммы и выявляют аномалии.
Но физика быстро скорректировала наши планы. Когда Марк сел просчитывать математику дата-трафика, цифры оказались безжалостными.
Для адекватного анализа высокочастотных гармоник (например, зарождающегося питтинга на зубьях шестерен) теорема Котельникова диктует нам частоту дискретизации 
, которая должна минимум вдвое превышать максимальную частоту исследуемого сигнала 
:
На практике нам нужна частота дискретизации порядка 10–20 кГц.
10 000 измерений в секунду × 3 оси (X, Y, Z) × 16 бит = ~60 КБ/сек.
За час непрерывной езды один тягач сгенерирует около 200 Мегабайт сырой вибрации.
Учитывая, что грузовики ходят по трассам Сибири и Урала, где покрытие сотовой сети крайне нестабильно, модем будет постоянно терять связь, а счета за M2M-трафик для парка из сотен машин сделают юнит-экономику проекта отрицательной.
Вывод напрашивался сам собой: сырые высокочастотные данные вообще не должны покидать борт автомобиля. Возникла необходимость в реализации граничных вычислений.
Как слушать и считать одновременно?
Вся математика должна выполняться локально на микроконтроллере (в нашем случае это ARM Cortex-M). Задача чипа — непрерывно собирать данные с датчика, применять оконные функции, выполнять Быстрое преобразование Фурье (БПФ) и лишь раз в сутки отправлять на сервер диспетчера JSON весом в несколько байт (с вердиктом об остаточном ресурсе агрегата).
Главная аппаратная проблема, с которой мы столкнулись: процессор не может одновременно опрашивать датчик по цифровой шине в цикле и считать «сложную» математику. Пока ядро занято расчетом Фурье, мы пропускаем критически важные такты вибрации. В результате на спектрограмме неизбежно возникают фантомные частоты , сводящие на нет всю диагностику.
Решение: Мы выстроили связку контроллера прямого доступа к памяти и двойного кольцевого буфера. Периферия аппаратно, без малейшего участия CPU, складывает новые сырые данные от датчика в первую половину буфера (Ping). Как только она заполняется, генерируется аппаратное прерывание. DMA автоматически переключается на запись во вторую половину (Pong), а ядро процессора в это время спокойно забирает данные из первой половины и запускает над ними вычисления (используя библиотеку CMSIS-DSP). Процесс идет непрерывно, без пропущенных тактов, а процессор выступает исключительно в роли математического сопроцессора.
Яма на дороге или износ КПП?
Пока писался код инициализации прерываний и буферов, Марк решал фундаментальную логическую задачу проекта: как научить алгоритм отличать удар колеса в колдобину от хруста шестерни внутри агрегата?
Удар в дорожную яму — это низкочастотное, высокоамплитудное апериодическое событие. Дефект подшипника — это высокочастотный, периодический звон, модулированный частотой вращения вала.
Разрешение спектра при цифровой обработке зависит от частоты дискретизации (
) и размера окна БПФ (N):
Чтобы алгоритмы работали корректно, Марку пришлось выстроить фильтрацию:
На первом этапе мы задействуем встроенные High-Pass фильтры (ФВЧ) самого МЭМС-датчика, аппаратно «срезая» всё, что находится ниже 50 Гц. Большая часть дорожного рельефа просто не доходит до процессора.
Микроконтроллер переводит сигнал в частотную область (FFT).
На этапе обучения моделей Марк агрегирует спектрограммы, отсматривает логи и вручную размечает аномалии, сопоставляя их с телеметрией классического G-сенсора. Если происходит мощный аномальный удар подвески (ускорение выходит за пределы нормы), алгоритм фиксирует пик перегрузки, но игнорирует этот этап при расчете износа шестерен. Датасет остается чистым.
Как мы уперлись в 5000 об/мин
А теперь о физике, с которой мы столкнулись на этапе стендовых испытаний прототипа. Чтобы отладить первичный сбор данных и дать Марку материал для работы с алгоритмами, мы тестировали макет на бензиновом ДВС малого объема.
На холостых и средних оборотах система работала как часы. Данные шли стабильно, графики спектрограмм четко отражали работу механизмов. Но как только мы раскрутили двигатель до 5000 об/мин, массивы с АЦП превратились в нечитаемую высокочастотную кашу.
Сначала мы искали ошибку в коде: винили программный алиасинг, переписывали настройки оверсэмплинга, пытались вычистить шум цифровыми фильтрами. Ничего не помогало.
Причина оказалась сугубо аппаратной — Электромагнитные помехи. Мощнейшие наводки от катушек системы зажигания на высоких оборотах били по неэкранированным дорожкам базовых протоколов (I2C) связи между датчиком и контроллером, искажая цифровой сигнал прямо в процессе передачи. Единицы превращались в нули на физическом уровне.
Работа над ошибками:
Сейчас мы находимся на стадии подготовки к тестам на дизельных тягачах, поэтому кардинально пересматриваем схемотехнику:
Отказываемся от I2C в пользу промышленных МЭМС-датчиков с изолированным интерфейсом SPI или дифференциальной передачей.
Интегрируем гальваническую развязку сигнальных линий.
Переходим на SLA-печать герметичных виброзащищенных корпусов (стандарт IP67), так как дорожные реагенты и перепады температур не оставляют шансов открытой электронике.
Заключение
Разработка hardware-продуктов в B2B — это постоянный поиск компромиссов, где математика регулярно разбивается о физику, а инженерам постоянно требуются чистые данные. Но когда аппарат в реальном времени вычленяет звуки износа из рева двигателя — это оправдывает все бессонные ночи.
Лев Григорьев (Руководитель проекта)
Марк Григорьев (дата-инженер, алгоритмы)
Разработчики ПАК СПД-1
