Салют, Хабр! 

Меня зовут Александр, я руковожу разработкой Фермы и Чембера в SberDevices. Про Ферму я уже рассказывал в прошлой статье. Сегодня, как и обещал (спустя полтора года, да) расскажу, что такое чембера. 

В целом чембер — от английского chamber, или камера. Так вышло, что изначально для тестирования умного устройства SberPortal были закуплены радио- и звуконепроницаемые камеры. Внутрь помещался наш объект контроля — DUT (device under test, «тестируемое устройство»). С тех пор закрепилось: всё, что делает чемберная команда, — это «чембер», даже если там нет камеры. Хотя корректнее говорить, что мы занимаемся разработкой тестовых станций. Занимательный факт: менеджеры произносят «чАмбер», а инженеры — «чЕмбер».

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

Зачем нужны тестовые станции

Контроль качества на фабрике — это не всегда про качество в нашем понимании. Методики тестирования в основном сводятся к проверке физических параметров и редко поднимаются до уровня софта. Для рядовых сотрудников главное — увидеть на экране заветный PASS, а не проверить реальное качество устройства.

В теории среди ошибок могут быть: неверные серийники, попытки отгрузить брак, дублирование MAC-адресов, забытая прошивка девайсов. Всё это можно попробовать отладить прямо на фабрике, но есть нюансы: во-первых, мы не хотим отдавать на сторону ключи и другие критичные для безопасности данные. Во-вторых, фабрики бывают разные, с разным уровнем дисциплины и производственной культуры.

Оговорюсь, что через чемберы проходят не все умные устройства Sber, хотя все проходят выходной контроль в формате QC (quality control) инспекции. Наша команда разрабатывала тестовые станции для всех аудиоустройств — из актуальных моделей это SberBoom, SberBoom Mini и SberBoom Mini 2, SberBoom Home, SberBoom Micro — а также для линейки электроустановочных изделий AtlasDesign Smart.

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

• прожечь в девайсе efuse, чтобы загрузчик пошёл по другой ветке своей логики и при старте закрыл все отладочные интерфейсы;

• сгенерировать и записать в память устройства ключи, чтобы оно могло обращаться к бэкенду и получать конфигурации или OTA-обновления;

• выполнить технологические операции — например, сохранить в память серийный номер. Он появляется только на фабрике, когда плата помещается в корпус.

Вторая задача — проверить железо. Убедиться, что все припаянные компоненты работают: динамик подключен, микрофон слышит, антенны не повреждены при сборке. Объём проверок зависит от продукта, его сложности и размера партии. Здесь всегда приходится искать баланс — время тестирования каждого устройства ограничено мощностью линии, а дорогая оснастка увеличивает себестоимость устройства.

Третья — проанализировать процесс производства и дать фабрике обратную связь. Например, мы видим рост ретестов: у устройств перестал открываться fastboot. Это может означать падение качества монтажа или износ оснастки — условно, пришло время заменить USB-кабели.

Четвёртая — проконтролировать устройства перед отгрузкой. Не на каждой фабрике есть MES-система, вдобавок такая, чья интеграция и особенности работы позволят отследить всё. В итоге фабрика может попытаться отгрузить девайсы, которые не прошли полный цикл тестирования. Так как наши тестовые станции стоят в самом конце производственного конвейера, мы разрешаем к отгрузке только те устройства, которые успешно прошли чембер.

Как появились чемберы

Разработку первой тестовой станции для проекта SberPortal мы начали ещё на этапе EVT (об этапах разработки тут). Первый прототип девайса выглядел так:

А первый прототип тестовой станции выглядел так:

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

Это та самая радио- и звуконепроницаемая камера, которая дала название нашей команде и всему, что мы делаем — чембер. Такие станции стоят на линии на фабриках, а станция в офисе нужна для разработки и отладки софта перед деплоем на фабрику. В целом, в этой камере нет ничего сложного — это просто набор периферии, подключаемой по USB к компьютеру.

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

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

Для SberBox Top впервые был создан настольный вариант  — chamber-pc, компьютер с подключённым сканером штрихкодов. Тестирование звука на этом продукте выполнялось упрощённо: динамик воспроизводил звук, а микрофон девайса его записывал.

Для продуктов SberBoom, а также SberBoom Mini и SberBoom Mini 2 мы смогли интегрировать собственные аудиотесты в еще и акустические чембера фабрики. В итоге на этих продуктах применялась гибридная схема тестирования: часть девайсов проходила проверку через chamber-pc, а другая часть — через полноценные акустические чембера, выполняя выборочный контроль.

Благодаря наличию chamber-pc станций нам удалось автоматизировать тестирование кнопок, закупив и установив пневматические кнопконажиматели, которыми управлял чембер.

На текущий момент используются разные тестовые станции. Зависит от продукта: где-то просто станции формата chamber-pc, где-то — станции с полноценным акустическим чембером. Концептуально они не отличаются от описанных выше.

Как тестируется звук в чемберах

Если для производства продукта используется акустический чембер, то основная задача этой камеры — проверить звук на устройстве. На каждом девайсе, который проходит через чембер, мы выполняем следующие тесты:

• измеряем АЧХ (FR, frequency response);

• замеряем КНИ (THD, Total Harmonic Distortion) в вариантах internal и external;

• проводим тест Rubb and Buzz;

• проверяем уровень микрофонов (RMS тест);

• тестируем эффективность работы алгоритма AEC (NMSE тест).

Тест эффективности работы AEC (NMSE тест)

Он оценивает, как на девайсе работает AEC — алгоритм, вырезающий из микрофонных записей звук, воспроизводимый самим устройством. Это один из важнейших алгоритмов для работы споттерного слова, который запускает ассистента. Это кумулятивный тест, так как оценивает работу всех комплектующих устройства в совокупности.

В ходе устройство на максимальной громкости воспроизводит белый шум, одновременно записывая звук своими микрофонами и микрофоном референса. По полученной записи рассчитывается NMSE (Normalized Mean Square Error, нормализованная среднеквадратическая ошибка) между мощностью записанного шума и мощностью сигнала после работы AEC. Значение NMSE около 0 означает, что алгоритм не сработал (например, динамик или микрофон не работают, или есть искажения в микрофонной записи).

Тесты динамика

• THD internal / THD external — тест нелинейных искажений;

• Rub and Buzz — тест нелинейных искажений высокого порядка;

• FR (frequency response, АЧХ) — тест частотной характеристики.

Цель этих тестов — оценить степень искажённости записей:

• THD internal измеряет искажения на микрофонах девайса;

• THD external и Rub and Buzz — на микрофоне чембера во время воспроизведения музыки устройством.

Результаты этих тестов используются сразу для построения нескольких характеристик: THD internal, THD external, RNB и FR. THD internal и THD external оценивают суммарный коэффициент нелинейных искажений по уровню второй и третьей гармоник (согласно ГОСТ 23262-88). Rub and Buzz — суммарный коэффициент искажений для гармоник четвёртого порядка и выше. FR (АЧХ) оценивает неравномерность частотной характеристики устройства при воспроизведении музыки.

Для этих тестов применяется свиптон (sweeptone) — синусоидальный сигнал с плавным изменением частоты.

• Спектрограмма сигнала показывает наличие всех частотных компонентов диапазона от 0 до 20 кГц.

• Сигнал хорош тем, что в каждый момент времени содержит только одну частоту. Если разбить сигнал на маленькие последовательные фрагменты, можно считать, что в каждом присутствует только одна частота.

Так выглядит сигнал после воспроизведения на устройстве. Оба THD теста измеряют вторую и третью гармоники микрофонных записей.

Тест уровня микрофонов (RMS тест)

RMS тест оценивает уровень сигнала на микрофонах. Если микрофоны слишком чувствительные, сигнал может клиппироваться; при недостаточной чувствительности он зашумлён, а уровни между микрофонами разные. Это приводит к некорректной работе алгоритмов измерения громкости окружающего звука.

В ходе теста устройство в чембере записывает белый шум, воспроизводимый динамиком чембера. Динамик должен воспроизводить шум без искажений, на постоянной громкости, соответствующей самым громким бытовым шумам. В то же время микрофон чембера записывает этот шум для контроля стабильности громкости динамика со временем.

Чемберный софт подсчитывает два значения:

• RMS Total — среднеквадратическое значение белого шума в полосе 0–8000 Гц;

• RMS 3000 — среднеквадратическое значение в полосе 0–3000 Гц.

Калибровка

Тут возникает вопрос: как определить, проходит ли девайс в допустимые значения (например, по THD), если каждый чембер уникален? У каждого микрофона чембера своя чувствительность, у каждого динамика чембера — своя АЧХ. И это отдельная инженерная задача.

Решить её можно двумя путями. Первый — сделать все чемберы максимально одинаковыми, сведя разброс звуковых характеристик к минимуму… но это будет очень дорого стоить. Второй — признать, что чемберы разные, и для каждой тестовой станции вырабатывать собственные пороги для тестов. Этот процесс и называется калибровкой.

На этапе PVT, когда у девайса уже финальный звук и конструктив, мы прогоняем через каждый чембер несколько сотен устройств и проводим на них акустические тесты, описанные выше, но без вердикта «норма» или «брак» — просто получаем большую выборку результатов. Далее находим усреднённое «идеальное» поведение устройства и уже от него вычисляем допустимые отклонения.

Как тестировать акустику в заводских условиях без экранирования, или Self Sound Check

Для проверки качества звука в открытых заводских помещениях, где невозможно использовать звукоизолированные камеры, наша команда разработала метод Self Sound Check.

Это самотестирование, при котором проверка проводится с использованием только акустической системы самого устройства. Алгоритм построен на принципе замкнутого контура: устройство проигрывает эталонный (референсный) звуковой сигнал своими динамиками и одновременно записывает его собственными микрофонами, анализируя качество воспроизведения и записи.

Для теста используется специально сгенерированный сигнал с уникальной модуляцией, устойчивый к реверберации. В фабричных цехах множество металлических и бетонных поверхностей, создающих эхо. Наш сигнал обладает свойствами, которые позволяют алгоритму выделять его на фоне таких помех. Его резкий и нестандартный характер позволяет точно определить начало и конец каждого бита закодированной информации, минимизируя ошибки демодуляции.

Специальная утилита, разработанная нашими инженерами по обработке голоса и аудио (VQE), генерирует случайное цифровое сообщение и преобразует его в уникальный звуковой сигнал. Устройство проигрывает сигнал через динамик и одновременно записывает его микрофонами. Записанный сигнал демодулируется обратно в цифровую форму, и система сравнивает исходное сообщение с полученным. Результатом может быть:

• True — сигнал успешно обнаружен и декодирован без ошибок;

• Exception — произошла ошибка декодирования.

Чтобы одновременно тестировать на линии несколько устройств, каждое из них получает уникальный идентификатор (ID), основанный на номере посадочного места. Символы для модуляции берутся из ортогонального набора. Это позволяет устройствам воспроизводить уникальные сигналы без взаимного влияния и акустических помех.

В ходе теста ПО сохраняет два файла — исходный референсный сигнал и сигнал, записанный устройством. Далее в демодуляторе ищется уникальный сигнал префикса, демодулируется полезная нагрузка, символы проходят через блок исправления ошибок. Затем принимается решение о валидности сообщения. Если устройство правильно воспроизвело и записало сигнал, акустическая система исправна.

Даже если записанный сигнал искажён внешней средой, внутри алгоритма утилиты применяется блочный исправляющий код (Reed-Solomon), который фильтрует временные помехи — стук, кашель человека, гул и т.п. — и выделяет полезный сигнал.

«Вы нас блочите!», или как тестируют электроустановочные изделия

При тестировании колонок мы в среднем тратим на девайс от 3 до 5 минут — зависит от типа тестовой станции (chamber-pc или большой чембер) и продукта. Но когда мы начали производить электроустановочные изделия для умного дома AtlasDesign Smart, например, умную розетку или умный выключатель, правила изменились. Для нас было установлено жёсткое ограничение: 40 секунд на девайс. Это не просто пожелание, а лимит, который задаёт ритм всего производственного процесса. Дело в том, что на этой фабрике наша тестовая станция (chamber-pc) из-за плотности расписания подключается к конвейеру всего на несколько дней для проверки конкретной партии. Это требует совершенно другого подхода к автоматизации и стабильности тестового ПО.

На старте мы столкнулись с тремя особенностями тестирования электроустановочных изделий (ЭУИ)

1. Тестирование «по воздуху»
   Вместо проводного соединения, как в колонках, умные ЭУИ тестируются через протокол Zigbee, используя Zigbee Tunnel для взаимодействия chamber-pc с DUT, который представляет из себя а-ля UART over Zigbee. В условиях шумного радиоэфира на заводе, где одновременно тестируются другие Zigbee-устройства, пейринг DUT с тестовой станцией может занимать от 2 до 20 секунд. Но весь тест должен укладываться в 40 секунд, включая сам функциональный прогон.

2. Перезапуск внешних сервисов
   Проблема — особенности интеграции с Mosquitto (MQTT-брокер) и zigbee2mqtt. Из-за архитектурных ограничений и необходимости освобождать ресурсы между устройствами приходится полностью останавливать и перезапускать эти процессы после каждого DUT. На старте всё это реализовывалось внутри нашего софта. Это добавляло ещё 5–10 секунд на каждый цикл — нужно было убедиться в полной остановке сервисов, корректно инициировать повторный запуск и проверить доступность интерфейсов.

3. Асинхронность запуска
   Zigbee2mqtt не может начать работу без доступного брокера Mosquitto. После запуска оба сервиса ещё несколько секунд находятся в переходном состоянии, пока z2m не войдёт в режим поиска устройств и не начнёт пейринг.

Учитывая всё это, на первых этапах мы не укладывались в норматив по времени. Поэтому заказчик заявил: «Вы нас блочите!».

Чтобы уложиться в лимит по времени и стабилизировать тестирование ЭУИ, мы сделали несколько ключевых изменений:

1. Сервис zigbee2mqtt теперь сразу запускается в режиме подключения новых устройств (permit_join). Это позволило существенно сократить время пейринга каждого DUT.

2. Работу с внешними сервисами вынесли в отдельные скрипты, чтобы перезапуск Mosquitto и z2m больше не тормозил основной цикл тестирования.

После пары бессонных ночей с тестированием, переписыванием и доводкой софта до стабильного состояния всё получилось: массовое производство запущено точно и в срок.

Как поладить с MES-системой заказчика и обеспечить фабрике автономность

Чтобы лучше контролировать процессы на фабриках (или чтобы фабрика могла контролировать нас?), нужно интегрировать наш софт с их MES-системой. На разных производствах она называется по-разному — SFC, SFIS или ещё как-то, но суть одна.

Интеграция нужна, чтобы чемберы отправляли результаты своей работы на фабрику, и та понимала, какие устройства можно отгружать. Кроме того, MES-система может запретить тестирование девайса — например, если из-за ошибки оператора устройство пропустило предыдущую станцию или несколько раз провалило тесты. В этом случае тестовая станция покажет оператору окно с инструкциями или уведомит, что в MES системе возникла ошибка.

На практике самая сложная часть — найти человека, который сможет предоставить хотя бы какое-то описание API. В идеале в Word, но иногда это просто сообщение в мессенджере.

Как это может выглядеть

Дальше начинается процесс разработки клиента с нашей стороны и отладка интеграции. Без сюрпризов — MES-система редко работает так, как описано в документации, поэтому мы не удивляемся.

Ещё одна важная задача — независимость производства от связи с офисом. При проектировании тестовых станций мы выработали главное правило: фабрика должна быть автономна. Производства находятся далеко, и, независимо от тарифов провайдера и результатов speedtest, связь бывает медленной. Или отсутствует вовсе.

Иногда — например, на ранних этапах для бета-тестеров —  мы «релизим» устройства прямо в офисе. В результате появилась (не сразу) вот такая архитектура работы тестовых станций:

StarChamber

Это наш софт, который управляет процессом тестирования на станциях. В ходе теста каждого девайса StarChamber общается с MES-системой фабрики, сообщает о результатах тестов или блокирует устройство по требованию MES.

Результатом тестирования каждого девайса является «чемберный отчёт» — по сути папка с аудиофайлами, изображениями с камеры, результатами тестов в JSON и другими артефактами. Все отчёты мы храним в S3, но так как связь с интернетом бывает нестабильной, они сначала попадают на центральный сервер фабрики в сервис «upload to S3», который аккумулирует данные со всех тестовых станций и при наличии сетевого доступа загружает их в S3.

Serial Checker

Ещё один важный сервис, который работает и на фабрике, и в офисе. Он следит за уникальностью девайсов: серийных номеров, device ID и MAC-адресов.  

Сервис гарантирует, что фабрика использует только MAC-адреса из предоставленного пула, и что они уникальны. Инстанс serial checker в Москве следит за уникальностью «зарелиженных» девайсов в офисе. Под капотом сервис реализует master-master репликацию БД.

Работа с отчётами по тестированию

Когда отчёты попали в S3, сервис «report analyzer» разбирает их и заносит важные данные в БД. По этой БД строятся дашборды в Grafana с аналитикой по производству. И она же используется другими сервисами:

• Quality Control проверяет очередную партию девайсов перед отгрузкой и разрешает выпуск, если всё прошло штатно;

• Device Uploader передаёт информацию о девайсах в другие сервисы компании.

На схеме показаны не все сервисы: например, есть мониторинг с алертами в Mattermost. Есть реализованный в VictoriaMetrics механизм докачивания метрик с vmagent на фабриках, когда связь восстанавливается. (О переходе с Prometheus на VictoriaMetrics как-нибудь расскажу в отдельной статье).

Зачем ещё нужны чембера

Наши два чембера в московском офисе используются не только для отладки софта, иначе бы они часто простаивали. Мы их применяем на этапе разработки девайса — проводим звуковые тесты и предоставляем обратную связь разработчикам. А на ранних этапах разработки, например, DVT, когда линия на фабрике ещё не готова, привозим в офис ранние образцы девайсов и через чембера проводим полноценный релизный процесс. Эти устройства потом пойдут в бета-тест.

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

Когда девайс уже запущен в MP, чембера в офисе помогают:

• воспроизводить проблемы, которые возникают у фабрики при производстве;

• выпускать новые OTA-прошивки, прослушивая один и тот же эталонный образец на разных версиях прошивки (не забывая предварительно «прогревать» устройство, а как же иначе ^_^).

Таким образом, офисные чембера работают как своего рода «лаборатория», позволяющая ускорять разработку и поддерживать контроль качества до и после запуска девайса.

Заключение

Собственные тестовые станции — это дорого и сложно. Интеграция с фабрикой всегда непроста, а дополнительные расходы на место на фабрике и операторов бьют по экономике. Но по нашему опыту производства мы знаем, что всё не зря. Благодаря им мы выявляем проблемные девайсы ещё на фабрике и отгружаем пользователям устройства, в качестве которых уверены. 

Чембер, как и производство в целом — это огромное поле для улучшений: как разрабатывать быстрее и качественнее? Как бороться с человеческим фактором? Прошлые запуски устройств: что мы сделали на «отлично» и что не дотянули? Так что впереди ещё много новых историй (и грабель).  

***

В подготовке статьи участвовали: Дмитрий Рожков @DARozhkov Алексей Новиков @Gman11 Сергей Мироненко @yield_me