Недорогие решения для автоматизации тестирования с аппаратным моделированием в цикле

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

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

Ручное тестирование против автоматизированного тестирования

В индустрии довольно обычно иметь автоматизированное тестовое оборудование (в основном для тестирования на уровне производства). Однако для разработки продукта это не является общепринятой практикой. Как упоминалось выше, стоимость и время разработки для настройки сложного автоматизированного тестового оборудования требуют значительных усилий. Такие затраты и усилия оправданы только для производства большими объемами или малыми объемами с очень сложными конфигурациями тестирования (например, системы космических аппаратов малого объема, которые подвергаются многочисленным экологическим испытаниям). Для остального мира мы прибегаем к базовому, утомительному ручному тестированию. Такое тестирование может включать в себя проверку АЦП/ЦАП, проверки протоколов, тесты на потребление энергии и т.д. Независимо от типа теста, надежда заключается в том, что его нужно будет провести один или два раза, а затем его можно будет передать группе тестирования.

Непреднамеренные последствия и автоматизация

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

Дешёвое решение

Для встроенных систем существует недорогое, но в то же время очень масштабируемое и практичное решение для автоматизированного тестирования. Хотя оно и не идеально, оно обеспечивает наивысшую отдачу от инвестиций для инженера-конструктора. Концепция заключается в использовании простого устройства, которое может подавать аналоговые сигналы, считывать аналоговые сигналы, генерировать различные последовательные потоки протоколов и анализировать формы сигналов. Примером недорогого устройства, обладающего такими характеристиками, является Analog Discovery 2. Несмотря на то, что это устройство на 5В, оно все же обладает значительными возможностями. Я считаю его своим швейцарским ножом для разработки встроенных систем. Существуют и другие сопоставимые продукты, но я обнаружил, что это устройство особенно хорошо работает для моих приложений. Это устройство может работать как с вашего настольного компьютера, так и с Raspberry Pi. Также у него есть библиотека Python, которая позволяет пользователю быстро собирать тестовые программы. Для удобства я докеризировал полную конфигурацию и собрал ее для всех архитектур.

Пример выполнения

Рассмотрим реальный пример, который можно найти в этом репозитории. Для простоты наша встроенная цель будет Arduino Duo. Ниже представлен наш полный тестовый набор:

Здесь идея заключается в следующем:

• Хост-компьютер посылает команды Analog Discovery 2 для генерации аналоговых сигналов на Arduino
• Arduino считывает и сохраняет значения АЦП
• Хост-компьютер получает значения АЦП через UART (USB)
• Хост-компьютер проверяет, соответствуют ли отправленные через Analog Discovery 2 данные телеметрии, отправленной Arduino

Почему мы хотели бы автоматизировать что-то подобное? Допустим, мы переделываем плату рядом с АЦП, или кто-то меняет драйверы, которые взаимодействуют с АЦП. Можем ли мы быть на 100% уверены, что простое ручное чтение АЦП с несколькими поворотами ручек на блоке питания достаточно для тестирования нашего аппаратного/программного обеспечения? Если нет, то почему бы не позволить автоматизации охватить каждую перестановку и каждый крайний случай, чтобы нам не приходилось этого делать? И просто для верности, почему бы не запустить то же самое 100 раз... просто потому, что мы можем! Это может стать гораздо более сложным и изощренным (например, тестирование протоколов, тесты фильтрации АЦП и т.д.), но в этой статье будут рассмотрены только основы.

Тестовый скрипт довольно прост. Предполагая, что ваш Arduino (т.е. тестируемое встроенное устройство) был загружен соответствующими программными файлами и все было правильно подключено, вы бы запустили тестовый скрипт на своем компьютере следующим образом:

python -m pytest test_arduino_hil.py

Это приведет к тому, что Analog Discovery 2 будет проходить через диапазон напряжений АЦП Arduino и проверять, соответствует ли входное напряжение выходному напряжению, считываемому с АЦП. Вместо ручного перебора с помощью настольного источника питания, скрипт сделал это за вас одной командой. Для такого простого примера это может показаться ненужным, но этот процесс окупается, когда тесты комбинируются в регрессионном стиле.
Совмещая это с нашей системой CI/CD, мы можем видеть следующие этапы, которые выполняются и проходят:

Вышеупомянутые этапы:

1. docker_build: Сборка окружения. В данном случае мы используем образы docker на Linux ПК и устройствах на базе ARM, таких как Raspberry Pi
2. arduino_load_test: Компиляция и загрузка кода Arduino и проверка, что все работает.
3. arduino_hil_test: Запустите тест с использованием реального оборудования на физическом Arduino.

Если мы подробнее рассмотрим раздел Тесты, мы можем видеть, что эти тесты были зафиксированы и обработаны Gitlab:

Теперь у нас есть программная настройка, которая позволяет нам тестировать нашу разработку локально и удаленно (используя нашу систему CI/CD). Это позволяет инженеру-конструктору продолжать сосредотачиваться на проектировании, а не на тестировании и отладке в дальнейшем.

Заключение

В этой статье мы рассмотрели концепцию использования автоматизированных тестов для одновременной и последующей проверки дизайна. Будь то незначительная доработка или кардинальное изменение дизайна, наличие автоматизированных регрессионных тестов окупается, когда дело доходит до исключения непредвиденных последствий (то есть исправить одно, сломать другое). Рекомендуемый процесс заключается в написании этих тестовых скриптов параллельно с процессом разработки дизайна (аналогично Разработке через тестирование). Сочетание этих автоматизированных тестов с системой CI/CD добавляет дополнительное преимущество, демонстрируя, что наши платы работают на удаленной цели и могут быть протестированы кем угодно, где угодно и когда угодно.

Хотите узнать больше о том, как Altium может помочь вам с вашим следующим проектом печатной платы? Обратитесь к эксперту Altium или узнайте больше о основных проблемах DFM и их решениях. Вы можете скачать бесплатную пробную версию Altium Designer здесь.