Задачи в нашей небольшой команде разделены строго: Лев отвечает за аппаратную часть, схемотехнику и проект в целом, а Марк — за инженерию данных, разметку виброакустических датасетов и алгоритмы каскадной фильтрации.

В этой статье мы хотим поделиться набитыми шишками при проектировании прототипа: почему стримить аудио работающего двигателя фуры в облако — это экономическая утопия, как организовать непрерывный сбор данных без блокировки процессорного ядра и почему перенос цифровой обработки сигналов (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):

Чтобы алгоритмы работали корректно, Марку пришлось выстроить фильтрацию:

1. На первом этапе мы задействуем встроенные High-Pass фильтры (ФВЧ) самого МЭМС-датчика, аппаратно «срезая» всё, что находится ниже 50 Гц. Большая часть дорожного рельефа просто не доходит до процессора.

2. Микроконтроллер переводит сигнал в частотную область (FFT).

3. На этапе обучения моделей Марк агрегирует спектрограммы, отсматривает логи и вручную размечает аномалии, сопоставляя их с телеметрией классического G-сенсора. Если происходит мощный аномальный удар подвески (ускорение выходит за пределы нормы), алгоритм фиксирует пик перегрузки, но игнорирует этот этап при расчете износа шестерен. Датасет остается чистым.

Как мы уперлись в 5000 об/мин

А теперь о физике, с которой мы столкнулись на этапе стендовых испытаний прототипа. Чтобы отладить первичный сбор данных и дать Марку материал для работы с алгоритмами, мы тестировали макет на бензиновом ДВС малого объема.

На холостых и средних оборотах система работала как часы. Данные шли стабильно, графики спектрограмм четко отражали работу механизмов. Но как только мы раскрутили двигатель до 5000 об/мин, массивы с АЦП превратились в нечитаемую высокочастотную кашу.

Сначала мы искали ошибку в коде: винили программный алиасинг, переписывали настройки оверсэмплинга, пытались вычистить шум цифровыми фильтрами. Ничего не помогало.

Причина оказалась сугубо аппаратной — Электромагнитные помехи. Мощнейшие наводки от катушек системы зажигания на высоких оборотах били по неэкранированным дорожкам базовых протоколов (I2C) связи между датчиком и контроллером, искажая цифровой сигнал прямо в процессе передачи. Единицы превращались в нули на физическом уровне.

Работа над ошибками:

Сейчас мы находимся на стадии подготовки к тестам на дизельных тягачах, поэтому кардинально пересматриваем схемотехнику:

1. Отказываемся от I2C в пользу промышленных МЭМС-датчиков с изолированным интерфейсом SPI или дифференциальной передачей.

2. Интегрируем гальваническую развязку сигнальных линий.

3. Переходим на SLA-печать герметичных виброзащищенных корпусов (стандарт IP67), так как дорожные реагенты и перепады температур не оставляют шансов открытой электронике.

Заключение

Разработка hardware-продуктов в B2B — это постоянный поиск компромиссов, где математика регулярно разбивается о физику, а инженерам постоянно требуются чистые данные. Но когда аппарат в реальном времени вычленяет звуки износа из рева двигателя — это оправдывает все бессонные ночи.

Лев Григорьев (Руководитель проекта)

Марк Григорьев (дата-инженер, алгоритмы)

Разработчики ПАК СПД-1