Продолжаю рассказывать про наш опыт организации серийного производства коммерческой электроники.
Прошлая статья была про историю производства изделия. Там много статистики, полученной в результате использования тестовых станций. Но мало про то, что собой представляют сами станции. Сегодня — подробнее о том, как мы автоматизировали функциональное тестирование печатных плат на производстве и как устроена тестовая станция, которая нам в этом помогает.
Чего мы хотели добиться:
- Тотального контроля. Проверять каждую плату, а не выборочно.
- Снизить влияние человеческого фактора. Эффективность тестирования не должна зависеть от квалификации и личных качеств исполнителя.
- Интеграция с производством. Тестирование должно быть частью общего процесса производства.
- Прошивка. Устройство должно выходить готовым к дальнейшей сборке в корпус.
- Учет и маркировка выпущенных устройств. Сквозное присвоение серийных номеров. Распечатка стикеров для дальнейшей идентификации.
- Всё это должно работать быстро.
Для этого мы решили расширить возможности тестера, о котором мы писали тут, и разработали систему тестирования.
Система обеспечивает взаимодействие тестовых станций, производственной инфраструктуры, серверной платформы и пользователей. Позволяет хранить, обрабатывать и обеспечивать доступ к информации для оператора тестирования, менеджера производства, оператора системы, других пользователей.
В будущем мы планируем добавить возможность удаленного управления тестовыми станциями (изменять тестовый план, версию прошивки и т.д.).
DUT (device under test)
Немного про устройство, которое мы тестируем. Упрощенная структурная схема:
Это модуль телеметрии, который работает под управлением микроконтроллера. Он имеет несколько интерфейсов к объекту управления, связь с сервером, индикацию и элементы управления. Модуль работает как от внешнего питания, так и автономно от батареи. В ТЗ на тестовую станцию мы расписали подробный тестовый план, здесь я кратко приведу функции и способы тестирования:
Блок | Как проверяем |
---|---|
MCU | Заливается тестовая прошивка, которая выполняет команды тестовой станции. |
SD card | Запись, чтение данных. |
LEDs | Измерение напряжения на включенном светодиоде, позволяет проверить как работу, так и цвет |
Buttons | Не тестируем, усложняет механику, снижает скорость тестирования. |
USB | Используется как канал связи между MCU и ноутбуком во время тестирования. |
Power | Измерение напряжений на всех стадиях преобразования, контроль входного тока. |
Battery | Контроль сигналов состояний заряда микросхемы на плате. |
GSM, Bluetooth | Соединение, передача данных на сервер/плату тестовой станции. |
RS-232, UART* | Передача тестовых посылок на плату тестовой станции. |
Buzzer | Микрофон, детектирование количества звуков. |
IO | Изменение состояний, контроль на стороне платы тестовой станции. |
Тестовая станция
Тестовая станция состоит из оснастки, стандартных приборов и ноутбука, который всем этим управляет. Почти все устройства связаны с ноутбуком по USB.
Название | Название прибора |
---|---|
DUT | Тестируемое устройство, Device under test |
Тестовая оснастка |
Ingun MA260 |
QR сканер |
GD4400 |
Принтер этикеток |
GODEX RT200 |
Вольтметр |
АКИП В7-78/1 |
Источник питания | АКИП-1105 |
USB hub |
D-LINK |
Ноутбук |
Lenovo Ideapad 320 |
Ноутбук
Когда мы выбирали модель ноутбука, мы думали, что просто развернем на них предварительно отлаженное ПО. Поэтому особая производительность ноутбуку не нужна. Так мы закупили дешёвые ноутбуки с WIN10. Не делайте так. Отладка на целевом железе — неминуема. Гораздо удобнее работать с нормальным железом, тем более что стоимость ноутбука в масштабах проекта не так принципиальна.
Windows оказалась не лучшей ОС для наших нужд. С ней сложно добиться идентичности нескольких станций, сложно до конца и навсегда прекратить обновления. Вот мы приехали на производство разворачивать станцию тестирования:
Ещё Windows подкинула одну задачу по Bluetooth. При попытке подключения нового устройства к Bluetooth ноутбука Windows каждый раз просит у пользователя разрешения. Мы не смогли обойти софтово эту просьбу и сделали Bluetooth внутри стенда.
На ноутбуке работает вот такая панель оператора:
Начинается тестирование сканированием штрих-кода на плате. Процесс тестирования представляет собой последовательное выполнение шагов в тестовой программе, каждый из которых имеет номер, название и статус выполнения. (левая часть интерфейса) Если необходимо, на отдельных шагах можно снять галочку выполнения, и они будут пропущены. По мере выполнения, тестирующая программа выводит дополнительную информацию в окне «Лог выполнения тестирования» (справа) о статусе выполнения текущего шага. Заканчивается тестирование распечаткой этикеток.
Плата тестовой станции и DUT подключены к ноутбуку через USB и обмениваются по протоколу modbus.
Нагрузочное тестирование
Одно из основных требований к работе тестовой станции на производстве — надежность. Она должна не пропускать брак и не браковать годные изделия. Для выявления редких отказов надо много раз запустить тестирование. Поэтому мы стали делать нагрузочное тестирование. Автокликер запускает GUI и имитирует работу оператора стенда. Суммарное количество нагрузочных тестов — более 20 тысяч.
USB hub
Оказывается, в автоматизации нет мелочей. Все наши приборы соединены с ноутбуком по USB. Иногда они “отваливаются”. Чаще всего зависает плата тестовой станции, конечно. Сначала мы боролись с этим руками и перетыкали провод в ноутбуке. Потом научились перезагружать hub софтово, при этом он сбрасывает питание и переподключает все устройства. Теперь каждое тестирование начинается с переподключения всех USB устройств. В этом нам помогает usbdeview. Выяснилось, что не все хабы так делают, и почти точь-в-точь такой же с виду хаб так не умеет. Закупаем ровно такие же.
Даже порядок включения устройств в хаб влияет на стабильность, в руководстве пользователя есть специальный раздел с иллюстрацией, как что втыкать:
Оснастка
Оснастка состоит из механики, тестирующей платы(1) и платы пробников(2).
Разработка механики
Однажды мы начали делать нашу собственную механику, проработали несколько вариантов:
Разрабатывать свою механику с нуля довольно дорого. Решения кажутся 100% рабочими, а потом в макетах всегда что-то заедает, где-то прогибается и постоянно требуются разные доработки.
В конце концов мы пришли к выводу, что гораздо выгоднее использовать готовые узлы. Для снижения стоимости можно использовать одинаковые оснастки на разных проектах, перерабатывая только сменные модули. На этом проекте мы использовали оснастку Ingun MA260.
Процесс разработки механики в нашем случае можно разделить на следующие этапы:
- Выбор подходящей по размеру оснастки
- Компоновка — размещение DUT и печатных плат
- Расстановка направляющих элементов, упоров и пробников
- Выгрузка конструкции плат для трассировки
- Проверка с моделями готовых печатных плат
- Создание чертежей
- Производство деталей
- Проверка сборки
- Повторить цикл (пока получалось с первого раза)
Вот пример чертежа подвижной пластины:
Платы тестовой станции
Есть разные подходы к реализации соединений между подпружиненными контактами и приборами тестовой станции.
- Без печатных плат внутри оснастки. Провода от каждого подпружиненного контакта идут на общий разъём оснастки, а уже с него сигналы распределяются на приборы. Монтаж проводов может быть очень трудоёмким, смена такой оснастки сопряжена с риском повреждения проводов.
- С одной платой пробников. Плата пробников выполняет две функции: механическая и электрическая. Держатели пробников запаяны в отверстия на плате, а тестовые сигналы выведены на разъёмы к внешним приборам. Но в нашем DUT есть специфические интерфейсы, и нам нужна дополнительная плата внутри для работы с ними.
- С платой пробников и платой тестера. Плата тестера — отдельное устройство со своим микроконтроллером, который получает команды по USB с ноутбука. Она может быть объединена с платой пробников, но из-за большого количества отверстий для держателей пробников это неудобно в плане трассировки.
Плата тестера выполняет функции:
- Формирование специальных интерфейсов
- Обработка логических сигналов.
- Переключение аналоговых сигналов для внешнего вольтметра.
- Контроль и управление питанием DUT.
- Детектирование наличия DUT в оснастке.
- Исполнение тестовых последовательностей.
- Прошивка DUT (на плате закреплён стандартный программатор).
Провода
Проводов довольно много. Несколько из них подключают руками в DUT перед тестированием:
- кабель антенны с быстросъемным SMA
- micro USB
- аккумулятор
Аккумулятор мы решили втыкать руками, потому что на момент создания оснастки считали, что каждое устройство будет тестироваться с комплектным аккумулятором. На практике это оказалось избыточным, неисправных аккумуляторов нам не попадалось, поэтому оператор использует один и тот же аккумулятор.
При закрывании оснастки есть риск заламывания проводов. При этом сделать их совсем коротко тоже нельзя — надо дать оператору шанс их воткнуть, не залезая в оснастку самому.
Быстросъёмный SMA оказался не быстрее обычного, от него производство избавилось.
Оглядываясь назад, следовало сделать автоматическое подключение этих интерфейсов.
К разъёмам со сквозными отверстиями (Through-hole) мы подключаемся через торчащие пины с обратной стороны платы. А как добраться до USB? Для этого есть специальные механизмы бокового доступа (Side approach mechanism), которые позволяют воткнуть имитатор разъёма в тестируемый узел, или подвести подпружиненные контакты.
Микрофон
Сначала для тестирования динамика на DUT мы использовали оператора. На DUT идёт команда попикать 1..3 раза, а оператор должен выбрать правильное количество пиков во всплывающем окне. Наши программисты постоянно ошибались даже при наладке стенда, а на производстве — вообще гиблое дело. В итоге мы добавили микрофон, он крепится вот так, прямо напротив излучателя DUT.
Хранение и визуализация данных
Процесс тестирования начинается со связи с сервером. Мы хотим знать обо всём, что происходит с нашими устройствами на производстве. Так что нет связи — нет тестирования. Для этого на сервере развернута база данных. При любой операции со станцией в базу заносится запись, фиксируется время начала, окончания и все результаты шагов тестирования. Так что впоследствии мы можем делать выгрузки с интересной статистикой, а также подробно узнать судьбу конкретного экземпляра. Для оперативного контроля производства у нас появился сайт пользователя с наиболее интересными метриками:
Здесь показано общее количество устройств, прошедших тестирование, количество бракованных устройств, их процентное соотношение. Ниже таблица с расшифровкой брака количество ошибок на тестовые стадии. Справа внизу — График тестов, он показывает “хорошие” и “плохие” устройства во времени нарастающей суммой. На нём хорошо видны перерывы в тестировании(горизонтальные участки). По наклону графика можно судить о темпах выпуска и видеть заранее, успевает ли производство в срок, или уже пора корректировать план.
Транспортировка
Транспортировка оборудования тестовой станции на производство выглядит как разовая операция. На практике они достаточно активно перемещаются, иногда между производствами, иногда возвращаются на ремонт к разработчикам всеми возможными видами транспорта. В общем требования к упаковке повышенные. Для транспортировки мы используем вот такие кейсы Peli 1637.
Оборудование прокладываем пупыркой, пустое пространство набиваем ей же. Наблюдали из иллюминатора погрузку нашего оборудования в самолёт. Масса тестовой станции брутто 27 килограмм. Мы думали, что-то точно сломается, но и чемодан и начинка всё пережили без потерь.
Эталонный образец
Разворачивая тестовую станцию на производстве, хорошо иметь образец устройства, с которым она тестировалась при разработке (гарантированно рабочий образец). С ним же обучаем персонал производства. С ним же проверяем взаимодействие с сервером. Далее в процессе тестирования партии также бывают проблемы, и в первую очередь возникают сомнения в работе самой тестовой станции (иногда обоснованно), и эталонный образец помогает найти, в чём причина.
Трудозатраты на проекте
Разработка железа (оснастка, платы внутри) — 8% от общей трудоёмкости. Если вы задумали делать тестовую станцию — не воспринимайте аппаратную часть как основную по затратам и сложности.
Софт (Разработка, баги, тестирование) — в сумме дают 75% всех трудозатрат.
Для этого изделия этап постановки на производство превышает по сложности и стоимости разработку самого устройства.
Сейчас мы работаем над унифицированной платформой тестирования. Унификация затронет аппаратную часть, встраиваемое ПО и серверную платформу. Это позволит снизить затраты и время на разработку тестовых станций для новых устройств наших партнеров.
Наверняка я забыл написать про что-то важное, добро пожаловать в комментарии.
P.S. Мы не стали продлевать блог компании на Хабре, так что подписывайтесь на меня, если хотите и дальше следить за нашими успехами.
lamerok
Красота, у нас примерно похожий подход, правда не для печатных плат, а для тестирования встроенного ПО.
Вопрос, какой облачный сервис используете? И какое средство для отчётов, отображения результатов и графиков используете?
Ioanlarionov Автор
Для сбора данных по результатам тестов Cloud SQL в Google Cloud.
Получить отчёт, например, во всем успешным тестам можно SQL запросом. Удобно использовать ПО с графическим интерфейсом, например, HeidiSQL.
Наиболее часто используемую выборку из базы по количеству проваленных и успешных тестов вынесли в приложение на Flask, чтобы интересующиеся результатами своих трудов коллеги могли наблюдать процесс тоже.
Впоследствии на сырой вывод таблицы навесили интерфейс ArchitectUI, чтобы было не только функционально полезно, но и красиво.
lamerok
Спасибо